Hvad en WebRTC-kandidatliste afslører om din VPN
En host-, server-refleksiv eller relay-kandidat fortæller, hvor en adresse kom fra. Kun det valgte ICE-par fortæller, hvilken vej mediet faktisk brugte.
Når en WebRTC-testside udskriver 172.20.4.15, har den erfaret, at der findes et lokalt netværkskort på det netværk. Det er en reel afsløring, og det er ikke det samme fund som “mediet forlod via VPN-udgangen”. Kandidatopdagelse og pakkerouting er adskilte mekanismer, og de fleste lækagerapporter smelter dem sammen til én dom. Hvilken af dem du ser på, afgør løsningen.
Indsamlingen sker, før noget sendes
Browseren opregner lokale netværkskort, sender en bindingsanmodning til en STUN-server og beder en TURN-server om en tildeling, og skriver derefter resultaterne i sessionsbeskrivelsen som kandidatlinjer. Alt det afsluttes uden opkald, uden medie og uden modpart. En liste over kandidater er derfor en registrering af opdagelse, ikke af transport.
Moderne browsere kan erstatte en host-kandidats bogstavelige adresse med et mDNS-navn .local, så siden ikke kan læse den private IP. Det lokale netværk ser stadig de multicast-forespørgsler, der opløser navnet, så adressen skjules for applikationen i stedet for at blive fjernet fra nettet.
Rækkefølgen betyder også noget: en ny sideindlæsning indsamler et nyt sæt, med en anden TURN-tildeling og muligvis en anden refleksiv mapping. To kørsler, der er uenige, er ikke nødvendigvis to forskellige konfigurationer.
Tre kandidattyper, tre slags bevis
Hver linje stammer fra en anden observation. Hver type besvarer et andet spørgsmål, og tabellen adskiller dem efter, hvad de kan og ikke kan fastslå.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
En relay-kandidat bliver rutinemæssigt forvekslet med brugerens internetadresse. Den tilhører TURN-serveren, og dens tilstedeværelse viser, at en relay var tilgængelig, ikke at browseren valgte den. Den samme forveksling går den anden vej med host-kandidater, hvor et mDNS-navn skjuler adressen for siden, mens netværket stadig bærer forespørgslerne. Læs typen, før du læser værdien.
Det valgte par besvarer routing-spørgsmålet
ICE parrer hver lokal kandidat med hver fjern kandidat, kører forbindelsestjek på hvert par og nominerer en vinder. Det nominerede par, synligt i browserens egen diagnostik, bærer mediet. Alt andet på listen er en mulighed, der tabte.
Vinderen fortæller dig banens form. Relay-til-relay går gennem TURN-serveren, et host-par bliver på det lokale netværk, og et server-refleksivt par går direkte gennem NAT. Det er det faktum, en VPN-kontrol har brug for, og det er et andet faktum end adresselisten. To opkald med identiske kandidatlister kan tage forskellige par.
Ikke-valgte kandidater blev stadig indsamlet, og indsamling er netværkstrafik, der forlader maskinen. Et opkald, der i sidste ende brugte relayen, betyder ikke, at intet blev afsløret, mens listen blev bygget.
Kontroller svarer til mål, ikke til en lækagescore
WebRTC-specifikationen for IP-håndtering beskriver flere politikker: at bruge kun det netværkskort, der bærer standardruten, at bruge alle netværkskort og at deaktivere UDP uden proxy, så trafikken skal gennem en relay eller proxy. Hver af dem bytter forbindelse og latenstid for en anden slags eksponering. Hvilken en browser implementerer, og under hvilket navn, varierer efter platform og version.
Vælg politikken ud fra målet. At skjule lokale adresser for en side er ét mål; at forhindre direkte peer-to-peer-trafik er et andet; at holde hver pakke inde i tunnelen er et tredje. Det første handler mest om, hvad applikationen lærer, det andet om hvilken vej der er tilladt, og det tredje skal også håndhæves ved platformens eller VPN’ens grænse.
Uanset hvilken kontrol du vælger, skal du verificere begge halvdele: kør indsamlingstesten og noter kandidattyperne, og undersøg derefter det valgte par under en rigtig session. En ren adresseliste med en direkte medievej er stadig en vej, du ikke havde tænkt dig.