Temat: Przekierowanie zapytań dns na lokalny serwer
Witam
Chciałem zmusić komputery podłączone do routera(openwrt) aby zabytania szły na opendns.

Takie moje rozwiązanie ma prawo działać ?
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Przekierowanie zapytań dns na lokalny serwer
Zaloguj się lub zarejestruj by napisać odpowiedź
Witam
Chciałem zmusić komputery podłączone do routera(openwrt) aby zabytania szły na opendns.

Takie moje rozwiązanie ma prawo działać ?
Chyba chciałeś wpisać do dowolny port w wan i dowolny ip w wan - to, żeby zapytania szły do opendns określasz w konfiguracji wan (option dns <ip opendns> i option peerdns 0) i ustawiasz 192.168.1.1 jako jedyny serwer DHCP w lanie (wtedy zapytania nie przedrą się gdziekolwiek indziej bo właśnie tą regułą zablokowałeś port do takich zapytań z jakiegokolwiek adresu w lan do jakiegokolwiek ip w wan na jakimkolwiek porcie). Poza tym chcąc jeszcze bardziej zabezpieczyć zapytania, aby nie paść np. ofiarą phishingu, robisz jak szifo Cezary poleca http://eko.one.pl/?p=openwrt-dnscrypt . ![]()
Nie trzeba robić żadnej reguły dla adresu 192.168.1.1 - to jest domyślnie ustawiane w lan. Dodatkowo możesz też tam ustawić krótką strefę DHCP, a adresy w lanie jako statyczną dzierżawę spoza zakresu jedynego (192.168.1.1) DHCP w lan - i wtedy jesteś już full zabezpieczony na okoliczność portu 53 i 68 (ich domyślnej funkcjonalności w wielu programach - np. windows czy nas już Ci nie wywinie numeru szukając zazwyczaj dnsów i dhcp przez jakieś wirtualne prywatne adresy domyślne). ![]()
Trzymasz, że tak powiem, całą automatykę w przeróżnych urządzeniach sieciowych w LAN za pysk... ![]()
Witam
Chciałem zmusić komputery podłączone do routera(openwrt) aby zabytania szły na opendns.
Takie moje rozwiązanie ma prawo działać ?
iptables -t nat -I PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 208.67.222.222
iptables -t nat -I PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 208.67.222.222
?
Samo wymuszenie bez blokady szeregu portów (w tym 443) i adresów raczej na nic się zda -- co w takim przypadku:
Proxying from 127.0.2.1:53 to 208.67.220.220:443Można by blokować/przekierować port źródłowy ale to tak samo można sobie zmienić na dowolny.
Co do tych regułek iptables, przetestowałem, zlicza ale jak zweryfikować do jakiego servera DNS poszło zapytanie?
Np. narzędzia takie jak dig, czy nslookup zwracają odpowiednio:
$ dig debug.opendns.com txt
...
;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat May 09 10:15:48 CEST 2015
;; MSG SIZE rcvd: 235 $ nslookup wp.pl
Server: 8.8.8.8
Address: 8.8.8.8#53
...W tablicy conntracka są wpisy tupu:
ipv4 2 udp 17 18 src=192.168.1.150 dst=8.8.8.8 sport=57352 dport=53 packets=1 bytes=69 src=208.67.222.222 dst=82.160.x.x sport=53 dport=57352 packets=1 bytes=85 mark=0 use=2
ipv4 2 udp 17 27 src=192.168.1.150 dst=8.8.8.8 sport=53153 dport=53 packets=1 bytes=69 src=208.67.222.222 dst=82.160.x.x sport=53 dport=53153 packets=1 bytes=97 mark=0 use=2Niby z tego wychodzi, że zapytanie miało iść na 8.8.8.8 z lokalnego hosta ale odpowiedź przyszła z adresu opendns -- czyli wychodzi na to, że działa. Pytanie czemu te powyższe narzędzia zwracają dnsy googla zamiast opendns?
Poza tym, jak ktoś już korzysta z opendns, to niech sobie zaprzęgnie dnscrypt-proxy i przekieruje zapytania DNS z sieci na router, tak by szły one do opendns szyfrowanym tunelem.
cezary te 2 linijki w konsoli mam wpisać.
Trzeba jakoś te zmiany zapisać ??
Np. dodać do /etc/firewall.user
(...)
Pytanie czemu te powyższe narzędzia zwracają dnsy googla zamiast opendns?
(...)
Bo to jest określone w skrypcie w uproszczony sposób - nie bada przedtem skrypt skąd faktycznie idzie odpowiedź, tylko jedynie umie rozpoznać, że albo odpowiedź była, wtedy "podaj w wyniku zapytania to o co było pytane", albo wcale i w wyniku "komunikat błędu".
(...)
Poza tym, jak ktoś już korzysta z opendns, to niech sobie zaprzęgnie dnscrypt-proxy i przekieruje zapytania DNS z sieci na router, tak by szły one do opendns szyfrowanym tunelem.
No chyba Cezary w wyżej wymienionym tutku już to tak skonstruował.![]()
EDIT:
Przy okazji wspomnianego tricku z tutka Cezarego chciałem "uprzejmie donieść", że aby całość działała zgodnie z tutkiem trzeba dodać na początku w /etc/init.d/dnscrypt-proxy "sleep 5" - jeżeli chcemy z tego korzystać w trunku (CC) - inaczej zwyczajnie kontakt z siecią ma jedynie router, oraz tylko z serwerami opendns (nie da się z lanu wbić na żaden adres inernetowy).
Tam jest tylko opisane jak uruchomić dnscrypt i nie ma przymusowego przekierowania, a sam adres servera dns jest podawany z lease dhcp -- ja u siebie mam tak samo. Możesz sobie na hostach wyłączyć dhcp, jak i też możesz zignorować parametr resolvera i pobrać konfigurację hosta bez serverów dns.
Tutaj masz, na przykładzie linuxa, o co pyta klient dhcp:
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;Tylko, że ja na swojej głównej maszynie mam swój lokalny resolver, bo nie ufam żadnym innym, nawet tym postawionym w mojej sieci przeze mnie. ![]()
Siemka po przerwie.
U mnie sposób cezarego nie sprawdza się.
Laptop nie korzysta z opendns-u.
Po wymuszeniu tego za pomocą tych wpisów.
To zobacz czy ci w ogóle w przekierowanie łapie pakiety.
Jak sprawdzić poprawnie to ??
iptables -v -L -t nat
iptables -v -L -t nat
Chain PREROUTING (policy ACCEPT 80354 packets, 17M bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- br-lan any anywhere anywhere tcp dpt:domain to:208.67.222.222
10374 683K DNAT udp -- br-lan any anywhere anywhere udp dpt:domain to:208.67.222.222
80354 17M delegate_prerouting all -- any any anywhere anywhere
Chain INPUT (policy ACCEPT 752 packets, 144K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 22171 packets, 1629K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 90 packets, 28558 bytes)
pkts bytes target prot opt in out source destination
75751 10M delegate_postrouting all -- any any anywhere anywhere
Chain delegate_postrouting (1 references)
pkts bytes target prot opt in out source destination
75751 10M postrouting_rule all -- any any anywhere anywhere /* user chain for postrouting */
90 28558 zone_lan_postrouting all -- any br-lan anywhere anywhere
75661 10M zone_wan_postrouting all -- any eth1 anywhere anywhere
Chain delegate_prerouting (1 references)
pkts bytes target prot opt in out source destination
80354 17M prerouting_rule all -- any any anywhere anywhere /* user chain for prerouting */
46858 8198K zone_lan_prerouting all -- br-lan any anywhere anywhere
33496 9175K zone_wan_prerouting all -- eth1 any anywhere anywhere
Chain postrouting_lan_rule (1 references)
pkts bytes target prot opt in out source destination
Chain postrouting_newzone_rule (1 references)
pkts bytes target prot opt in out source destination
Chain postrouting_rule (1 references)
pkts bytes target prot opt in out source destination
Chain postrouting_wan_rule (1 references)
pkts bytes target prot opt in out source destination
Chain prerouting_lan_rule (1 references)
pkts bytes target prot opt in out source destination
Chain prerouting_newzone_rule (1 references)
pkts bytes target prot opt in out source destination
Chain prerouting_rule (1 references)
pkts bytes target prot opt in out source destination
Chain prerouting_wan_rule (1 references)
pkts bytes target prot opt in out source destination
Chain zone_lan_postrouting (1 references)
pkts bytes target prot opt in out source destination
90 28558 postrouting_lan_rule all -- any any anywhere anywhere /* user chain for postrouting */
Chain zone_lan_prerouting (1 references)
pkts bytes target prot opt in out source destination
46858 8198K prerouting_lan_rule all -- any any anywhere anywhere /* user chain for prerouting */
Chain zone_newzone_postrouting (0 references)
pkts bytes target prot opt in out source destination
0 0 postrouting_newzone_rule all -- any any anywhere anywhere /* user chain for postrouting */
Chain zone_newzone_prerouting (0 references)
pkts bytes target prot opt in out source destination
0 0 prerouting_newzone_rule all -- any any anywhere anywhere /* user chain for prerouting */
Chain zone_wan_postrouting (1 references)
pkts bytes target prot opt in out source destination
75661 10M postrouting_wan_rule all -- any any anywhere anywhere /* user chain for postrouting */
75661 10M MASQUERADE all -- any any anywhere anywhere
Chain zone_wan_prerouting (1 references)
pkts bytes target prot opt in out source destination
33496 9175K prerouting_wan_rule all -- any any anywhere anywhere /* user chain for prerouting */
Jest ok czy coś jest nie tak ?
Masz 10tys pakietów, więc raczej działa..
https://www.opendns.com/welcome/ Strona sprawdza czy korzystam z ich dns-ów. Twierdz że nie korzystam z ich.
Zablokowałem stronę cda.pl i dalej ona jest normalnie dostępna na kilku urządzeniach podpiętych do tego routera.
Dla tego zdziwiłem się .
Ale blokowanie adresów działa jak:
1) masz ustawione główne dns-y na opendns
2) zaktualizuje się automatycznie IP w Twoim profilu, na Twoim zarejestrowanym koncie w opendns
3) odpowiednio sformułujesz adres i jego pochodne (jak są)
4) czasem trzeba czekać i 2-3 h, by był skutek
dnscrypt-proxy to tylko dodatek do podstawowej funkcjonalności opendns.
1 Na wanie ma dns-y opendns
2 Ip mam stałe zewnętrzne
3 W jakim sensie
4 Sądziłem że 2 dni starczą na zobaczenie zmian. (Czyli zablokowaniem cda.pl przez opendns)
dnscrypt-proxy z tego nie korzystam
1) to 50 % ustawień z dyńki ![]()
2) to bez znaczenia czy stałe, czy zmienne - skrypty aktualizacyjne ddns to pilnują
3) może być jeszcze kilka stron przekierowujących na cda.pl - chociaż dla testu właśnie ustawiłem i zaskoczyło po 2 minutach (samo cda.pl) - więc posprawdzaj sobie konfigi sieci, i.t.d.
4) no wiadomo - nie działa - w praktyce kilka minut
cda blokuje za pomocą opendns
Dodałem samo cda.pl
Coś robisz źle - u mnie to działa.
Po której stronie.
opendns czy openwrt ?
Jesteś wstanie z backupa konfiguracje sprawdzić ??
Coś tak przeczuwam, że w openwrt mogłeś coś namieszać (no bo jak można się pomylić w prostym i przejrzystym konfiguratorze opendns, na ich stronie ?).
Jeśli możesz napisz dokładnie jak ustawić aby bez względu na ustawienia u klienta. Router kierował wszystkie zapytania do opendns.
Przywrócę ustawienia domyślne router tylko muszę wiedzieć dokładnie jak tym razem to ustawić.
Przede wszystkim to trzeba dodać do zapory regułę, która spowoduje blokowanie zapytań/ruch z LAN do WAN na porcie 53 (dać na REJECT).
Co do reszty to niewiele Ci podpowiem, bo korzystam z trunka (CC) i np. ja muszę dawać "sleep 5" w /etc/init.d/dnscrypt-proxy, bo inaczej nikt nie ma internetu oprócz 127.0.0.1 na routerze.
Przecież cda.pl jako, że nie jest https można bez problemu w samym openwrt zablokować.
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Przekierowanie zapytań dns na lokalny serwer
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc