A propos de la solution wireguard suggérée par NoSpam. J'ai lu beaucoup de bonnes choses sur wireguard. Je me suis lancé.
La doc officielle [ https://www.wireguard.com/quickstart/ | https://www.wireguard.com/quickstart/ ] m'a paru trop courte et un peu floue. Le tuto [ https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04 | https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04 ] m'a bien aidé. Elle semble confirmer que la doc quickstart de wg est légère pour les débutants. J'ai configuré wg sur un serveur. J'ai ensuite configuré wg sur mon poste de travail (géré par Network-manager, qui génère /etc/resolv.conf ; ce qui m'a causé les problèmes attendus avec resolv.conf - voir plus loin). La configuration de wg apparaît différente et un peu plus simple qu'avec Openvpn (surtout quand on doit ajuster le fichier de config openvpn). Chaque pair/peer doit générer une paire de clef privée/publique en Base64 ; et il faut déclarer un pair/client sur le serveur par sa clef publique et son adresse IP par une commande : sudo wg set wg0 peer tFxQ25iWwGMgHuCFplWeXcrSnBpRcdfQSNnA4UVpXzg= allowed-ips 10.8.0.2 Ce serait bien de pouvoir utiliser un fichier de conf des clients. A suivre. PROBLEME 1/ : Résolution des noms sur mon poste de travail J'ai buté sur ma configuration réseau, avec un resolv.conf cassé puis réparé. Dans le tuto [ https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel | https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel ] il est indiqué d'installer resolvconf : [ https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel ] $ sudo apt install resolvconf ça m'a planté mon resolv.conf qui était géré par NM = plus d'accès à internet. J'ai cru trouver une solution avec [ https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ | https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ ] qui proposait aussi d'installer resolvconf, comme dans le tuto digitalocean sur wireguard : $ sudo apt install resolvconf Mais il recommandait aussi d'installer systemd-resolved et de démarrer les DEUX services : $ sudo systemctl restart resolvconf.service $ sudo systemctl restart systemd-resolved.service Dans mon cas, seulement démarrer resolvconf.service rétablissait mon resolv.conf tandis que démarrer ensuite systemd-resolved.service le cassait immédiatement ! J'en ai conclu qu'il fallait l'un ou l'autre et ait conservé seulement resolvconf.service (et ai désactivé systemd-resolved) D'ailleurs, certains se sont posé la question : [ https://askubuntu.com/questions/1181346/systemd-resolved-and-resolvconf-is-it-ok-to-have-both-installed | https://askubuntu.com/questions/1181346/systemd-resolved-and-resolvconf-is-it-ok-to-have-both-installed ] Cet article compare resolv.conf , [ https://manpages.ubuntu.com/manpages/xenial/en/man1/systemd-resolve.1.html | systemd-resolve ] , and Avahi (mais pas resolvconf) et semble indiquer qu'il faut en choisir un... [ https://www.baeldung.com/linux/resolve-conf-systemd-avahi | https://www.baeldung.com/linux/resolve-conf-systemd-avahi ] Je rappelle que j'utilise NM sur mon poste de travail debian 11. Ma question : Faut-il bien choisir resolvconf ou bien systemd-resolved ? Et lequel privilégier ? PROBLEME 2/ : Finir la configuration de wireguard Je crois avoir fait le plus gros : le serveur tourne, le client semble lancé d'après le serveur et le client (sauf interface wg0 en state UNKNOWN) La configuration est faite pour envoyer tout le traffic dans le tunnel vpn. Mais impossible de faire un ping du serveur vpn malgré la configuration du serveur autorisant les pings entrants (sauf bêtise...) Et impossible de naviguer avec un navigateur ou en CLI quand j'ai démarré le client wg. Seul le ping vers le serveur avec son adresse IP publique fonctionne (ainsi, seule passe la connexion mosh vers le serveur où tourne wg) CLIENT $ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.8.0.2/24 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] resolvconf -a tun.wg0 -m 0 -x [#] ip rule add table 200 from 192.168.1.153 [#] ip route add table 200 default via 192.168.1.153 $ ip addr show wg0 37: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 10.8.0.2/24 scope global wg0 valid_lft forever preferred_lft forever indice : state UNKNOWN ça indique peut-être un truc qui cloche... SERVEUR Il voit le client taper à la porte ou alors tente de taper à sa porte : $ sudo wg interface: wg0 public key: 3e2/5eGWQvJjs7wbTdOnCwJOoB8JLDN909xYZrdlIzE= private key: (hidden) listening port: 51820 peer: tFxQ25iWwGMgHuCFplWeXcrSnBpRcdfQSNnA4UVpXzg= endpoint: (IP_PUBLIQUE_CLIENT_LAN):38408 allowed ips: 10.8.0.2/32 transfer: 296 B received, 184 B sent Quand on fait sur le client : $ sudo wg-quick down wg0 sur le serveur, on voit alors toujours la même chose. Du coup, je ne sais pas trop si le client est vraiment connecté au serveur vpn... Voilà ce que j'ai configuré sur le serveur wg : $ cat /etc/wireguard/wg0.conf [Interface] Address = 10.8.0.1/24 SaveConfig = true PostUp = ufw route allow in on wg0 out on eth0 PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE PostUp = iptables -A OUTPUT -p icmp -j ACCEPT PostUp = iptables -A INPUT -p icmp -j ACCEPT PreDown = ufw route delete allow in on wg0 out on eth0 PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE PreDown = iptables -A OUTPUT -p icmp -j DROP PreDown = iptables -A INPUT -p icmp -j DROP ListenPort = 51820 PrivateKey = (hidden) Voici le réglage du FW $ sudo ufw allow 51820/udp # wg $ sudo ufw allow OpenSSH # ssh $ sudo ufw allow 60001:60999/udp #mosh $ sudo ufw disable $ sudo ufw enable $ sudo ufw status Status: active To Action From -- ------ ---- 51820/udp ALLOW Anywhere OpenSSH ALLOW Anywhere 60001:60999/udp ALLOW Anywhere 51820/udp (v6) ALLOW Anywhere (v6) OpenSSH (v6) ALLOW Anywhere (v6) 60001:60999/udp (v6) ALLOW Anywhere (v6) Anywhere on eth0 ALLOW FWD Anywhere on wg0 Anywhere (v6) on eth0 ALLOW FWD Anywhere (v6) on wg0 J'allais envoyer ma question : "Voyez-vous ce que j'ai loupé ? Merci." Mais avant, je fais un dernier essai en reprenant les étapes de la vidéo de démo de wg : CLIENT sudo ip addr add 10.8.0.2/24 dev wg0 sudo wg set wg0 private-key /etc/wireguard/private.key sudo ip link set wg0 up sudo wg set wg0 peer 3e2/5eGWQvJjs7wbTdOnCwJOoB8JLDN909xYZrdlIzE= allowed-ips 10.8.0.1/32 endpoint (adr_IP_serveur):51820 SERVEUR Au pif, je décide de pas faire les 'ip link add...' car l'interface wg0 est déjà présente... sudo wg set wg0 peer tFxQ25iWwGMgHuCFplWeXcrSnBpRcdfQSNnA4UVpXzg= allowed-ips 10.8.0.2/32 endpoint (adr_IP_publique_client):51820 # au pif pour (adr_IP_publique_client):51820, et sans routage de port sur mon routeur... ping SERVEUR (10.8.0.1/24) vers CLIENT (10.8.0.2/24) $ ping -c 3 10.8.0.2 PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data. 64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=6.78 ms 64 bytes from 10.8.0.2: icmp_seq=2 ttl=64 time=3.91 ms 64 bytes from 10.8.0.2: icmp_seq=3 ttl=64 time=4.57 ms --- 10.8.0.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 3.909/5.087/6.783/1.228 ms Tiens ! ping CLIENT (10.8.0.2/24) vers SERVEUR (10.8.0.1/24) $ ping -c3 10.8.0.1 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=5.10 ms 64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=4.24 ms 64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=4.40 ms --- 10.8.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 4.238/4.580/5.104/0.375 ms Super ! Le réseau vpn wireguard semble opérationnel. J'ai bien fait de regarder les étranges instructions en vidéo sur [ https://www.wireguard.com/quickstart/ | https://www.wireguard.com/quickstart/ ] (celles en CLI sont un peu différentes et troublantes) Il reste quelques points à traiter sur wg : a/ Comment router tout le traffic de mon poste de travail dans le tunnel ? (il est toujours vu comme étant derrière son routeur domestique...) b/ Quel intérêt y a-t-il encore à utiliser Squid si wg est capable de router le trafic et de le relayer ? (oui, les acl...) c/ Pourquoi "state UNKNOWN" apparaît dans l'interface wg0 et pas "UP" ? d/ Comment utiliser wg côté client sans ligne de commande ? (sur le serveur, ça va, mais tout utilisateur ordinaire voudra une applet ou une commande appelable par une icône ) e/ comment utiliser sur le serveur une liste d'adr IP et de clefs publiques des clients ? Merci. De: "NoSpam" <no-s...@tootai.net> À: "Liste Debian" <debian-user-french@lists.debian.org> Envoyé: Dimanche 9 Juillet 2023 18:08:15 Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel? Il te faut du marquage aussi via nftables ou iptables. Wireguard est effectivement alternatif à openvpn, mais plus rapide, plus facile à configurer, technologie récente proche du noyau. Le 09/07/2023 à 17:23, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a écrit : Merci. Je vais d'abord plancher sur iproute2 puisque c'est la norme. wireguard : je croyais que c'était juste un vpn alternatif à openpvn ou autre. A creuser pour moi. De: "NoSpam" [ mailto:no-s...@tootai.net | <no-s...@tootai.net> ] À: "Liste Debian" [ mailto:debian-user-french@lists.debian.org | <debian-user-french@lists.debian.org> ] Envoyé: Dimanche 9 Juillet 2023 17:00:14 Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel? Cela s'appelle du routage, iproute2 installé d'office, fait cela en faisant du marquage. Sinon wireguard permet également de router via sa configuration Le 09/07/2023 à 14:11, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a écrit : BQ_BEGIN Bonjour, Je peux me connecter à un serveur openvpn en CLI (sudo openvpn truc.conf) ou par le GUI (gnome VPN settings : clic). Je vois cette connexion client sur le serveur (10.0.0.x). $ ip addr 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0 valid_lft forever preferred_lft forever inet6 2a02:.................................... /64 scope global dynamic noprefixroute valid_lft 604402sec preferred_lft 604402sec inet6 fe80::.................../64 scope link noprefixroute valid_lft forever preferred_lft forever ... 21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::................................./64 scope link stable-privacy valid_lft forever preferred_lft forever Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me tirer d'un problème de connexion. Avec nmcli. Ça fonctionne bien ainsi depuis des années. Malgré le tunnel, depuis un autre terminal ou depuis un navigateur ma machine a toujours la même adresse IP (celle publique fournie par mon opérateur), bien que je sois connecté au vpn. Je suis autonome en réseau pour des choses ordinaires . Là c'est plus compliqué... Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la machine dans le VPN (sans les certificats) client remote $REMOTE_IP 6504 proto udp nobind dev-type tun pull dev tun0 redirect-gateway auth-user-pass login.txt auth-retry interact fragment 1452 mssfix 1452 explicit-exit-notify 3 remote-cert-tls server verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" cipher AES-256-CBC Et celui qui ne fait pas ce que j'attends : dev tun tls-client remote $REMOTE_IP 1195 pull proto udp script-security 2 comp-lzo reneg-sec 0 cipher AES-256-CBC auth SHA512 auth-user-pass Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn. Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser. Je me dis que le problème vient de ce fichier de configuration openvpn. Je fouille donc du côté d'openvpn "Comment router tout le trafic d'une machine dans un tunnel openvpn"... Résultat : Il se pourrait que ce soit la directive suivante qui permette de router tout le trafic dans le tunnel vpn : redirect-gateway ou redirect-gateway def1 Ou push "redirect-gateway" push "redirect-gateway def1" Qu'en pensez-vous ? Quelle est la manière de faire ça proprement ? - sans modifier le fichier .opvpn fourni - en le modifiant a minima (ex : ajouter la directive redirect-gateway ) Je vais plus loin : J'ai souvent besoin de me connecter à diverses machines en CLI ou avec un navigateur via un tunnel. Je sais faire ça successivement mais pas simultanément. Je veux éviter de devoir gérer successivement chaque tunnel unique. J'ai aussi des connexions RDP actives qui doivent rester hors des tunnels. Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou telle fenêtre de navigateur dans le tunnel ssh/vpn qui LUI correspond, sans toucher au trafic des autres connexions (RDP, etc.) ? Ça c'est du vrai réseau, pas ordinaire (pour moi)...! Merci. BQ_END
