Cet exemple montrera comment faire fonctionner OpenBSD en tant que routeur. Dans ce cas, un routeur est défini comme étant un système qui assume les devoirs suivants :

• Traduction d'Adresses Réseaux (NAT)
• Distribuer des adresses IP à d'autres clients via DHCP
• Permettre les connexions entrantes au serveur web local
• Faire de la mise en cache DNS pour le LAN
• Fournir une connectivité sans fil (requiert une carte supportée)

Cet exemple utilisera deux NIC em(4) et une carte sans fil athn(4). Les noms des interfaces em0, em1, et athn0 devraient être remplacées par celles qui vous sont appropriées.

La configuration réseau utilisera un sous-réseau 192.168.1.0/24 pour les clients filaires et 192.168.2.0/24 pour les sans-fils.

# echo 'net.inet.ip.forwarding=1' >> /etc/sysctl.conf
# echo 'dhcp' > /etc/hostname.em0 # or use a static IP
# echo 'inet 192.168.1.1 255.255.255.0 192.168.1.255' > /etc/hostname.em1
# vi /etc/hostname.athn0

Ajoutez ce qui suit, en changeant le mode et le canal si besoin :

media autoselect mode 11n mediaopt hostap chan 1
nwid AccessPointName wpakey VeryLongPassword
inet 192.168.2.1 255.255.255.0

OpenBSD permet par défaut seulement les connexions WPA2-CCMP dans le mode HostAP. Si vous avez besoin du support de vieux protocoles (non sécurisés), ils doivent être explicitement activés.

Le service dhcpd(8) devrait être démarré au démarrage pour fournir aux machines clients des adresses IP locales. La configuration est faite via le fichier dhcpd.conf(5).

# rcctl enable dhcpd
# rcctl set dhcpd flags em1 athn0
# vi /etc/dhcpd.conf

L'exemple suivant fournit aussi les réservations d'adresses IP statiques pour un ordinateur portable et un serveur selon leur adresse MAC.

The following example also provides static IP reservations for a laptop and server based on their MAC addresses.

Prenez cet exemple et adaptez-le à vos besoins :

subnet 192.168.1.0 netmask 255.255.255.0 {
	option routers 192.168.1.1;
	option domain-name-servers 192.168.1.1;
	range 192.168.1.4 192.168.1.254;
	host myserver {
		fixed-address 192.168.1.2;
		hardware ethernet 00:00:00:00:00:00;
	}
	host mylaptop {
		fixed-address 192.168.1.3;
		hardware ethernet 11:11:11:11:11:11;
	}
}
subnet 192.168.2.0 netmask 255.255.255.0 {
	option routers 192.168.2.1;
	option domain-name-servers 192.168.2.1;
	range 192.168.2.2 192.168.2.254;
}

Tout espace d'adresses selon la RFC 1918 devrait être spécifié ici. La ligne domain-name-servers dans cet exemple spécifie un serveur DNS local qui sera configuré dans une section plus bas.

Le parefeu PF d'OpenBSD est configuré via le fichier pf.conf(5). Il est hautement recommandé de vous familiariser avec, et celui de PF en général, avant de copier cet exemple. Chaque section sera expliquée plus en détails.

# vi /etc/pf.conf

Une configuration pour une passerelle peut ressembler à cela :

wired = "em1"
wifi  = "athn0"
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
	 	   172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
	 	   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
	 	   203.0.113.0/24 }
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
antispoof quick for { egress $wired $wifi }
block in quick on egress from <martians> to any
block return out quick on egress from any to <martians>
block all
pass out quick inet
pass in on { $wired $wifi } inet
pass in on egress inet proto tcp from any to (egress) port { 80 443 } rdr-to 192.168.1.2

Expliquons maintenant les différentes sections de ce jeu de règles :

wired = "em1"
wifi  = "athn0"

Les noms des interfaces filaires et sans fil pour le LAN sont définies par des macros, utilisées pour faciliter la maintenance ultérieure. Les macros peuvent être référencées par une jeu de règles après avoir été définies.

