A propos de la solution wireguard suggérée par NoSpam.
J'ai lu beaucoup de bonnes choses sur wireguard. Je me suis lancé.
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-tunnelil est indiqué d'installer resolvconf :
$ sudo apt install resolvconf
ça m'a planté mon resolv.conf qui était géré par NM = plus d'accès à internet.
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 :
Cet article compare
resolv.conf,
systemd-resolve, and Avahi (mais pas resolvconf) et semble indiquer qu'il faut en choisir un...
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.
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-spam@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.
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"
<no-spam@tootai.net>
À: "Liste Debian"
<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
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
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.