cd / ;
apropos ;
find * ;
VPN signifie "Virtual Private Network" que l'on peut traduire par rĂ©seau virtuel privĂ©. Comme son nom l'indique, cela permet de crĂ©er un rĂ©seau entre plusieurs machines qui sera "cachĂ©" au reste de l'internet mondial (d'oĂč le "privĂ©").
En pratique, un VPN sert souvent Ă contourner les restrictions ou utilisations plus ou moins abusives qu'un fournisseur d'accĂšs, d'un rĂ©seau WiFi public, ou un gouvernement peuvent mettre en place sur votre accĂšs Ă internet. Vous retrouvez ainsi un accĂšs sain. Ăa peut aussi ĂȘtre utile pour rĂ©server des services au sein du VPN uniquement : streaming de musique, partage de fichiers...
Il existe plusieurs sortes de VPN, chacun présentant des avantages et inconvénients selon l'utilisation souhaitée.
Nous présenterons donc plusieurs solutions dans cette partie : Wireguard, OpenIKED, et un tunnel SSH.
Par la suite, nous appellerons :
Nous configurerons principalement des "roadwarriors".
roadwarrior... c'est censé avoir du sens?
Ce terme décrit une l'utilisation du tunnel VPN permettant à un client, peu importe son adresse IP, de faire passer tout ou partie de son trafic au travers du VPN pour le faire sortir par le serveur. De cette façon, pour les autres, tout semble venir du serveur, le client étant "caché" derriÚre la façade du serveur. Le serveur, quant à lui, ne fait qu'attendre qu'un client se connecte pour faire le relai.
Un peu plus loin, nous proposerons aussi la possibilitĂ© d'utiliser un VPN pour proposer votre serveur derriĂšre une nouvelle IP fixe, pratique pour les serveurs nomades ou si votre fournisseur d'accĂšs Ă internet ne vous propose pas d'IP fixe ou bien une IP Ă mauvaise rĂ©putation. Ă ce moment-lĂ , plus question de roadwarrior, la configuration du VPN sera mĂȘme encore plus simple. On devra par contre dĂ©tailler la configuration du pare-feu pour effectuer les bonnes redirections.
Wireguard est un VPN trĂšs pratique Ă mettre en place tout en restant sĂ©curisĂ© puisqu'il n'accepte que les derniĂšres mĂ©thodes de chiffrement existantes. De plus, il fonctionne mĂȘme si l'IP de votre appareil change (passage d'une connexion filaire Ă un rĂ©seau sans-fil par exemple). Il permet un accĂšs tant en IPv4 qu'IPv6, ce qui peut permettre d'obtenir une IP fixe en IPv6 si votre FAI n'en donne pas. Il est supportĂ© de base Ă partir d'OpenBSD 6.8. Avec les versions prĂ©cĂ©dentes, il faudra installer un port (# pkg_add wireguard-go).
Site officiel de Wireguard:
Il existe des clients wireguard sur de multiples plateformes (android, MacOS...) ce qui facilite son utilisation.
C'est certainement le choix le plus simple et utile si on veut mettre en place un VPN sur un serveur auto-hébergé.
On retrouve les mĂȘmes idĂ©es qui ont dĂ©jĂ fait leurs preuves pour chiffrer des mails ou encore publier les signatures DKIM : la paire de clĂ©s.
Pour faire simple, chaque morceau de données envoyé au travers du VPN est mis dans un coffre et fermé avec un cadenas qui ne peut s'ouvrir qu'avec la clé échangée pendant la poignée de mains. La poignée de main est quant à elle chiffrée avec les clés publiques la premiÚre fois.
Je vous propose l'organisation suivante :
Dans cet exemple, nous utiliserons dans le VPN des IP situées dans le sous réseau 10.0.0.0/24 :
En savoir plus sur les adresses sous-réseau :
https://fr.wikipedia.org/wiki/Sous-r%C3%A9seau
Voici Ă quoi cela va ressembler :
+-------------+
| serveur | wg0: 10.0.0.1 port 4545
| |---------------+
+-------------+ |
| IP Publique |
| 192.0.2.2 |
| |
| |
/\/\/\/\/\/\/\ |WireGuard
| internet | |VPN
\/\/\/\/\/\/\/ |
| |
| |
|rdomain 1 |
+-------------+ |
| client |---------------+
+-------------+ wg0: 10.0.0.2
rdomain 0 (defaut)
Par défaut, le trafic passera par 10.0.0.2 à moins que vous demandiez précisément à passer par une autre route. (ex : route -T1 exec ping openbsd.org)
Le VPN se met en place par la crĂ©ation d'interfaces wgN, oĂč "N" peut ĂȘtre un chiffre de 0 Ă 9 par exemple. Sous OpenBSD, une telle interface peut ĂȘtre obtenue en remplissant un fichier /etc/hostname.wgN.
Le serveur Ă©coutera sur le port 4545 en UDP. N'importe quel autre port peut-ĂȘtre utilisĂ©. VĂ©rifiez tout de mĂȘme que celui choisi ne soit pas dĂ©jĂ rĂ©servĂ© en consultant /etc/services.
Pour créer une clé privée robuste, utilisez la commande suivante :
openssl rand -base64 32
Cela retourne par exemple : "uA1ggvRv66QslZ0ygorWvcLVTxzFauffqMigXTrmLVY="
Ce n'est qu'une fois une clé privée attribuée à une interface que vous pourrez récupérer la clé publique correspondante avec la commande
# ifconfig wgN
Sur le serveur, on crée une clé privée :
# openssl rand -base64 32 r8uSGD6vyycE5n5/atU9/NX9JQPo4SJryNGpjbQG+rA=
On crée l'interface en précisant la clé précédente
# ifconfig wg0 create wgkey r8uSGD6vyycE5n5/atU9/NX9JQPo4SJryNGpjbQG+rA= wgport 4545
Maintenant, vous pouvez récupérer la clé publique correspondant à cette nouvelle interface :
# ifconfig wg0
wg0: flags=8082<BROADCAST,NOARP,MULTICAST> mtu 1420
index 5 priority 0 llprio 3
wgport 4545
wgpubkey x9VXlh4AMa2YRjTMRVE39pQRsFHRJHUYrATL6vkqFmU=
groups: wg
La ligne commençant par "wgpubkey" vous renseigne sur la clé publique utilisée par le serveur. Il faudra la préciser pour les clients, prenez-en note.
Prenez-bien note aussi de la clé privée du serveur : on l'utilisera tout à l'heure dans un fichier pour automatiser toute la procédure en cours.
Maintenant, sur un client, on fait la mĂȘme chose que sur le serveur, c'est-Ă -dire crĂ©er une clĂ© privĂ©e puis une interface wg0 associĂ©e (nul besoin de prĂ©ciser le port):
# openssl rand -base64 32
q/7uIx6wBIRUIdxOi5D6OWEQRVUt2AXhMj7j29W/s3s=
# ifconfig wg0 create wgkey q/7uIx6wBIRUIdxOi5D6OWEQRVUt2AXhMj7j29W/s3s=
# ifconfig wg0 |grep wgpubkey
wgpubkey V3pCAhxnRl0QEL8luB9D4EvTVxGT7QGDDCZ3O26kY3A=
Ici, on souhaite que le serveur se constitue comme une sorte de relai entre le client et le reste du réseau.
On doit pour cela activer la redirection d'IP sur les paquets passant par le serveur :
# sysctl net.inet.ip.forwarding=1
Pour que ça soit automatique, ajoutez cette ligne dans /etc/sysctl.conf :
net.inet.ip.forwarding=1
Si vous voulez faire de mĂȘme en IPv6, utilisez plutĂŽt:
net.inet6.ip6.forwarding=1
De plus, il faudra ajouter une rĂšgle pour faire du nat avec le pare-feu :
# Ouverture du port 4545 en UDP pass in proto udp to port 4545 # ouverture de wg0 pour accéder au vpn pass on wg0 # Ce qui vient du VPN (wg0) est NATté vers # l'interface "publique" du serveur pass out quick on egress from (wg0:network) to any nat-to (egress)
Maintenant qu'on dispose de tout le nécessaire pour identifier client et serveur, on peut creuser le tunnel. Pour ça, on va notamment ajouter les clés publiques des clients sur le serveur, et inversement. On va aussi indiquer les IP autorisées à utiliser le tunnel.
Afin de gagner du temps pour la suite et rendre les choses plus simples, nous allons désormais directement éditer les fichiers /etc/hostname.wg0. Ainsi, lors d'un futur redémarrage, la configuration sera intacte.
PrĂȘtez bien attention aux clĂ©s utilisĂ©es, ce sont les mĂȘmes que celles obtenues juste avant pour vous aider Ă vous repĂ©rer. đ
Sur le serveur : /etc/hostname.wg0 contient maintenant:
inet 10.0.0.1/24 wgkey r8uSGD6vyycE5n5/atU9/NX9JQPo4SJryNGpjbQG+rA= wgport 4545 wgpeer V3pCAhxnRl0QEL8luB9D4EvTVxGT7QGDDCZ3O26kY3A= wgaip 10.0.0.2/32 up
Quelques explications :
Vous pouvez ajouter autant de lignes "wgpeer" que vous voulez. C'est bon Ă savoir si vous souhaitez proposer un accĂšs Ă plusieurs machines đ. Cependant, chaque client disposera de sa propre IP. Par exemple :
wgpeer V3pCAhxnRl0QEL8luB9D4EvTVxGT7QGDDCZ3O26kY3A= wgaip 10.0.0.2/32 wgpeer m7K/gfmMPYRJx1IOP01zYrNbEuMnnZ29xN4OBgRoRXo= wgaip 10.0.0.3/32 wgpeer qnuq5MgezCDHXsYYGmrcegPCNcJvz9EOIG3XyHp1DBk= wgaip 10.0.0.4/32
Sur le client :
Le fichier /etc/hostname.wg0 du client fonctionne comme pour le serveur, Ă ceci prĂšs qu'on doit notamment prĂ©ciser oĂč trouver le serveur ("wgendpoint") et modifier les routes par dĂ©faut pour que le trafic passe par le tunnel.
wgkey q/7uIx6wBIRUIdxOi5D6OWEQRVUt2AXhMj7j29W/s3s= wgpeer x9VXlh4AMa2YRjTMRVE39pQRsFHRJHUYrATL6vkqFmU= wgendpoint chezmoi.tld 4545 wgaip 0.0.0.0/0 inet 10.0.0.2/24 wgrtable 1 !route add -net default 10.0.0.1 up
Ouvrez le tunnel avec la commande suivante sur le serveur et le client :
# sh /etc/netstart wg0
Modifiez la configuration correspondant à l'interface du client pour lui préciser de passer par la table de routage 1. Par exemple, dans /etc/hostname.em0 :
autoconf rdomain 1 up
Vous pouvez désormais vérifier que lorsque vous naviguez sur internet, votre nouvelle IP est celle du serveur.
Comme je le disais plus haut, Wireguard est bien supporté par la plupart des systÚmes. Cherchez "Client wireguard -nom-de-votre-plateforme-" pour trouver votre bonheur. Par exemple, pour Android, on peut trouver un client dans les dépÎts F-droid.
SystÚmes supportés par Wiregard :
https://www.wireguard.com/xplatform/
Wireguard dans F-droid :
https://f-droid.org/en/packages/com.wireguard.android/
Voici le minimum à préciser :
Interface :
Pair :
Voici un exemple :
On a précisé ici comment déployer le VPN avec les outils de base dans OpenBSD. Sachez que vous pouvez installer le port "wireguard-tools" qui pourra vous faire gagner du temps sur la gestion des clés.
Ce tutoriel est trÚs largement inspiré des liens suivants :
https://xosc.org/wireguard.html
https://lipidity.com/openbsd/wireguard/
https://codimd.laas.fr/s/NMc3qt5PQ
Je souligne l'importance du travail de SolÚne qui a eu la judicieuse idée d'utiliser "rdomain" plutÎt que modifier les routes par défaut.
https://dataswamp.org/~solene/2021-10-09-openbsd-wireguard-exit.html
OpenIKED est une implémentation libre du protocole IKEv2 qui permet de mettre en place des VPN de type IPSec.
Ce protocole permet, comme Wireguard, de s'assurer des éléments de sécurité suivants :
Sous OpenBSD, le nom du démon qui gÚre les connexions IKEv2 s'appelle iked.
Vous pouvez dores et déjà consulter la FAQ17 qui couvre officiellement le sujet, puisque cette partie en suit les grandes lignes en guise de traduction détaillée.
https://www.openbsd.org/faq/faq17.html
Par défaut, iked utilise une identification par jeton de clés (publique/privée), un peu comme pour ssh. Vous pouvez les stocker dans des dossiers bien précis pour faciliter l'organisation (au format PEM), iked les prendra automatiquement en charge. Selon si les sources (srcid) et les destinations (dstid) sont écrites sous la forme d'adresses IP ou de noms de domaines, les clés publiques seront à enregistrer sous :
Ce qui est génial, c'est qu'iked saura les retrouver comme un grand.
Dans le cadre de ce tutoriel, nous allons prĂ©senter la mĂ©thode la plus simple, Ă savoir se servir des clĂ©s publiques prĂ©sentes par dĂ©faut sur une installation d'OpenBSD. Libre Ă vous de crĂ©er de nouvelles paires de clĂ©s avec la commande openssl si vous le souhaitez afin de changer l'algorithme de chiffrement. La partie privĂ©e des clĂ©s gĂ©nĂ©rĂ©es sera dans /etc/iked/private, mais vous l'auriez devinĂ© tout seul đ.
Pour l'exemple, nous allons copier les clĂ©s dĂ©jĂ prĂȘtes. C'est facile de les trouver, il s'agit du fichier /etc/iked/local.pub.
Sur le serveur et le client, activez l'interface enc0 :
# echo up > /etc/hostname.enc0 # sh /etc/netstart enc0
Ensuite, insérez dans le fichier /etc/sysctl.conf les lignes suivantes, toujours sur le serveur et le client.
net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1
Sur le serveur et le client, vous ajouterez :
net.inet.ipcomp.enable=1
Activez directement ces fonctionnalités sans avoir à redémarrer :
# while read -r line; do sysctl $line; done < /etc/sysctl.conf
Afin de pouvoir Ă©tablir la liaison entre le client et le serveur, vous devez ouvrir et rediriger ports 500 (isakmp) et 4500 (ipsec-nat-t) sur le serveur.
De plus, on redirige le trafic passant par le VPN en sortie pour qu'il apparaisse avec l'IP du serveur et non celle du client. Ce flux est repéré par l'étiquette "ROADW" définie plus loin dans la configuration d'OpenIKED. Le fichier /etc/pf.conf du serveur ressemblera à ceci (lisez les commentaires) :
# On rassemble les paquets
set reassemble yes
# Petite precaution
antispoof quick for enc0
# On laisse entrer le trafic IKE et IKE NAT-Traversal pour l'authentification
pass in on egress proto udp from any to <ip-du-serveur> port {isakmp, ipsec-nat-t} tag IKED
pass in on egress proto esp from any to <ip-du-serveur> tag IKED
# On laisse passer le trafic encapsulé avec l'etiquette ROADW
pass on enc0 tagged ROADW
# On redirige le trafic avec l'etiquette ROADW vers la sortie
match out on egress inet tagged ROADW nat-to (egress)
Tous les fichiers iked.conf doivent avoir des droits bien choisis. Que ce soit sur le client ou le serveur, vous entrerez :
# touch /etc/iked.conf # chmod 600 /etc/iked.conf
Voici le contenu du fichier /etc/iked.conf sur le serveur :
ikev2 "warrior" passive ipcomp esp \ from 0.0.0.0/0 to 10.0.5.0/24 \ peer any local <ip.publique.du.serveur> \ srcid "chezmoi.tld" \ tag "ROADW"
Ce dernier crĂ©e un flux Ă partir du trafic venant de n'importe oĂč (0.0.0.0) et le redirige vers le rĂ©seau 10.0.5.0/24 auquel appartiendront les clients. Au passage, il donne l'Ă©tiquette "ROADW" Ă ce flux pour le repĂ©rer ensuite.
Pensez Ă bien modifier l'IP publique du serveur et le nom de domaine. Le paramĂštre srcid servira Ă identifier le certificat Ă utiliser pour l'authentification (ça peut donc aussi ĂȘtre une adresse IP selon ce que vous avez prĂ©fĂ©rĂ©.
Tu crois t'en sortir comme ça ? Nous on veut savoir ce que ça veut
dire ces trucs bizarres dans la configuration.
Et c'est parti pour des détails, ligne par ligne :
La configuration est quasiment identique, mais inversĂ©e đ
ikev2 "warrior" active ipcomp esp \ from 0.0.0.0/0 to 0.0.0.0/0 \ peer "<ip.publique.du.serveur>" \ srcid "batman@cacahuete.tld" \ dstid "chezmoi.tld"
Les paramĂštres auxquels vous devez ĂȘtre attentifs sont "srcid" et "dstid" :
Si vous ĂȘtes perdus, retournez lire la partie sur les clĂ©s un peu plus haut. đ
Le client doit aussi configurer son IP pour qu'elle appartienne au réseau 10.0.5.0/24. Vous pouvez le faire ainsi en éditant sur le client le fichier de configuration /etc/pf.conf :
match out log on enc0 inet all nat-to 10.0.5.2
Cela associe tout le flux sortant sur l'interface enc0 Ă l'adresse 10.0.5.2. Si vous utilisez plusieurs clients, vous devrez modifier cette adresse. N'oubliez pas de recharger le pare-feu.
Attention : tout le flux du client passe dĂ©sormais par le tunnel chiffrĂ©. Cela peut ĂȘtre embĂȘtant notamment pour la rĂ©solution de domaine, ou si vous utilisez des dĂ©mons locaux. Ajoutez seulement cette ligne au fichier /etc/ipsec.conf :
flow from 127.0.0.1/32 to 127.0.0.1/32 type bypass
Activez cette rĂšgle avec la commande :
# ipsecctl -f /etc/ipsec.conf
En cas d'erreur concernant les permissions, entrez :
# chmod 600 /etc/ipsec.conf
Afin de ne pas avoir à lancer cette commande lors d'un redémarrage, entrez :
rcctl enable ipsec
Attention 2 : La résolution de noms (DNS) ne pourra pas se faire en local. Idéalement, il faudrait indiquer dans le fichier /etc/resolv.conf un résolveur accessible via le VPN, et dans l'idéal le résolveur du serveur s'il en propose. Dans le doute, indiquez dans /etc/resolv.conf un résolveur public :
nameserver 9.9.9.9
C'est parti ! đ
Sur le serveur, rechargez le pare-feu et activez/démarrez iked :
# pfctl -f /etc/pf.conf # rcctl enable iked # rcctl start iked
Sur le client, lancez pour commencer iked sans le mettre en arriĂšre-plan :
# iked -vvd
Vous allez voir un tas de choses s'afficher. Si vous voyez une ligne qui ressemble Ă la suivante, c'est tout bon đ :
sa_state: VALID -> ESTABLISHED from 46.23.92.147:4500 to 192.168.100.122:4500 policy 'warrior'
Par la suite, vous pourrez activer iked sur le client avec rcctl.
Pour vĂ©rifier que cela fonctionne, vous pouvez consulter un des sites permettant de connaĂźtre son IP publique. Si elle est diffĂ©rente et correspond Ă celle du serveur, c'est rĂ©ussi đ. Vous pouvez plus simplement le vĂ©rifier avec la commande suivante :
# ipsecctl -sa FLOWS: flow esp in from 0.0.0.0/0 to 192.168.0.0/16 peer 46.23.92.147 srcid UFQDN/prx@moria.lan dstid FQDN/reiva.xyz type use flow esp out from 192.168.0.0/16 to 0.0.0.0/0 peer 46.23.92.147 srcid UFQDN/prx@moria.lan dstid FQDN/reiva.xyz type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 46.23.92.147 to 192.168.100.122 spi 0x7958b1de auth hmac-sha2-256 enc aes-256 esp tunnel from 192.168.100.122 to 46.23.92.147 spi 0xe7d244a8 auth hmac-sha2-256 enc aes-256
En cas de problĂšme, avant d'arrĂȘter le processus iked, lancez la commande suivante pour fermer le tunnel :
# ikectl decouple
Ă partir du client :
Strongswan Sous Linux ou avec un smartphone android, vous aurez besoin d'utiliser l'application strongswan pour configurer la connexion Ă votre VPN.
Il faudra toutefois configurer un accĂšs par certificats :
https://www.openbsd.org/faq/faq17.html#clientandroid
Sinon, MacOS et Windows peuvent le gérer nativement, mais il faudra demander à leurs experts.
Si votre FAI ne vous fournit pas d'adresse IP fixe, alors vous pouvez mettre en place un tunnel VPN comme décrit dans cette partie. Votre serveur sera alors accessible au public via l'IP du VPN, l'IP de votre serveur étant "cachée" derriÚre.
Cela s'avĂšre particuliĂšrement utile si :
Voici schématiquement ce que l'on cherche à faire :
+-~sniper~-+ +------~tank~-------+ +--------------+ | | | | | | | Serveur +<------>+ Serveur +<-----+ | | Perso | VPN | point de sortie | | Visiteur | | | | avec IP fixe | | | +----------+ +-------------------+ +--------------+ IP cachée IP Publique
Peu importe l'IP de votre serveur perso, pour y accéder depuis internet, il suffira d'utiliser l'IP publique du serveur point de sortie.
Pour mieux se comprendre ensuite, j'appellerai "sniper" le serveur caché derriÚre le VPN et "tank" le serveur dont on veut utiliser l'IP publique.
â Pensez Ă adapter la configuration de votre pare-feu de votre serveur.
Désormais, le trafic parviendra à votre serveur par l'interface du VPN, c'est-à -dire "wg0" si vous l'avez configuré avec Wireguard ou bien "enc0" si c'est avec Iked. Le plus simple reste de remplacer "egress" par une macro contenant toutes les interfaces à gérer, et y ajouter "wg0" à la liste. Par exemple:
pass in quick on egress proto tcp to port $tcp_pass
devient
ifaces = "{ em0 wg0 }"
pass in quick on $ifaces proto tcp to port $tcp_pass
ou encore : ifaces = "{ egress wg0 }
Notez que vous n'ĂȘtes dans ce cas plus du tout obligĂ© de modifier les routes par dĂ©faut de votre serveur. Il est tout Ă fait possible que votre serveur garde un accĂšs Ă internet par dĂ©faut avec son IP fournie par celle du FAI et soit joignable de l'extĂ©rieur par l'IP de tank. Je trouve mĂȘme cette solution plus simple. Ainsi, pour un VPN wireguard, on pourrait trouver les extraits de configuration suivants.
Sur tank :
# cat /etc/hostname.wg0 inet 10.0.0.1/24 wgkey [..snip..] wgport 4545 wgpeer [...snip...] wgaip 10.0.0.2/32 up # cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 # cat /etc/pf.conf [...] # wireguard tunnel pass in proto udp to port 4545 # no nat-to [...]
Sur sniper :
# cat /etc/hostname.wg0 wgkey [..snip..] wgpeer [..snip..] wgendpoint chezmoi.tld 4545 wgaip 0.0.0.0/0 inet 10.0.0.2/24 up # cat /etc/pf.conf [...] # paranoid commented below # pass in on wg0 from 10.0.0.1 # pass out on wg0 # less paranoid: pass on wg0 [...]
On suppose par la suite que sniper et tank sont reliés par un VPN Wireguard.
Vous n'aurez qu'à éditer le pare-feu de tank pour ajouter quelques rÚgles "nat-to" et "rdr-to". Voici à quoi le résultat final peut ressembler :
Vous n'aurez qu'Ă Ă©diter le pare-feu de tank pour ajouter quelques rĂšgles "nat-to" et "rdr-to" :
https://www.openbsd.org/faq/pf/nat.html
serv_int = "10.0.0.2"
serv_ext = "192.0.2.2"
int_if = "wg0"
ext_if = "egress" # change me maybe
set skip on lo
block
# let vpn on
pass in proto udp to port 4545
pass in on wg0
### REDIRECT TO SNIPER
pass in on $ext_if proto tcp from any to $serv_ext \
rdr-to $serv_int
match out on $ext_if from $serv_int to any \
nat-to $serv_ext static-port
# One can replace the two previous rules with :
# match on $ext_if from $serv_int to any binat-to $serv_ext
match out on $int_if from any to $serv_int \
received-on $ext_if nat-to $int_if
###
pass out
Prenez bien soin de modifier les IP dans les variables serv_* et Ă©ventuellement $ext_if correspondant Ă l'interface publique.
La rĂšgle rdr-to relie ce qui arrive de n'importe oĂč (any) sur l'interface publique (ext_if) pour l'ip de tank ($serv_ext) vers sniper ($serv_int).
Ensuite, la premiÚre rÚgle "nat-to" relie ce qui arrive de sniper ($serv_int vers l'ip de tank $serv_ext) sans modifier le port utilisé (static-port).
Ces deux instructions sont Ă©quivalentes Ă la rĂšgle binat-to donnĂ©e en exemple dans le commentaire. Cette derniĂšre cependant ne permet par de prĂ©ciser des ports, on en parlera ensuite đ.
Ensuite, on précise à nouveau une rÚgle nat-to en sortie afin de bien relier cette fois-ci les interfaces (et non pas les IP).
On termine par laisser passer en sortie.
Remarquez qu'on utilise un match pour les rÚgles sortantes. Cela permet de garder en mémoire la rÚgle pour le paquet correspondant à cette derniÚre et ne pas l'écraser lorsqu'on autorise la sortie à la fin avec le pass out. On aurait pu utiliser des quick, mais je trouve cela moins pratique à la longue.
Rechargez le pare-feu. Et voilĂ , c'est terminĂ© đ.
Certains voudront peut-ĂȘtre plus finement paramĂ©trer leur pare-feu. C'est pour ça que j'ai commentĂ© la ligne binat-to pour l'exemple afin de conserver l'instruction rdr-to qui permet de dĂ©finir quels ports rediriger:
ports_tcp = "{ ssh www https smtp submission imaps domain }"
ports_udp = "{ domain spamd-sync }"
# pass in on $ext_if from any to $serv_ext rdr-to $serv_int
# previous line is replaced by
pass in on $ext_if proto tcp from any to $serv_ext port $ports_tcp rdr-to $serv_int
pass in on $ext_if proto udp from any to $serv_ext port $ports_udp rdr-to $serv_int
[...]
Si vous administrez vos serveurs via SSH, comprenez que vous ne pourrez plus accéder au point de sortie du VPN (l'hÎte) par ce moyen si vous laissez les choses en l'état. En effet, tout est redirigé vers le client.
Sur le serveur, vous devriez alors modifier le port d'écoute SSH par défaut (/etc/ssh/sshd_config) puis ajouter une rÚgle quick dans le pare-feu. Vous aurez alors en haut du pf.conf, avant les redirections du VPN, une rÚgle ressemblant à ceci :
pass in quick on $ext_if proto tcp port 2222 # alternative ssh listening port
DĂ©sormais, dans votre zone DNS, votre nom de domaine doit pointer vers l'IP de tank.
Malgré l'année dans laquelle nous vivons, certains fournisseurs d'accÚs ne proposent toujours pas de connectivité IPv6. Vous pouvez heureusement proposer vos services en IPv6 aprÚs avoir configuré un VPN vers un fournisseur qui en dispose : openbsd.amsterdam, vultr... (voir il y a quelques chapitres la partie "Quelqu'un peut-il héberger OpenBSD pour moi ?").
On va pour cela mettre en place un VPN avec wireguard comme vu précédemment, en y ajoutant la connectivité ipv6 à un client qui n'en dispose pas.
Ce site vous aide à générer une rangée ipv6 privée :
https://simpledns.plus/private-IPv6
Pensez Ă activer l'option d'ip forwarding pour l'ipv6 dans /etc/sysctl.conf:
net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1
Le fichier /etc/hostname.wg0 servant à configurer wireguard doit désormais préciser l'ipv6 du point de sortie du VPN. Ici, c'est fd9c:f774:0bfa:acfc::1/64.
Chaque client doit pouvoir disposer aussi de son ipv6. On ajoute tout simplement une nouvelle option wgaip en plus de l'ancienne. La configuration ressemble alors Ă ceci :
# cat /etc/hostname.wg0 inet 10.0.0.1/24 inet6 fd9c:f774:0bfa:acfc::1/64 wgkey [...snip...] wgport 4545 # peer 1 wgpeer [...snip...] wgaip 10.0.0.2/32 wgaip fd9c:f774:0bfa:acfc::2/128 # peer 2 wgpeer [...snip...] wgaip 10.0.0.3/32 wgaip fd9c:f774:0bfa:acfc::3/128 # peer 3 wgpeer [...snip...] wgaip 10.0.0.4/32 wgaip fd9c:f774:0bfa:acfc::4/128 up
â C'est important que chaque ipv6 des clients soit bien prĂ©cisĂ©e avec Ă la fin "/128".
Dans le fichier /etc/hostname.wg0, on doit ajouter quelques éléments par rapport à précédemment :
La configuration de wireguard ressemble Ă ceci :
# cat /etc/hostname.wg0
wgkey [...snip...]
wgpeer [...snip...] \
wgendpoint <XX.XX.XX.XX> 4545 \
wgaip 0.0.0.0/0 \ # <--- !
wgaip ::0/0 \
wgpka 25
inet 10.0.0.3/24
inet6 fd9c:f774:0bfa:acfc::3/64 # <--- !
wgrtable 1
up
!route add -inet default 10.0.0.1
!route add -inet6 default fd9c:f774:0bfa:acfc::1 # <--- !
Et voilà , vous disposez désormais d'un accÚs ipv6 au travers du VPN.
VĂ©rifiez-le par exemple avec cette commande :
curl -6 https://ifconfig.co
Pour faire la résolution DNS, vous pouvez utiliser un résolveur public. Ce n'est cependant pas trÚs conseillé pour des raisons évidentes de confidentialité.
Le plus simple reste de configurer unboud sur votre serveur afin qu'il accepte de résoudre les noms de domaines pour les clients du VPN.
Sur une machine cliente, il suffira alors de préciser "10.0.0.1" dans /etc/resolv.conf pour utiliser votre résolveur.
Voici en quelques lignes comment cela se présente :
# cat << EOF > /var/unbound/etc/unbound.conf
server:
# listen on VPN's IP
interface: 10.0.0.1
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: ::0/0 refuse
access-control: ::1 allow
# accept requests from the VPN's clients
access-control: 10.0.0.0/24 allow
private-address: 10.0.0.0/24
hide-identity: yes
hide-version: yes
auto-trust-anchor-file: "/var/unbound/db/root.key"
val-log-level: 2
aggressive-nsec: yes
EOF
# rcctl enable unbound
# rcctl start unbound
Notez que vous pouvez filtrer les pubs et ip malveillantes avec unbound ;). Voir pf-badhost et
# unbound-control-setup
cat << EOF >> /var/unbound/etc/unbound.conf
module-config: "respip validator iterator"
rpz:
name: "unbound-adblock"
zonefile: "/var/unbound/db/unbound-adblock.rpz"
rpz-log: yes
rpz-log-name: "unbound-adblock"
remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock
EOF
cat << EOF >> /etc/daily.local
ftp -o- "https://si3t.ch/pub/evils/unbound-adblock.rpz.gz" |\
gzcat > /var/unbound/db/unbound-adblock.rpz && \
unbound-control -q auth_zone_reload unbound-adblock && \
unbound-control -q flush_zone unbound-adblock
EOF
Voir aussi:
https://www.geoghegan.ca/unbound-adblock.html
https://marcocetica.com/posts/wireguard_openbsd/
SSH vous permettra de mettre en place un rapide PROXY pour encapsuler certaines connexions, voire de mettre en place un VPN rudimentaire.
Un tunnel SSH est trĂšs facile Ă mettre en place. Il permet d'apparaĂźtre avec l'IP du serveur sortant.
On supposera que votre serveur dispose d'un accĂšs SSH fonctionnel.
Depuis une machine cliente (votre ordinateur de bureau par exemple), vous entrerez cette commande :
ssh -D 9999 -NT batman@chezmoi.tld
Quelques explications :
Ensuite, toutes les applications peuvent ĂȘtre configurĂ©es pour utiliser un proxy de type SOCKS vers le port 9999.
Par exemple, avec le navigateur Firefox, vous pouvez configurer le proxy dans les préférences "ParamÚtres réseau".
Voir le man ssh(1) partie "SSH-BASED VIRTUAL PRIVATE NETWORKS" :
http://man.openbsd.org/ssh#SSH-BASED_VIRTUAL_PRIVATE_NETWORKS