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…
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
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.
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…
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.
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.
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.
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.
Source ?
Le point important concernant DNSSEC est qu’il permet d’authentifier les réponses mais ne fait pas de chiffrement.
Euh, peux-tu explique ce que c’est censé vouloir dire ?
Non, c’est l’inverse : la récursivité, c’est quand le serveur interrogé s’occupe de tout le reste.
Voir le lien cité.
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.
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, avec comme domaine local local.mydomain.com:
le DNS local ne connais pas toto.org donc il va forward vers les serveurs DNS du FAI, disons orange.com (si c’est le FAI que tu as), lui ne connais pas 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
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 parce qu’il a ou pas un enregistrement A (ou pas) www.toto.org.
Un serveur de domaine a toujours un enregistrement NS de son/ses sous-domaine(s), mais l’inverse non.
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
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
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 
Est(ce bien de cette façon que tout est interconnecté?
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
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?
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
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
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.
En fait pas besoin de routage avancé, il suffit de router les adresses déclarées comme forwarders via PC2 avec des routes classiques.
J’ai lu en diagonale, pas trouvé. Peux-tu être plus précis ?
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
?
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.
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;