# Router le traffic d'un PC du LAN par VPN **URL:** \ **Category:** Support Debian\ **Created:** [Décembre 21, 2020, 9:50 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585 "2020-12-21T09:50:34Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 21, 2020, 8:21 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/21 "2020-12-21T20:21:16Z")
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE iptables v1.8.2 (nf\_tables): Chain ‹ MASQUERADE › does not exist Pour cette erreur, sur github, ils ont dit à un internaute Try `update-alternatives –config iptables… ---
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 21, 2020, 8:31 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/22 "2020-12-21T20:31:04Z")
sudo update-alternatives --config iptables There are 2 choices for the alternative iptables (providing /usr/sbin/iptables). Selection Path Priority Status - 0 /usr/sbin/iptables-nft 20 auto mode 1 /usr/sbin/iptables-legacy 10 manual mode 2 /usr/sbin/iptables-nft 20 manual mode Press to keep the current choice[\*], or type selection number: 1 update-alternatives: using /usr/sbin/iptables-legacy to provide /usr/sbin/iptables (iptables) in manual mode A tester demain ---
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 22, 2020, 10:01 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/24 "2020-12-22T10:01:19Z")
Enfin ça marche. Merci beaucoup PascalHambourg et Zargos pour votre aide. En définitif, j’ai fait : Sur PC1 : ip route add default via 192.168.1.2 table VPN\_PC2 (apès déclaration du nom dans /etc/iproute2/rt\_tables) Après l’ajout de cette route, tcpdump a montré que les paquets ne s’arretent plus à wlp3s0. ip route add 192.168.1.0/24 dev eth1 table VPN\_PC2 (pour ne pas envoyer vers PC2 les paquets destinés à d’autres machines de ce réseau) ip rule add from 192.168.2.3 table VPN\_PC2 (règle de routage avancé basée sur l’adresse source --\> router tout le traffic de PC3 sur PC2) Sur PC2 : sysctl -w net.ipv4.ip\_forward=1. iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE. Cela a fonctionné après cette dernière commande. Suite : J’ai remarqué que certains paquets https sont rejetés par le firewall (wifi2loc:REJECT:IN=wlp3s0 OUT=eth1), bien que les applis sur PC3 fonctionnent bien. Je ne sais pas pourquoi… J’ai alors rajouté les 2 règles : iptables -I FORWARD -i wlp3s0 -o eth1 -s 192.168.2.3 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -I FORWARD -o wlp3s0 -i eth1 -d 192.168.2.3 -m state --state ESTABLISHED,RELATED -j ACCEPT. ---
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 29, 2020, 3:28 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/25 "2020-12-29T15:28:17Z")
Bonjour, Je reprends ce fil pour demander, si possible, comment faire pour router vers PC2, les requettes DNS qui sont générées sur PC3. Pour rappel, PC1 est la passerelle vers Internet. PC2 et PC3 sont sur deux réseaux différents. Pour l’instant, les packets HTTP et HTTPS sont bien routés de PC3–\>PC2 via PC1. Mais les requettes DNS sont résolues via BIND9 qui est sur PC1. c’est donc celles-ci que j’aimerai router vers PC2. Une autre question, est-il possible ou faisable de chiffrer les requettes qu’envoie bind aux serveurs racine ? Bien entendu, j’ai fais un tas de tests et recherches sur Internet sans succès… ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 3:57 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/26 "2020-12-29T15:57:03Z")
> [@Franck\_FR](#): > > Pour l’instant, les packets HTTP et HTTPS sont bien routés de PC3–\>PC2 via PC1. > Mais les requettes DNS sont résolues via BIND9 qui est sur PC1. c’est donc celles-ci que j’aimerai router vers PC2. Les paquets HTTP(S) sont destinés à des adresses extérieures et donc routés par la route par défaut. Si les paquets de requêtes DNS sont destinés à PC1, il n’y a aucune raison qu’ils soient routés par PC1 vers PC2. Le routage local est prioritaire et cela ne peut être changé. Pour router les requêtes DNS vers PC2, il faut les destiner à des adresses de serveurs DNS extérieurs, au choix - en définissant ces adresses de DNS dans /etc/resolv.conf sur PC3 - ou en appliquant du NAT destination (DNAT) des paquets DNS de PC3 pour les rediriger vers ces adresses avec iptables - ou en définissant ces adresses comme « forwarders » pour les requêtes DNS de PC3 dans la configuration de BIND9 sur PC1 et en les routant via PC2 Il y a sûrement encore d’autre possibilités. > [@Franck\_FR](#): > > est-il possible ou faisable de chiffrer les requettes qu’envoie bind aux serveurs racine ? Pourquoi spécifiquement aux serveurs racine ? Ils ne servent qu’à fournir les DNS des TLD (domaines de premier niveau comme .com, .net, .org, .fr…). Tu veux dire aux serveurs faisant autorité, dont ils ne constituent qu’une toute petite partie (bien qu’essentielle) ? A ma connaissance, ce n’est pas possible. Il existe plusieurs protocoles de chiffrement des requêtes DNS plus ou moins normalisés (DNSCrypt, DNS over HTTPS, DNS over TLS, DNSCurve…), mais je ne pense pas qu’ils soient supportés par les serveurs autoritaires officiels, seulement par des serveurs caches récursifs. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 4:06 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/27 "2020-12-29T16:06:59Z")
Les requêtes DNS sur Internet ne sont pas chiffrées. DNSSEC n’est fait que pour protéger les données échangées entre les serveur, pas pour protéger les requetes clients. > **[What is DNSSEC?](https://www.efficientip.com/what-is-dnssec/)** > > The Domain Name System Security Extensions suite is used to strengthen DNS protocol security because the DNS protocol is by design not secure. Normallement, dans ton architecture tu ne devrait avoir qu’un serveur serveur DNS (enfin, éventuellement un primaire et un secondaire, mais vu le nombre de poste c est pas utile). Les machines interne de ton réseau local, font leurs requetes sur ton serveur DNS local. Si ces requetes ne sont pas resolvable par ton DNS local, alors celui-ci « forward » les requêtes vers un DNS de niveau supérieur: A l’allé: my.domain1.tld1 -\> forward -\> domain1.tld1 -\> forward -\> .tld1 -\> forward -\> . (root) -\> NS -\> .tld2 -\> NS -\> domain2.tld2 -\> NS -\> his.domain2.tld2 Au retour, ca depend du mode de reponse (avec ou sans recusivité), car s’il y a récursivité, chaque réponse revient d’abord au demandeur qui pose la question suivante et ainsi de suite. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 4:46 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/28 "2020-12-29T16:46:00Z")
> [@Zargos](#): > > DNSSEC n’est fait que pour protéger les données échangées entre les serveur, pas pour protéger les requetes clients. Source ? Le point important concernant DNSSEC est qu’il permet d’authentifier les réponses mais ne fait pas de chiffrement. > [@Zargos](#): > > A l’allé: > my.domain1.tld1 → forward → domain1.tld1 → forward → .tld1 → forward → . (root) → NS → .tld2 → NS → domain2.tld2 → NS → his.domain2.tld2 Euh, peux-tu explique ce que c’est censé vouloir dire ? > [@Zargos](#): > > s’il y a récursivité, chaque réponse revient d’abord au demandeur qui pose la question suivante et ainsi de suite. Non, c’est l’inverse : la récursivité, c’est quand le serveur interrogé s’occupe de tout le reste. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 5:18 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/29 "2020-12-29T17:18:43Z")
> [@PascalHambourg](#): > > Source ? Voir le lien cité. > [@PascalHambourg](#): > > Non, c’est l’inverse : la récursivité, c’est quand le serveur interrogé s’occupe de tout le reste. Arf.. me trompe une fois sur deux. et c’est logique, car le plus souvent les DNS publiques ne sont pas recursif pour eviter les DDOS. > [@PascalHambourg](#): > > Euh, peux-tu explique ce que c’est censé vouloir dire ? Le PC fait une requete host.domain1.tld1. Le PC fait cette requete au serveur local, si le PC ne peux pas repondre à la question, il forward celle-ci vers le noeud DNS au dessus supérieur, et ainsi de suite jusqu’au serveurs racines. Qui ensuite redescendent la requete vers les NS: . → tld → domain → subdomain Donc pour par exemple [www.toto.org](http://www.toto.org), avec comme domaine local [local.mydomain.com](http://local.mydomain.com): le DNS local ne connais pas [toto.org](http://toto.org) donc il va forward vers les serveurs DNS du FAI, disons [orange.com](http://orange.com) (si c’est le FAI que tu as), lui ne connais pas [toto.org](http://toto.org), va renvoyer la requete au serveur gérant le tld .org (via les indormations des serveurs ROOT que tous les serveurs DNS ont). .org connait toto, donc il lui envoie la requête parce qu’il a un enregistrement NS [toto.org](http://toto.org) [toto.com](http://toto.com) connait (ou pas ) www, il renvoie la réponse ou un message d’erreur disant qu’il n’y a pas de [www.toto.com](http://www.toto.com) parce qu’il a ou pas un enregistrement A (ou pas) [www.toto.org](http://www.toto.org). Un serveur de domaine a toujours un enregistrement NS de son/ses sous-domaine(s), mais l’inverse non. ---
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 29, 2020, 6:37 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/30 "2020-12-29T18:37:06Z")
Merci pour toutes ces explications. - J’ai rajouté un NS exterieur dans resolv.conf (qui sera ecrasé à la prochaine requette dhcp). - J’ai appliqué DNAT PC3–\>PC2 udp 53 - J’ai rajouté l’adresse du NS extérieur comme forwarder dans /etc/bind/named.conf.options > Citation > [@PascalHambourg](#): > > en faisant du routage avancé des paquets émis localement par PC1 destinés à ces adresses J’ai tenté d’adapter les règles citées plus haut dans le fil mais sans succès. Les requettes DNS ne passent pas de eth0 vers tun0, du PC2. tcpdump -i eth0 udp port 53 montre bien les requettes tcpdump -i tun0 udp port 53 rien ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 7:06 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/31 "2020-12-29T19:06:51Z")
Il aurait été intéressant d’avoir un architecture claire de ce que tu veux faire, indépendamment de toute forme de routage, de nat, dnat, et autres règles techniques qui ne viennent qu’une fois le besoin clairement exprimé indépendamment des techniques 😉 Car sauf erreur, ça ressemble un peu à une usine à gaz 🙂 ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 7:18 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/32 "2020-12-29T19:18:42Z")
Est(ce bien de cette façon que tout est interconnecté? ```auto +--------+ +--------+ +--------+ +--------+ | | | | | | | | Internet --------| BOX |--------| SW |--------| PC1 |<-----WIFI---->| PC3 | | FAI | | | | DNS | | | +--------+ +--------+ +--------+ +--------+ | +--------+ | | | +------------| PC2 | | | +--------+ ``` Et auquel cas, le VPN de PC2 est relié à quoi? quelle est l’autre extrémité de ton VPN? ---
**Author:** ![Franck\_FR](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/e47774/32.png) [@Franck\_FR](https://www.debian-fr.org/u/Franck_FR)\ **Post date:** [Décembre 29, 2020, 7:20 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/33 "2020-12-29T19:20:12Z")
> [@Zargos](#): > > Il aurait été intéressant d’avoir un architecture claire de ce que tu veux faire l’essentiel est dans le tout premier poste. Je viens de voir ton shéma. c’est bien ça (je vérifierai juste ou est placé le switch); A l’origine il n’y avait pas de PC2 ni switch , puis avec le temps, j’ai rajouté PC2 qui est dédié pour aller chercher les certificats https(Let’s Encrypt). puis rajouté le VPN pour tester. Je vais retirer le VPN de PC2 et faire autrement ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 8:33 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/34 "2020-12-29T20:33:38Z")
Oui car je ne vois pas l’utilité de ton VPN en fait. Si PC1 sert de routeur à PC3, avec un ip\_forwad, alors ton PC3 accède sans probleme à ton PC2, si les règles de parefeu de PC2 le permette, sans avoir à faie un NAT quelconque, vu que PC1 est aussi la passerelle de PC2. Personnellement j’aurais plutot mis PC1 entre la box et le switch, et PC2 sur le switch, ca aurait ete plus logique, car la sécurité de PC1 vis à vis de PC2 ne sert à rien. Et de fait, tu peux supprimer ton switch en reliant directement les deux PC1 et PC2 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 10:09 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/35 "2020-12-29T22:09:32Z")
> [@Franck\_FR](#): > > - J’ai rajouté un NS exterieur dans resolv.conf (qui sera ecrasé à la prochaine requette dhcp). > - J’ai appliqué DNAT PC3–\>PC2 udp 53 > - J’ai rajouté l’adresse du NS extérieur comme forwarder dans /etc/bind/named.conf.options Tout en même temps ? C’était l’un ou l’autre, pas les trois à la fois. Et le DNS ne doit pas rediriger vers l’adresse de PC2 mais vers l’adresse d’un DNS extérieur accessible via le VPN. Si tu rediriges vers l’adresse de PC2 et que ce dernier n’a pas de serveur DNS récursif, les requêtes ne sont pas traitées et ne vont pas plus loin. > [@Franck\_FR](#): > > J’ai tenté d’adapter les règles citées plus haut dans le fil mais sans succès. Les requettes DNS ne passent pas de eth0 vers tun0, du PC2. En fait pas besoin de routage avancé, il suffit de router les adresses déclarées comme forwarders via PC2 avec des routes classiques. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 10:16 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/36 "2020-12-29T22:16:16Z")
> [@Zargos](#): > > Voir le lien cité. J’ai lu en diagonale, pas trouvé. Peux-tu être plus précis ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 10:18 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/37 "2020-12-29T22:18:24Z")
DNSSEC helps prevent DNS attacks like DNS cache poisoning and DNS spoofing. DNSSEC does not protect the entire server, it only protects the data exchanged between signed zones. For memory, DNSSEC is not providing privacy. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 10:26 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/38 "2020-12-29T22:26:22Z")
> [@Zargos](#): > > DNSSEC helps prevent DNS attacks like DNS cache poisoning and DNS spoofing. DNSSEC does not protect the entire server, it only protects the data exchanged between signed zones. For memory, DNSSEC is not providing privacy. En quoi cela dit-il que > [@Zargos](#): > > DNSSEC n’est fait que pour protéger les données échangées entre les serveur, pas pour protéger les requetes clients. ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 10:40 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/39 "2020-12-29T22:40:07Z")
> [@Zargos](#): > > it only protects the data exchanged between signed zones en plus literal « DNSSEC protège uniquement les données échangées entre les zones signées » (donc incidement entre les serveurs vu que deux zones ne communiquent pas entre elles autrement. et en literal aussi « Pour mémoire, DNSSEC n’assure pas l’intimité », qu’on peut aussi traduire « DNSSEC ne fournit pas de confidentialité ». reverso est ton ami. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 29, 2020, 10:59 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/40 "2020-12-29T22:59:58Z")
Ton interprétation est erronée. A ta décharge, c’est très mal exprimé : « données échangées entre zones », ça ne veut rien dire. Les zones n’échangent pas de données, ce sont elles les données. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Décembre 29, 2020, 11:12 UTC](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585/41 "2020-12-29T23:12:14Z")
> [@PascalHambourg](#): > > Ton interprétation est erronée. A ta décharge, c’est très mal exprimé : « données échangées entre zones », ça ne veut rien dire. Les zones n’échangent pas de données, ce sont elles les données. Tout à fait c’est pour ça que j’ai parlé plutot de serveur. en fait le système DNSSEC permet entre deux serveurs d’assurer la confiance des données. C’est le mot le plus proche en français. Ça permet d’établir entre les interlocuteurs des relations de confiance sur les données échangées; [Page précédente](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585.md?page=1) [Page suivante](https://www.debian-fr.org/t/router-le-traffic-dun-pc-du-lan-par-vpn/83585.md?page=3)