[OpenBSD] Problèmes pour faire un routeur (wifi) - problèmes avec le dhcp et le net

Système d'exploitation Linux
1

J’essaye de m’ “entraîner” à faire un routeur sous OpenBSD et j’ai quelques difficultés :whistle:

Je suis passé en CURRENT parce que j’utilise une carte PCI Wifi Ovislink avec le chip Realtek 2500, et le driver ral de la RELEASE et de STABLE ne fonctionnent pas en mode AP.

Donc après ce passage, je fais un peu tout ce qu’il faut :

ip.inet.forwarding = 1 dans /etc/sysctl.conf
je configure dhcpd

et le réseau est un peu particulier puisque je fais que tester…
Je vous explique.

J’ai un routeur US Robotics que j’appelerai USR par la suite. La bécane sous OpenBSD s’appellera Fixe, et mon PC portable s’appellera Portable :slight_smile:

Donc, USR est relié au net, et du coté LAN il a l’IP 192.168.1.1.
Il file en DHCP les addresses entre 192.168.1.2 et .99
Au-delà de 100 c’est les addresses pour ceux qui veulent une IP fixe.

Sur Fixe j’ai donc une carte PCI ethernet nommée re0, et une carte PCI Wifi nommée ral0.
re0 est donc reliée au routeur, elle est config en DHCP et reçoit 192.168.1.7

ral0 est configurée comme suit :

Comme vous pouvez le voir je voudrais que les postes en Wifi soient dans 192.168.2.0/24

Jusque là tout va bien, quand je scanne je vois bien l’AP désiré.

Mes deux problèmes :

1°) le DHCP

J’ai configuré dhcpd pour écouter sur ral0 dans /etc/dhcpd.interfaces, et il est bien lancé au démarrage.
Malheureusement quand j’essaie de me connecter ça marche pas, je ne reçois aucune addresse…
Pourtant dans /var/db/dhcpd.leases j’ai bien un log d’addresses attribuées, avec la bonne addresse MAC de la carte wifi de Portable :frowning:

Voilà ma conf :

(P.S. : comme le suggère la ligne domain-name-servers, j’ai bind qui tourne sur Fixe, et qui fonctionne bien)

2°) le cas des IP fixes - pas de net

Si sur Portable, au lieu de laisser le DHCP faire, je config moi-même, en mettant l’IP 192.168.2.2, le DNS 192.168.2.1, etc, j’ai apparemment aucun problème de LAN : je peux pinger Fixe avec Portable et vice-versa, et d’ailleurs avec Portable (dans 192.168.2.0/24) je peux pinger la carte ethernet de Fixe qui est dans 192.168.1.0/24, ainsi que USR.

Merveilleux !

Sauf que si je veux acceder au net… là plus rien :frowning:

Dans USR j’ai configuré la route suivante :

Voilà, je sais pas ce que j’ai oublié/mal fait…
Si vous avez besoin de renseignements supplémentaires que j’aurais omis n’hésitez pas (des screenshots de l’interface HTML de config de USR ? :D)

A noter : je n’ai que des notions de base lacunaires en réseau, je n’ai qu’il y a peu découvert (et pas forcément très bien assimilé :riva: ) ce que veut dire /24 dans 192.168.1.0/24, etc., alors m’en voulez pas si je vous demande de mieux expliquer :ane:

2

Pffff je me sens super ridicule :craint: :transpi:

J’avais oublié de mettre les règles de NAT kivontbien dans /etc/pf.conf :oops:

Maintenant ça marche :smiley: Y compris le DHCP :francais:

Par contre pour les règles de pare-feu avec ce bon pf je pateauge.
Je me suis inspiré de ce (vieux) tuto pour pf.conf, en l’adaptant, et quand je charge ces règles, je peux plus “pinger” ni “ssher” Fixe depuis une adresse dans 192.168.1.0/24 (pas essayé avec .2.0), que ce soit sa carte en 192.168.1.7 ou en 192.168.2.1 :frowning:

Si quelqu’un détecte une erreur que je persisterais à ne pas voir… Merci d’avance :slight_smile:

Donc voilà, actuellement je n’utilise que la partie NAT de ce pf.conf et ça marche mais bon j’ai donc pas de pare-feu.
Si j’utilise toute la conf ça merde comme expliqué.
J’ai essayé de virer tous les trucs qui me parraissaient “violents” (par exemple les références à nonroutable) mais rien n’y fait… :frowning:

3

Bon alors sans crier gare ça remerde :eeek2:

Si je config Portable avec les infos manuellement (192.168.2.2, gateway et DNS 192.168.2.1) j’ai le net et tout :ouioui:

et si je le mets en DHCP, que dalle :zarb:

sur Fixe (en lançant dhcpd avec l’option -d pour qu’il logge sur stdrout) je vois des DHCPOFFER, DHREQUEST, de temps en temps des DHPACK,… Mais ça conclut jamais :pleure:

Et au bout d’un certain temps j’ai une ligne genre “already acking address 192.168.2.2” et j’ai effectivement une entrée dans /var/db/dhcpd.leases

Jcomprends plus rien :frowning:

4

Bon bin voilà sans doute la réponse :smiley:

Wireless AP using OpenBSD

Ceci donné par le gars qui fait le driver OpenBSD pour les cartes à bases de realtek, donc ça a un certain poids… :slight_smile:

Donc ne pas mettre de serveur DHCP côté wifi, mais faire un bridge et faire écouter le DHCPD sur le filaire…

Dommage, le tuto que je suivais ne disait pas ça du tout, et faisait 2 sous réseaux, un pour le wifi et un pour le filaire, ce qui avait des avantages :pleure:

Reste plus qu’à tester si ça marche bien comme ça :smiley:

5

Pour donner un avis sur winwin ou critiquer y’a du monde sur clubic, mais pour aider ceux qui veulent faire une VRAIE config, y’a personne … Kevin quand tu nous lasses …

Pour les acces wifi je te conseille tres tres vivement authpf sur openbsd, c’est LE mode de connexion sécurisé.
Sinon le DHCP c’est comme toujours une plaie dans un réseau, mieux vaut des adresses fixes, surtout sur un parc de moins de 10~15 machines ! :slight_smile:

Pour éviter les port scan des blaireaux de 12 à 15 ans, tu peux rajouter ça en début de ton pf.conf :

Brouille nmap

block in log quick on { $in_if0, $in_if1, $in_if2, $in_if3 } inet proto tcp all flags FUP/FUP
block in log quick on { $in_if0, $in_if1, $in_if2, $in_if3 } inet proto tcp all flags SF/SFRA
block in log quick on { $in_if0, $in_if1, $in_if2, $in_if3 } inet proto tcp all flags /SFRA

Ici les in_if1->3 ce sont mes numéros de port sur le FW, il faut mettre les tiens bien entendu.

6

Si y’a personne connaissant suffisament bien OpenBSD pour l’aider, ca sert a rien de la ramener pour raconter n’importe quoi.
Quand j’ai lu son post la premiere fois, je me suis assure qu’il n’avait pas fait une erreur bete au niveau reseau mais tout semblait OK.
Et au vu de la suite des evenements, il semble que son probleme touche un defaut assez “special” du driver de sa carte wifi… qui irait pointer ce probleme sans connaitre OpenBSD dans les details ?

Et puis bon, tu fais le malin mais tu ne reponds pas non plus a son probleme et tu donnes un conseil a la con sur DHCP…

Sans compter que tu remontes un topic qui a plus de 2 ans…

owned ! comme on dit :wink:

7

Plus de 2 ans certes mais ton post est largement à côté de la plaque.
1/ J’ai apporté ma pierre à l’édifice chose que tu aurais pu faire, ne serait-ce, qu’en indiquant ce que tu viens de ressortir de ton chapeau troué. Facile puisque tu te souviens très précisément de ce que tu as pu penser sur un topic vieux de 2 ans …

