dns terzi non raggiungibili: udp filtrato?

Area di discussione libera.

Moderatore: Staff

Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

Utilizzo un cellulare come modem su rete tim.
A volte mi collego ad internet via apn wap.tim.it ma dal PC.
Quindi ovviamente la connessione ha delle limitazioni rispetto all'accesso via apn predisposto per navigare dal PC (ibox.tim.it).
Alcune differenze stanno per esempio nell'assegnazione di un un ip privato nel caso del wap mentre è pubblico nel caso di ibox.
Altra differenza non so per quale motivo (e quindi non riesco ad adattare il mio sitema) è il presunto filtraggio di protocolli particolari:

Il ping verso un qualsiasi sito tipo maya.ngi.it non funziona. Che sia filtrato il protocollo ICMP?

Codice: Seleziona tutto

# ping maya.ngi.it
PING maya.ngi.it (88.149.128.3) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
[...]
ping: sendmsg: Network is unreachable
^C
--- maya.ngi.it ping statistics ---
54 packets transmitted, 0 received, 100% packet loss, time 53002ms
Non è forse molto importante, ma tanto per dare un'idea della situazione.

Un'altra cosa è la navigazione internet via normale browser... non è come ci si aspetterebbe, alcune pagine non vengono visualizzate correttamente ecc.

Un comportamento particolarmente strano è inoltre riscontrabile tentando di utilizzare un servizio di dns terzo diverso da quelli predefiniti di tim. Per esempio basta impostare gli opendns in resov.conf ed effettuare un dig verso google, ci si accorgerà che non viene risolto alcunchè.

Siccome avevo seguito un po' la guida di conraid per impostare semplicemente bind in locale al fine di bypassare i dns esterni e lo uso senza problemi quando mi connetto via apn ibox.tim.it. Ho riscontrato che invece neanche questo funziona più, ovvero lasciando in resolv.conf il localhost il dig verso google dà lo stesso risultato di opendns.
Alla fine ho pensato che potesse trattarsi di filtraggio quasi totale del protocollo udp su cui si basa se non ho capito male l'accesso ai dns, probabilmente lasciano aperta solo la connessione udp verso i dns di tim.
Avrei voluto bypassarli.

Visto che questo sito è frequentato anche da esperti, secondo voi cosa può essere bloccato?

PS. La soluzione volendo c'è ma è dispersiva e si appoggia a terzi. openvpn per esempio. Anche le richieste verso i dns in quel caso viene tunnelizzata pertanto si bypassa tutto (d'altra parte si agisce a livello ip, cambia proprio l'interfaccia di rete tun0 invece di ppp0).
Però come dicevo serve un server vpn esterno (ve ne sono di gratuiti, ma anche loro hanno pi le loro limitazioni).

PS2.
La cosa più strana è che queste limitazione sembrano essere randomizzate tipo al momento riesco a fare il dig di goolge con gli opendns

Codice: Seleziona tutto

# dig www.google.com

; <<>> DiG 9.4.2-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48534
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         604268  IN      CNAME   www.l.google.com.
www.l.google.com.       289     IN      A       173.194.36.104

;; Query time: 1140 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Sep 15 12:45:35 2010
;; messaggio SIZE  rcvd: 68
Invece una mezz'ora fa non mi era possibile.

Tanto per cominciare vi chiederei una diagnosi delle limitazioni stando a quanto spiegato.
Grazie in anticipo.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

Mmm cercando e ricercando sono giunto ad un tool sicuramente interessante chiamato tcpdump e l'ho fatto girare sull'interfaccia ppp0 cui viene assegnato da tim l'ip 10.212.x.x Ecco, ad un certo punto il bind in locale attivato e funzionante ho smesso di risolvere gli indirizzi. Come avevo detto sopra il comportamento della limitazione è piuttosto casuale. Ne ho approfittato per vedere cosa non và e mi sembra un problema di ICMP che viene disabilitato a monte.
Da un'altra shell ho lacniato il dig di http://www.pluto.org:

Codice: Seleziona tutto

# dig www.pluto.org

; <<>> DiG 9.4.2-P2 <<>> www.pluto.org
;; global options:  printcmd
;; connection timed out; no servers could be reached
E nella shell con tcpdump che gira vedo:

Codice: Seleziona tutto

