Odkryłem, że mój dostawca usług internetowych (verizon) przechwytuje cały ruch DNS na porcie 53.
Za pomocą iptables chcę przekierować cały ruch związany z wyszukiwaniem DNS do określonego adresu IP i portu (5353). Każda próba połączenia mojego komputera z innym komputerem na porcie 53 powinna zostać przekierowana na 23.226.230.72:5353.
Aby zweryfikować serwer DNS i port, którego próbuję użyć, uruchomiłem to polecenie.
~$ dig +short serverfault.com @23.226.230.72 -p5353
198.252.206.16
To jest reguła iptables, której próbuję użyć.
iptables -t nat -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 23.226.230.72:5353
Po dodaniu tej reguły nie znaleziono wszystkich wyszukiwań DNS. Pingi WWW powracają unknown host
. Strony internetowe mówią „Nie znaleziono serwera”.
~$ mtr serverfault.com
Failed to resolve host: Name or service not known
Chcę, aby moje DNS były wyszukiwane z 23.226.230.72:5353. Jak mogę uruchomić regułę iptables?
EDYTOWAĆ
Demonstracja przechwytywania DNS (port 53) przez mojego dostawcę usług internetowych. Śledź dane wyjściowe z dig do 23.226.230.72 przez port 5353, a następnie 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
Moje obecne iptables. 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
tutaj8.8.8.8
i8.8.4.4
Odpowiedzi:
Wykonaj wszystkie te instrukcje jako root (sudo).
Edytuj ten plik.
Wyłącz DnsMasq, komentując linię
dns=dnsmasq
. Umieść#
przed liniąUruchom ponownie sieć.
Dodaj te iptable reguły.
źródło
Wygląda na to, że to, czego naprawdę chcesz, to kontrolowanie tego, co dzieje się z Twoimi zapytaniami DNS.
Nie jestem pewien, czy preferowanym rozwiązaniem byłoby użycie iptables.
Czy zastanawiałeś się nad utworzeniem lokalnego serwera DNS, który po prostu przesyła żądania do hosta i żądanego portu? Jeden przykład: używając opcji forward9 bind9 możesz dodać port do forwardera.
Taka konfiguracja jest znacznie łatwiejsza w utrzymaniu i rozwiązywaniu problemów i może być znacznie bardziej elastyczna. Rozważ zalety buforowania lub po prostu rozważ przypadek, w którym zewnętrzny serwer DNS jest wyłączony. Możesz mieć wielu forwarderów w konfiguracji DNS, ale tylko jeden adres IP w regułach iptables ...
Dobry przegląd konfiguracji bind9 znajduje się w samouczku na temat oceanu cyfrowego . Po prostu dodaj port do forwarderów i wszystko powinno być gotowe.
Bind9 w ogóle nie zużywa dużo zasobów i jest łatwy do skonfigurowania (a przynajmniej: łatwiejszy niż iptables :-))
źródło
Spróbuj tego:
Najpierw musisz włączyć opcję przekazywania w
Ustaw na wartość 1
Włącz zmiany
Zapisz i uruchom następujące:
Jeśli możesz podać interfejs (-i eth1) w PREROUTING lub / i out-interfect (-o eth0), IN POSTROUTING może być przydatne.
UWAGA: Konieczna jest linia MASQUARADE, która maskuje docelowy adres IP głównym adresem IP.
źródło
sysctl net.ipv4.ip_forward=1
i reguły iptables. DNS działa, ale nadal jest przechwytywany przez mój ISP. To mi wskazuje, że DNS jest nadal wysyłany przez port 53.udp
, ale mam te same wyniki.Spróbuj tego:
Oznacza to:
1) Każdy użytkownik lokalny łączący się ze światem w celu przesłania portu tcp 53 na numer 23.226.230.72 na porcie 5353.
2) Taki sam jak 1, ale dla udp
3) Ustaw informacje o źródle na wychodzącym pakiecie jako pochodzące od nas.
źródło
źródło
sport
, abydport
(było najwyraźniej błąd w odpowiedzi tachomi że battman622 wskazał trzy lata temu , (2) dodano linię (komend) doudp
(jest to uzasadniona poprawa odpowiedzi tachomi, ale taka, o której wspomniano już w komentarzu … ( ciąg dalszy )--to-destination
się--to
. Strona podręcznika tego nie mówi--to
i--to-destination
są równoważne; wręcz przeciwnie, mówi, że--to
jest używany zNETMAP
celem (w przeciwieństwie doDNAT
celu) i że jego argument nie zawiera numeru portu. (Chociaż zauważam, że kilka innych odpowiedzi używa--to
tego, co zrobiłeś.) Czy jesteś pewien, że--to
działa tak, jak go używasz (z numerem portu, zDNAT
celem)? … (Ciąg dalszy)--to
lepszy niż--to-destination
jakikolwiek inny sposób niż zwięzłość?