Kui WebRTC testleht trükib 172.20.4.15, on see teada saanud, et selles võrgus on kohalik liides olemas. See on tõeline paljastus ja see ei ole sama järeldus nagu «meedia väljus VPN-i väljumiskoha kaudu». Kandidaatide avastamine ja pakettide marsruutimine on eraldi mehhanismid ning enamik lekkeraportid ühendavad need üheks otsuseks. Kumb neist on vaatluse all, määrab paranduse.

Kogumine toimub enne, kui midagi saadetakse

Brauser loetleb kohalikud liidesed, saadab STUN-serverile sidumispäringu ja palub TURN-serverilt eraldise, seejärel kirjutab tulemused sessioonikirjeldusse kandidaadiridadena. Kõik see lõpeb ilma kõne, meedia ja vastaspooleta. Kandidaatide loend on seega avastamise, mitte edastuse kirje.

Kaasaegsed brauserid võivad asendada hostkandidaadi sõnasõnalise aadressi mDNS-nimega .local, nii et leht ei saa privaatset IP-d lugeda. Kohalik võrk näeb endiselt multicast-päringuid, mis selle nime lahendavad, seega on aadress rakenduse eest peidetud, mitte võrgust eemaldatud.

Ka järjekord on oluline: värske lehe laadimine kogub uue komplekti, kasutades teist TURN-eraldist ja võib-olla teistsugust refleksiivset vastendust. Kaks erinevat jooksu ei ole tingimata kaks erinevat konfiguratsiooni.

Kolm kandidaaditüüpi, kolme liiki tõendid

Iga rida pärineb erinevast vaatlusest. Iga tüüp vastab erinevale küsimusele ning tabel eristab neid selle järgi, mida nad suudavad ja ei suuda tuvastada.

CandidateDerived fromWhat it establishesWhat it cannot establish
HostAn interface on the deviceA local address exists in that networkThat the peer can reach it
Server-reflexiveA STUN binding responseHow a NAT mapped this sourceWhich exit the media will use
Peer-reflexiveA connectivity check that arrivedAn address seen by the far sideThat it was ever advertised
RelayA TURN allocationThe relay server accepted the sessionThat the relay carries the call

Releekandidaat aetakse sageli segi kasutaja internetiaadressiga. See kuulub TURN-serverile ja selle olemasolu näitab, et relee oli saadaval, mitte et brauser selle valis. Sama segadus käib vastassuunas hostkandidaatide puhul, kus mDNS-nimi peidab aadressi lehe eest, samal ajal kui võrk kannab endiselt päringuid. Lugege tüüpi enne, kui loete väärtust.

Valitud paar vastab marsruutimisküsimusele

ICE paarib iga kohaliku kandidaadi iga kaugkandidaadiga, teeb igal paaril ühenduvuskontrollid ja nimetab võitja. See nimetatud paar, mis on nähtav brauseri enda diagnostikas, kannab meediat. Kõik muu loendis on võimalus, mis kaotas.

Võitja ütleb teile tee kuju. Relee-relee läheb läbi TURN-serveri, hostpaar jääb kohalikku võrku ja serveri-refleksiivne paar läheb otse läbi NAT-i. See on fakt, mida VPN-i kontroll vajab, ja see on teine fakt kui aadresside loend. Kaks kõnet identsete kandidaadiloenditega võivad valida erinevad paarid.

Valimata kandidaadid koguti siiski ja kogumine on võrguliiklus, mis masinast lahkub. Kõne, mis lõpuks releed kasutas, ei tähenda, et loendi koostamise ajal midagi ei paljastatud.

Juhtimisvõimalused vastavad eesmärkidele, mitte lekkehindele

WebRTC IP-käsitsemise spetsifikatsioon kirjeldab mitut poliitikat: kasutada ainult liidest, mis kannab vaikemarsruuti; kasutada kõiki liideseid; ja keelata puhverserverita UDP, nii et liiklus peab minema läbi relee või puhverserveri. Iga neist vahetab ühenduvuse ja latentsuse teistsuguse kokkupuute vastu. Millist brauser rakendab ja millise nime all, sõltub platvormist ja versioonist.

Valige poliitika eesmärgi järgi. Kohalike aadresside peitmine lehe eest on üks eesmärk; otsese võrdõigusliku liikluse takistamine on teine; iga paketi tunnelis hoidmine on kolmas. Esimene puudutab peamiselt seda, mida rakendus teada saab, teine seda, milline tee on lubatud, ja kolmas tuleb tagada ka platvormi või VPN-i piiril.

Ükskõik millise juhtimisvõimaluse valite, kontrollige mõlemat poolt: käivitage kogumistest ja kirjutage üles kandidaatide tüübid, seejärel uurige valitud paari tõelise sessiooni ajal. Puhas aadresside loend otsese meediaga on endiselt tee, mida te ei kavatsenud.

Seotud artiklid