J'ai découvert que mon FAI (verizon) intercepte tout le trafic DNS sur le port 53.
En utilisant iptables, je veux rediriger tout le trafic de recherche DNS vers une IP et un port spécifiques (5353). Toute tentative de connexion de mon ordinateur à un autre ordinateur sur le port 53 doit être redirigée vers 23.226.230.72:5353.
Pour vérifier le serveur DNS et le port que j'essaie d'utiliser, j'ai exécuté cette commande.
~$ dig +short serverfault.com @23.226.230.72 -p5353
198.252.206.16
Ceci est la règle iptables que j'essaie d'utiliser.
iptables -t nat -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 23.226.230.72:5353
Après avoir ajouté cette règle, toutes les recherches DNS sont introuvables. Les pings du site Web reviennent unknown host
. Les pages Web indiquent «Serveur introuvable».
~$ mtr serverfault.com
Failed to resolve host: Name or service not known
Je veux que mes recherches DNS soient extraites de 23.226.230.72:5353. Comment puis-je faire fonctionner la règle iptables?
MODIFIER
Démonstration d'interception DNS (port 53) par mon FAI. Tracez la sortie de dig à 23.226.230.72 via le port 5353, puis le port 53.
~$ dig +trace stackexchange.com @23.226.230.72 -p5353
; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p5353
;; global options: +cmd
. 86395 IN NS ns7.opennic.glue.
. 86395 IN NS ns4.opennic.glue.
. 86395 IN NS ns3.opennic.glue.
. 86395 IN NS ns5.opennic.glue.
. 86395 IN NS ns2.opennic.glue.
. 86395 IN NS ns10.opennic.glue.
. 86395 IN NS ns1.opennic.glue.
. 86395 IN NS ns6.opennic.glue.
. 86395 IN NS ns8.opennic.glue.
dig: couldn't get address for 'ns8.opennic.glue': no more
~$ dig +trace stackexchange.com @23.226.230.72 -p53
; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p53
;; global options: +cmd
. 7440 IN NS f.root-servers.net.
. 7440 IN NS d.root-servers.net.
. 7440 IN NS j.root-servers.net.
. 7440 IN NS i.root-servers.net.
. 7440 IN NS g.root-servers.net.
. 7440 IN NS k.root-servers.net.
. 7440 IN NS a.root-servers.net.
. 7440 IN NS h.root-servers.net.
. 7440 IN NS e.root-servers.net.
. 7440 IN NS m.root-servers.net.
. 7440 IN NS c.root-servers.net.
. 7440 IN NS b.root-servers.net.
. 7440 IN NS l.root-servers.net.
;; Received 239 bytes from 23.226.230.72#53(23.226.230.72) in 2948 ms
stackexchange.com. 215 IN A 198.252.206.16
;; Received 62 bytes from 192.228.79.201#53(b.root-servers.net) in 116 ms
Mes iptables actuels. iptables-save
~# iptables-save
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*mangle
:PREROUTING ACCEPT [79950528:41742899703]
:INPUT ACCEPT [78748282:41360159554]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85455483:57472640071]
:POSTROUTING ACCEPT [85480442:57475512901]
-A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*nat
:PREROUTING ACCEPT [71:18713]
:INPUT ACCEPT [7:474]
:OUTPUT ACCEPT [109:7855]
:POSTROUTING ACCEPT [109:7855]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -d 172.17.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*filter
:INPUT ACCEPT [78748139:41360144354]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85454926:57472600172]
:fail2ban-ssh - [0:0]
:fail2ban-vsftpd - [0:0]
-A INPUT -p tcp -m multiport --dports 21,20,990,989 -j fail2ban-vsftpd
-A INPUT -p tcp -m multiport --dports 22,6622 -j fail2ban-ssh
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o lxcbr0 -j ACCEPT
-A FORWARD -i lxcbr0 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A fail2ban-vsftpd -j RETURN
COMMIT
iptables rules
ici8.8.8.8
et8.8.4.4
Réponses:
Exécutez toutes ces instructions en tant que root (sudo).
Modifiez ce fichier.
Désactivez DnsMasq en mettant en commentaire la ligne
dns=dnsmasq
. Mettez un#
devant la ligneRedémarrez votre réseau.
Ajoutez ces règles iptables.
la source
Il semble que ce que vous recherchez vraiment, c'est de contrôler ce qui se passe avec vos requêtes DNS.
Je ne suis pas sûr que l'utilisation d'iptables serait ma solution préférée.
Avez-vous pensé à mettre en place un serveur DNS local qui transmet simplement vos demandes à l'hôte et au port que vous souhaitez? Un exemple: en utilisant l'option de redirecteurs bind9, vous pouvez ajouter un port à un redirecteur.
Une telle configuration est beaucoup plus facile à entretenir et à dépanner, et peut être beaucoup plus flexible. Considérez l'avantage du cache, ou considérez simplement le cas où votre serveur DNS externe est en panne. Vous pouvez avoir plusieurs redirecteurs dans votre configuration DNS, mais une seule IP dans les règles iptables ....
Il y a un bon aperçu de la configuration de bind9 dans un tutoriel sur l'océan numérique . Ajoutez simplement le port aux redirecteurs et vous devriez être prêt.
Bind9 ne consomme pas beaucoup de ressources et est facilement configuré (ou au moins: plus facile que iptables :-))
la source
Essaye ça:
Vous devez d'abord activer l'option de transfert dans
Réglez à un la valeur de
Activer les modifications
Enregistrez et exécutez les éléments suivants:
Si vous pouviez spécifier l'interface (-i eth1) dans PREROUTING ou / et out-interfect (-o eth0) IN POSTROUTING pourrait être utile.
REMARQUE: la ligne MASQUARADE est nécessaire tandis que cette masque l'IP de destination avec l'IP principale.
la source
sysctl net.ipv4.ip_forward=1
et les règles iptables. Le DNS fonctionne, mais il est toujours intercepté par mon FAI. Cela m'indique donc que le DNS est toujours envoyé via le port 53.udp
, mais j'ai obtenu les mêmes résultats.Essaye ça:
Cela signifie:
1) Tout utilisateur local contactant le monde vers le port TCP 53 envoie au 23.226.230.72 au port 5353.
2) Identique à 1 mais pour UDP
3) Définissez les informations source sur le paquet sortant comme provenant de nous.
la source
la source
sport
endport
(c'était, apparemment, une erreur dans la réponse de tachomi que battman622 a signalée il y a trois ans , (2) vous avez ajouté une ligne (commande) pourudp
(c'est une amélioration légitime de la réponse de tachomi, mais qui a déjà été mentionnée dans un commentaire … (suite)--to-destination
par--to
. La page de manuel ne dit pas cela--to
et--to-destination
est équivalente; au contraire, il dit qu'il--to
est utilisé avec laNETMAP
cible (par opposition à laDNAT
cible) et que son argument n'inclut pas de numéro de port. (Bien que je remarque que quelques autres réponses utilisent--to
comme vous l'avez fait.) Êtes-vous sûr que cela--to
fonctionne comme vous l'utilisez (avec un numéro de port, avec laDNAT
cible)? … (Suite)--to
mieux que--to-destination
de toute autre manière que la brièveté?