Bonjour,
Je teste wireguard (qui a l’air plus performant qu’openvpn). Pour le mettre en place, je dois ajouter des règles iptables glanées à gauche et à droite. N’étant pas spécialiste (loin de là), je les poste ici : quelqu’un pourrait-il me les traduire (me les vulgariser) ? Sont-elles nécessaire et à peu près securisées ?
iptables -A INPUT -s 192.168.10.0/24 -p udp --dport 51871 -j ACCEPT
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
La première, on ouvre en entrée pour le sous-réseau wireguard.
wg0, pour ce que j’en comprends, est le périphérique virtuel créé et utilisé pour wireguard mais que fait exactement la chaine FORWARD ?
La dernière est encore plus floue.
C’est mon RPI, étant toujours allumé, il fait,dans ce cas office de « serveur » pour wireguard (pas certain que le terme employé soit exact…). Le but étant d’avoir accès à mon lan depuis l’extérieur au travers un tunnel wireguard.
Je me suis inspiré de ce tuto
Au temps pour moi, erreur de recopie de règle, c’est plutôt :
iptables -A INPUT -p udp --dport 51871 -j ACCEPT
qui autorise les connexions sur le port d’écoute de wireguard.
Cette règle me parait pourtant indispensable, vu que quand je la supprime, la connexion à wireguard ne se fait plus.
Exact. Je comprends donc que ce sont ces règles qui permettent l’accès à mon lan, par exemple à un serveur samba situé sur un autre PC de mon lan.
Sans l’option -s, ça change tout. Je ne voyais pas l’intérêt d’autoriser le port VPN à des adresses privées qui sont probablement celles de ton réseau local.
Et vice versa, accéder à ce qui est à l’autre bout du VPN depuis le LAN.
Si le RPi ne fait pas de partage de connexion internet, à rien. En revanche ça peut être utile s’il fournit l’accès internet aux clients VPN via le LAN, ça peut être utile.
Dsl pour le délai de réponse… Mais je voulais « tester » avec et sans ces règles pour voir.
Dans mon cas, le client wireguard n’a accès aux fichiers samba du lan et à internet (il a dans ce cas, l’ip publique du RPI) qu’avec les 4 règles données plus haut. Elles sont donc toutes visiblement indispensables pour wireguard.
Le masquerading permet ici aux clients wireguard d’utiliser l’ip public du RPi ?
Pour les clients, pas ou wireguard. Wireguard se fiche royalement que les clients aient accès aux partages Samba ou à internet, ce n’est pas son problème.
Si la règle NAT est nécessaire pour accéder au LAN et à internet, c’est que les routes sur les machines de ton LAN sont mal fichues (manque la route de retour vers le préfixe du VPN via la passerelle VPN).
L’adresse IP de son interface eth0, qu’elle soit publique ou privée.
Le RPI est connecté directement à internet avec une adresse IP publique ?
Non, il est derrière ma box, comme le reste de mon LAN. La box (192.168.1.1) fournit des adresses en 192.168.1.* par DHCP . Wireguard utilise des adresses en 192.168.10.* .
Sur mon RPI, eth0 a donc une adresse 192.168.1.6 et wgo est 192.168.10.1.
Je précise aussi que mon RPI fait office de serveur DNS via Unbound pour mon LAN.
La conf de NetworkManager du serveur smb du lan est donc :
IP : 192.168.1.2 (eno1) → obtenue par DHCP grâce à la box
Route par défaut : 192.168.1.1 (box)
DNS : 192.168.1.6 (RPI)
Si je comprends bien, il faut donc ajouter une route dans le NetworkManager des machines de mon LAN ?
Ça se présente ainsi :