2/ Quant au conseil que tu juges injustement, je trouve, comme étant “à la con”, je le trouve parfaitement justifié. Sachant qu’il distribue des adresses dans un réseau avec 2 machines, le DHCP est inutile.

3/ La communauté OpenBSD étant déjà limitée (en quantité), nous sommes bien heureux de trouver de bonnes âmes qui parlent de l’OS, ne serait-ce que par ajout de connaissances même sur de vieux posts.
Maintenant si ça te défrise, c’est le même tarif.

owned bis
Edité le 18/08/2008 à 18:01

8

Oui je m’en souviens parce que des posts sur autre chose que linux ou macosx, y’en a pas des masses ici…
Surtout quand le post en question est interessant et que l’auteur en assure le suivi.
Et puis c’est Sufflope, c’est pas un mec inconnu ici.

Il est clairement en train de monter une maquette pour faire des tests et de l’autoformation.
C’est extremement rare de faire ce genre de chose pour un reseau final comportant moins de 10 machines…
Et puis, bon, dhcp c’est comme beaucoup d’autres services d’infrastructure : on le configure une fois et on l’oublie.
Generalement, plus simple a mettre en place qu’un dhcpd, tu meurs. Donc ca vaut vraiment pas le coup de s’en passer… meme pour 2 ou 3 machines.

Ouais mais quand ca concerne un bug de ce genre, on peut raisonnablement penser qu’en 2 ans, il a ete resolu… ou alors, l’image d’excellence technique que j’ai de la communaute OpenBSD va bientot voler en eclat…

9

Et donc on attend toujours ta contribution … j’ai donné des regles pf … Mais toi ???
Pour ce qui est dit dans le petit texte de Sufflope, ce n’est pas un bug. L’approche OpenBSD du WiFi est très opposée à celle de Linux justement pour maintenir un niveau de sécurité élevé. Le bridge est indispensable si on souhaite utiliser openbsd avec du Wifi

Allez j’en lache un peu plus :
Combiné avec une activation par ancre, authpf va charger les regles de filtrage lorsque la connexion est ok. Ceux qui ne sont pas authentifiés ne peuvent pas passer.

On déclare un bridge entre la carte wifi et une interface filaire en remplissant un fichier /etc/bridgename.bridge0 par exemple :


add ath0  # l'interface wifi
add vr0    # L'interface cable
up            # pour mettre up le bridge

On manipule le bridge avec brconfig
Pour la conf de authpf ce lien peut aider : lien

On crée ensuite le fichier /etc/authpf.conf. Il est obligatoire pour la connexion. Même vide. Si ce fichier n’existe pas, après la saisie du password, la connexion se ferme.
Contenu du fichier :


anchor=authpf
table=authpf_users

La table servira pour les manips des connexions valides ou pas.
On ajoute ensuite les utilisateurs qui serviront pour établir les connexions WiFi avec authpf.
Il est très important que les utilisateurs fassent partie du groupe authpf.

exemple de Manip dans /etc/pf.conf


<---snip>
# HTTP pour les utilisateurs authentifies
pass out log on $in_if0 proto tcp from <authpf_users> to any port { http, https } modulate state queue http_if
<---snip>

Autre point, dans /etc/rc.local, on peut ajouter une ligne comme ceci pour mettre un tag sur les paquets qui ne proviennent pas d’une identification authpf (Une console par exemple, la dans l’exemple je tag ce qui vient de ma WII).


brconfig bridge0 rule pass out on vr0 src 00:1f:36:6a:82:18 tag WII

Ce qui permet dans pf.conf de laisser passer les paquets en vérifiant ce fameux tag comme ceci :


pass out log quick on $in_if0 tagged WII modulate state queue http_if

Ce genre de conf, c’est ce que j’ai chez moi, ça marche au poil !
Pour ceux qui vont relire ces lignes, sachez que j’ai volontairement passé certaines déclaration authpf. Elles sont toutes accessibles sur le site openbsd. Oublier DHCP dans un réseau WiFi c’est oublier qu’on se ballade avec le froc sur les chevilles.
Edité le 18/08/2008 à 23:52