table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
	 	   172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
	 	   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
	 	   203.0.113.0/24 }

Ceci est une table d'adresses privées non routables qui sera utilisée plus tard.

set block-policy drop
set loginterface egress
set skip on lo0

PF permet à certaines options d'être paramétrées dès le démarrage. L'option block-policy décide quels paquets rejetés devront retourner un TCP RST ou être silencieusement détruits. L'option loginterface spécifie quelle interface devrait avoir la collection activée de statistiques des paquets et du nombre d'octets. Ces statistiques peuvent être vues avec la commande pfctl -si. Dans ce cas, le groupe egress est utilisé plutôt que le nom spécifique de l'interface. En faisant cela, l'interface contenant la route par défaut (em0) sera automatiquement choisie. Pour finir, l'option skip permet de ne pas suivre les paquets pour une interface donnée. Le pare-feu ignorera le trafic sur l'interface de bouclage lo(4).

match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)

Les règles match utilisées ici accomplissent deux choses : normaliser l'entrée des paquets et exécuter la traduction d'adresses réseaux, avec l'interface egress entre le LAN et internet. Pour une explication plus détaillée sur les règles match et leurs différentes options, référez-vous au manuel pf.conf(5).

antispoof quick for { egress $wired $wifi }
block in quick on egress from <martians> to any
block return out quick on egress from any to <martians>

Le mot clé antispoof fournit certaines protections contre des paquets ayant des adresses sources usurpées. Les paquets entrant devront être détruits s'il apparaît qu'ils font partie de la liste des adresses non routables définies plus tôt. De tels paquets ont probablement été envoyés en raison d'une mauvaise configuration, ou probablement en tant que partie d'une attaque de spoofing. De la même manière, nos clients ne devraient pas essayer de se connecter à de telles adresses. L'action “return” est spécifiée pour éviter les timeout gênants pour les utilisateurs. Notez que cela peut causer des problèmes si le routeur fait lui aussi de la NAT.

block all

Le pare-feu aura une politique “default deny” pour tout le trafic, signifiant que seules les connexions entrantes et sortantes explicitement posées dans notre jeu de règles seront autorisées.

pass out quick inet

Permettre le trafic IPv4 sortant depuis la passerelle elle-même et les clients du LAN.

pass in on { $wired $wifi } inet

Permettre le trafic LAN.

pass in on egress inet proto tcp from any to (egress) port { 80 443 } rdr-to 192.168.1.2

Transférer les connexions entrantes (sur les ports TCP 80 et 443, pour un serveur web) vers la machine ayant l'adresse IP 192.168.1.2. Ceci n'est qu'un exemple de redirection de ports.

Bien qu'un cache DNS ne soit pas requis sur une passerelle, il est commun de l'ajouter. Quand les clients font une requête DNS, ils interrogent en premier le cache unbound(8). S'il n'a pas la réponse, la requête sortira vers le résolveur en amont. Les résultats seront alors envoyés au client et mis en cache pendant une période de temps, rendant les futures consultations pour la même adresse plus rapide.

# rcctl enable unbound
# vi /var/unbound/etc/unbound.conf

Quelque chose comme ça devrait fonctionner pour la plupart des configurations :

server:
	interface: 192.168.1.1
	interface: 192.168.2.1
	interface: 127.0.0.1
	access-control: 192.168.1.0/24 allow
	access-control: 192.168.2.0/24 allow
	do-not-query-localhost: no
	hide-identity: yes
	hide-version: yes

forward-zone:
        name: "."
        forward-addr: 1.2.3.4  # IP of the upstream resolver

D'autres options de configuration peuvent être trouvées dans unbound.conf(5). Les requêtes DNS sortantes peuvent aussi être chiffrées avec le package dnscrypt-proxy – voir le fichier README inclus pour les détails.

Si le routeur doit aussi utiliser le résolveur de cache, son prore fichier de configuration /etc/resolv.conf doit contenir nameserver 127.0.0.1.

Une fois que ces changements sont faits, redémarrez le système.

Cette page est la traduction officieuse de la page “Building a router“ de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

Contribut(rice|eur)s :