How are they (ISP) achieving this, Are they really stealing and MITM ing the traffic of 8.8.8.8?

Probabilmente semplicemente reindirizzano tutti i pacchetti con la porta di destinazione 53 (cioè DNS) ai propri server e rispondono alla query. Questo non è difficile da fare.

How can I get around this without VPN?

Una VPN configurata correttamente (cioè senza perdite DNS) può aggirare questo problema (a meno che non blocchi anche la VPN). Inoltre, è possibile utilizzare un proxy HTTP o un proxy SOCKS (assicurarsi di configurare la risoluzione dei nomi esterni per l'ultimo) per il traffico HTTP e HTTPS. E le tecniche di riservatezza DNS come dnscurve, dnscrypt, DNS su TLS e DNS su HTTPS ( supportato già da Firefox ) aiuterà anche.

unfortunately they are not doing so!

Loro stanno facendo così, e il tuo dattiloscritto mostra che sta accadendo, con nslookup che sta interrogando quell'indirizzo IP e ottenendo le risposte da esso.

La tua confusione deriva in parte da un malinteso su cosa sia 8.8.8.8. È un indirizzo IP anycast . Il traffico inviato ad esso viene instradato alle interfacce di rete di più macchine in tutto il mondo, gestito da Google in vari datacenter. Tale instradamento viene eseguito da ogni nodo a cui è inviato, includendo il proprio ISP immediatamente dopo che lascia la propria rete (s).

In primo luogo, Google stessa può far sì che le macchine si comportino in modo diverso nei diversi paesi. Può fare in modo che le macchine di un paese rispondano in modo diverso alle macchine di altri paesi, se decide di farlo o se è richiesto dalle autorità di quel paese.

In secondo luogo, i server DNS di contenuti che le query DNS pubbliche di Google dal suo back-end possono rispondere in modo diverso a macchine Google diverse. I loro indirizzi IP back-end e in quali paesi corrispondono, sono pubblicati come parte della documentazione di Google Public DNS. Contenuti I server DNS forniscono risposte diverse a diversi client (i client sono i back-end di risoluzione dei server DNS proxy) in base ai loro indirizzi IP di origine è una funzionalità in diversi software server DNS.

In terzo luogo, gli ISP soggetti alla giurisdizione di un determinato paese possono dire semplicemente di indirizzare l'anycast a altre macchine sotto il controllo di una persona diversa da Google. Come è successo in Turchia nel 2014. È stato affermato che Taiwan ha piani simili.

L'Iran lo stava già facendo un anno prima della Turchia. Gli ISP iraniani intercettano tutto il traffico DNS / UDP instradato attraverso di loro e rispondono ad esso da macchine sotto il controllo iraniano. È interessante notare che questo sembra non essere fatto in modo molto competente, poiché i pacchetti fittizi TCP (sic!) Continuano a passare alle macchine originali.

(Lo stesso accade al servizio 1.1.1.1 di Cloudflare, ma meno per ragioni politiche e di censura e altro a causa della pigrizia e della follia umana. È stato a lungo abusato come indirizzo IP di prova o come intervallo di indirizzi IP privati extra non ufficiali, da persone che programmano router e altri).

Naturalmente, se si organizza il traffico DNS lascia la propria macchina sulla VPN piuttosto che direttamente sul proprio ISP, allora tutte e tre cambiano. Il traffico passa attraverso la VPN a un'altra macchina Google in un paese diverso, che invia le sue query di back-end da un indirizzo IP di origine diverso e che non viene instradato a 8.8.8.8 dal proprio ISP.

Lo svantaggio di apparire come se ci si trovasse in un altro paese per il servizio DNS è che appare come se ci si trovasse in un altro paese , come scoperto dagli australiani che utilizzavano Google Public DNS nel 2010. I CDN indirizzano uno a server HTTP di contenuto molto più distanti e non locali. I servizi a basso costo o gratuiti, ma solo all'interno del proprio paese, provengono invece dai costosi server HTTP di contenuti.

Ulteriori letture

• Steven Carstensen (2014-03-29). DNS pubblico di Google intercettato in Turchia . Google Security.
• Kieren McCarthy (2017-05-11). " governo di Taiwan per bloccare il DNS pubblico di Google in favore di HiNet ". Il registro .
• Dan Warne (2010-05-19). " Perché usare Google DNS / OpenDNS è una cattiva idea ". Magazine APC .
• Aryan et al. (2013-08). Internet Censorship in Iran: un primo sguardo .
• link
• link
• link
• link

In breve, stai diventando MITMed. Il censore che stai affrontando sta facendo qualcosa alle tue richieste DNS dirette a 8.8.8.8 in modo da ottenere risposte non genuine. Ci sono molti modi per raggiungere questo obiettivo e diverse entità eseguono questa censura con diversi mezzi. Per dare un'occhiata più da vicino, usa il tuo strumento di cattura dei pacchetti preferito (Wireshark o tcpdump ).

Come dimostrazione, ho acquisito un'interrogazione da parte mia del server DNS di Google alla 8.8.8.8 per gli indirizzi di "www.google.com".

ComesipuòvederenelloscreenshotdiWireshark,ilmiocomputerinviaduequeryDNSalserverDNS,unaperilrecordA(indirizziIPv4)eunaperilrecordAAAA(indirizziIPv6).Perognirichiestasonostatericevute3risposte.Leprimeduerispostecontengonoindirizzifalsie,cosainteressante,leprimeduerisposteperlaqueryAAAAcontengonounrecordAnellarisposta,unarispostachiaramenteerrata.LaterzaeultimarispostaperognirichiestacontieneilveroindirizzoIPperwww.google.com.Lostrumentonslookup,nonsapendonientedimeglio,haaccettatolaprimarispostaperognirichiestaehavisualizzatoquegliindirizzi.

Questosuggeriscecosastafacendoilmiocensorenazionale.Evidentemente,nonstannobloccandoiltrafficodiretea8.8.8.8atitolodefinitivo.InvececontrollanotaletrafficoequandovienetrovataunarichiestaDNSperundominiobloccato,ilcensoreiniettarispostefalse.IlcensorenonpuòesserepresolabrigadicreareunarispostaAAAAcorretta,quindilerispostemalformate.NeanchelerisposteautentichedalserverDNSrealevengonoeliminate.Tuttavia,leprimefalserispostesonosufficientiperingannareilclientechehafattolarichiestaDNSadaccettareindirizzifalsi.

Iltuocensorepotrebbefarequalcosadisimile,oppurepotrebberofarequalcosadicompletamentediverso.Prendialcuneacquisizionidipacchettiepotremmoessereingradodidiredipiù.

Perquantoriguardacomeaggirarequestoproblema,larispostapraticaèprobabilmenteunproxyDNScrittografatolocale,comeadesempio Proxy DNSCrypt oppure Stubby . Questi strumenti eseguono un server DNS sul tuo computer e le richieste DNS indirizzate a loro verranno crittografate e inviate a un server DNS che comprende il protocollo di crittografia. In questo modo il censore non può sapere a quale dominio è rivolta la richiesta e non può falsificare le risposte. Il censore può comunque bloccare questi server a titolo definitivo, però.

(Se stai cercando di aggirare un censore nazionale, sconfiggere l'avvelenamento del DNS da solo potrebbe non essere sufficiente. Potrebbe essere necessario utilizzare strumenti diversi per diverse occasioni.)

Dato che stai usando Linux, un modo semplice per aggirare questo senza una VPN completa è il tuning SSH. Se è possibile configurare o ottenere un account su un server in una posizione neutra e non filtrata, è possibile eseguire il tunneling del traffico attraverso tale posizione utilizzando SSH con solo un paio di comandi. È possibile eseguire il tunneling del traffico DNS sulla porta 53 e del traffico Web attraverso la macchina remota.

Potresti utilizzare un servizio Web Amazon o un'istanza di Google Compute Engine o solo un normale VPS remoto.

link

link