Waar DNS heen gaan wanneer jy Tor en ’n VPN kombineer

Twee privaatheidshulpmiddels is aan die werk, een bladsy laai nie, en ’n opknooptest sê iets buite die blaaier het ’n naam ontvang. Voordat dit ’n lekverslag word, benoem die uitruiling waaruit dit kom. ’n Tor-plus-VPN-opstelling bevat ten minste drie verskillende naamnavrae met drie verskillende eienaars, en om hulle in die volgorde waarin hulle gebeur deur te werk is die vinnigste manier om te sien watter een hom wangedra.

Noem elke uitruiling voordat jy dit ’n lek noem

Die eerste uitruiling los die VPN-eindpunt self op, en dit gebeur voordat enige beskerming bestaan. Die tweede los ’n bestemming vir Tor Browser op, wat die naam aan die instaanbediener kan oorhandig in plaas daarvan om dit plaaslik op te los. Die derde dek alles anders op die masjien, insluitend opdateringstoetse, e-poskliënte en die bedryfstelsel se eie diensnavrae. Net die eerste hiervan kan gebeur sonder dat die ander twee betrokke is.

Elkeen hiervan kan ’n ander pad volg, en ’n enkele blaaiergebaseerde toets waarneem net sy eie versoek. Om een resultaat as die toestand van al drie te beskou, is waar die meeste verwarring begin.

Skryf neer watter name aan watter laag behoort voordat jy iets verander. Privaat organisasiename, ’n openbare bestemming en die tonneleindpunt self hou nie dieselfde vereiste in nie, en ’n beleid wat hulle as een kategorie behandel, sal iets breek.

Die opstartnavraag gebeur voor die tonnel

’n Kliënt wat met ’n gasheernaam opgestel is, moet daardie naam oplos om die tonnel oop te maak, en op daardie oomblik bestaan die tonnel nie om die navraag te dra nie. Watter oplosser die bedryfstelsel ook al op die huidige netwerk bied, antwoord dit, wat ’n vasgevangde portaal, ’n hoteloplosser of ’n openbare een kan wees. Dit is nie ’n lek in die tonnel nie, want daar is nog geen tonnel nie.

Om die blaaier se veilige-DNS-instelling te verander raak ook nie hierdie navraag nie, want dit behoort aan ’n diens wat buite die blaaier loop en begin voordat enige bladsy oopgemaak word. As die eindpuntnaam nie opgelos kan word nie, sal geen mate van tonnelbeleid help nie, want die fout gebeur een stadium vroeër as alles wat die opstelling beskryf.

Dit is die een plek waar die gebruik van ’n letterlike adres vir die eindpunt, as die verskaffer dit ondersteun, ’n afhanklikheid verwyder in plaas daarvan om een by te voeg. Dit verwyder ook die vermoë om ’n verskaffer te volg wat adresse roteer, so die ruil is werklik en moet eerder besluit as ontdek word.

Die blaaier en die res van die masjien verskil

Tor se SOCKS-koppelvlak ondersteun die deurgee van ’n bestemmingsgasheernaam aan die instaanbediener, wat beteken die afgeleë kant doen die oplossing en die plaaslike masjien vra nooit nie. ’n Generiese toepassing wat ’n instaanbediener ondersteun, kan die naam eers plaaslik oplos en dan aan die adres wat dit verkry het koppel, wat ’n plaaslike navraag lewer vir ’n bestemming wat die gebruiker geglo het deur die instaanbediener gestuur word. Die twee toepassings kan dus op verskillende plekke lek terwyl hulle een instaanbediener-instelling deel. Niks in ’n gedeelde instaanbediener-adres sê vir jou watter van die twee gedragswyses in gebruik is nie.

Blaaiers voeg nog ’n laag by wanneer veilige DNS geaktiveer is, want die blaaier kan sy eie verskaffer kies en die stelseloplosser heeltemal omseil. Die tonnelkliënt kan intussen ’n oplosser deur die tonnel vir die hele masjien stoot. Daardie twee instellings kan albei korrek wees en steeds verskillende gedrag vir verskillende programme beskryf.

Kontroleer die program wat die versoek gemaak het eerder as om van een toetsblad af te lei. Die onderskeid tussen ’n navraag wat binne die tonnel gedra word en een wat Tor nooit bereik het nie, is presies die onderskeid wat ’n enkele oplosseradres nie kan wys nie.

Kontroleer elke program en vergelyk dan met die bedoeling

Voer die waarnemings afsonderlik uit: wat die stelsel sou gebruik, waarvoor die blaaier opgestel is, en of die SOCKS-verbinding ’n naam of ’n adres dra. Laasgenoemde is die verskil tussen afgeleë en plaaslike oplossing, en die SOCKS-uitbreidingspesifikasie beskryf hoe ’n gasheernaam deurgegee word eerder as om eers opgelos te word.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Vergelyk dan wat jy waargeneem het met wat jy bedoel het. ’n Openbare naam wat deur ’n oplosser van jou keuse deur die tonnel opgelos word, is nie dieselfde bevinding as ’n privaat naam wat tydens ’n terugval aan ’n openbare oplosser oorhandig word nie, en net die tweede een vereis gewoonlik optrede. Die eerste is ’n opstelling wat werk soos ontwerp, selfs al lyk dit onbekend in ’n verslag.

Teken die uitsonderings aan wat jy aanvaar, insluitend die opstartnavraag wat nie beskerm kan word nie. ’n Uitsondering wat neergeskryf is, is ’n ontwerpbesluit, terwyl dieselfde uitsondering wat later ontdek word, soos ’n gebrek lyk. Die persoon wat dit vind, sal dit as een behandel, en jy sal die vergadering daaraan bestee om te verduidelik waarom dit nie is nie.