14:23:37.018500 IP 10.212.x.x > a.dns.jp: ICMP 10.212.x.x udp port 6047 unreachable, length 238
14:23:37.110595 IP a.dns.jp.domain > 10.212.x.x.64001: 19776- 0/3/5 (202)
14:23:37.110624 IP 10.212.x.x > a.dns.jp: ICMP 10.212.x.x udp port 64001 unreachable, length 238
14:23:37.302457 IP d.gtld-servers.net.domain > 10.212.x.x.50359: 57470- 0/2/2 (104)
Sembra come se il server (che penso sia un root server o qualcosa di simile) mi voglia contattare via protocollo ICMP (un ping per vedere se sono raggiungibile o cos'altro?) sulla porta udp numero tot. Ma non riesce pur riprovando su porte differenti. Questo spiega anche perchè fallisce il ping verso maya.ngi.it.
Però ho anche provato a fare il ping di un indirizzo privato appartenente alla mia sottorete, dovrebbe essere un altro utente connesso cui tim ha assegnato quel ip privato...

Codice: Seleziona tutto

ping 10.212.x.y
PING 10.212.x.y (10.212.x.y) 56(84) bytes of data.
64 bytes from 10.212.x.y: icmp_seq=1 ttl=127 time=2531 ms
64 bytes from 10.212.x.y: icmp_seq=2 ttl=127 time=1588 ms
64 bytes from 10.212.x.y: icmp_seq=3 ttl=127 time=708 ms
64 bytes from 10.212.x.y: icmp_seq=4 ttl=127 time=1036 ms
64 bytes from 10.212.x.y: icmp_seq=5 ttl=127 time=872 ms
^C
--- 10.212.x.y ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5007ms
rtt min/avg/max/mdev = 708.051/1347.086/2531.176/661.953 ms, pipe 3
Quindi sembrerebbe che il ping funzioni dentro la rete che tim predispone per le connessioni wap. Invece per i ping e più in generale per quanto rigarda il protocollo ICMP verso l'esterno della rete, c'è qualcosa frapposto che ne impedisce l'utilizzo.
Non penso che sia semplicemente dovuto al fatto dell'ip privato: mi pare che il ping verso siti esterni funzioni anche se si è in una lan così come le connessioni via udp. Ho il sospetto che sia un filtro imposto da tim per limitare qualche servizio particolare, non so a che pro di preciso.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

Mi viene un dubbio e una domanda banale:
ma è normale che il ping non funzioni se da un PC di una LAN si interroga un IP esterno a questa?
Per esempio un untente fastwaeb nattato che prova a dare ping maya.ngi.it riesce a contattare quell'ip ed ottenere anche le rispsote corrispondenti?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

nessuna idea comment ecc su questa situazione?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

Dopo varie ricerche ho trovato una possibile soluzione, anzi 2:
https://www.privacyfoundation.de/wiki/HTTPS-DNS
https://www.privacyfoundation.de/wiki/SSL-DNS

In particolare questo secondo link mi è sembrato presentare una soluzione piuttosto semplice:

localhost[socat(53 > 5666 )] <-----> localhost[stunnel (5666 > ssl-dns-server:portadelserver)]

In /etc/resolv.conf basta mettere 127.0.0.1 ovvero il dns interpellato sarà il localhost su porta 53.

il sistema contatta il localhost sulla porta 53 per risolvere un indirizzo.
Ma sulla porta 53 sta in ascolto socat che prende la richiesta ("trasformando" il protocollo udp della stessa in tcp) e la redirige sempre al local host sulla 5666.
Ma sulla 5666 sta in ascolto stunnel che cripta la richiesta proveniente in protocollo tcp. E la gira in connessione sicura al server ssl-dns remoto. La risposta avviene seguendo il percorso contrario: stunnel locale riceve l'ip che il server gli comunica in risposta, e passa il tutto a socat che riconverte (oppure no, questo non lo so, ma non è un problema) la risposta in udp e comunica il tutto al sistema che finalmente può connettersi all'ip voluto.

Bella storia, ma pur avendo ricopiato la procedura descritta, che alla fine si tratta di un file di configurazione di stunnel ed un comando per socat, non sono riuscito ad ottenere alcunchè. Può essere che i server proposti dal wiki non siano più attivi o può darsi che abbia sbagliato io qualcosa.
Eventualmente aveste voglia di provare anche voi mi sarebbe di aiuto un vostra conferma o smentita del non funzionamento.

Per quanto riguarda la seconda via ovvero https-dns (primo link) non vi ho capito granchè perchè òa guida è in tetesken, maledttenz...

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3986
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: dns terzi non raggiungibili: udp filtrato?

Messaggio da joe »

Ma veramente nessuno sa nulla di sta roba?

Rispondi