Vad en WebRTC-kandidatlista avslöjar om din VPN
En värd-, serverreflexiv eller relaykandidat berättar var en adress kommer ifrån. Endast det valda ICE-paret berättar vilken väg mediet faktiskt använde.
När en WebRTC-testsida skriver ut 172.20.4.15 har den fått veta att det finns ett lokalt gränssnitt på det nätverket. Det är ett verkligt avslöjande, och det är inte samma fynd som ”mediet lämnade via VPN-utgången”. Kandidatupptäckt och paketrouting är separata mekanismer, och de flesta läckagerapporter smälter samman dem till en enda dom. Vilken av dem du tittar på avgör åtgärden.
Insamlingen sker innan något skickas
Webbläsaren räknar upp lokala gränssnitt, skickar en bindningsbegäran till en STUN-server och ber en TURN-server om en tilldelning, och skriver sedan resultaten i sessionsbeskrivningen som kandidatradar. Allt detta slutförs utan samtal, utan media och utan motpart. En kandidatlista är därför ett protokoll över upptäckt, inte över transport.
Moderna webbläsare kan ersätta en värdkandidats bokstavliga adress med ett mDNS-namn .local, så sidan kan inte läsa den privata IP-adressen. Det lokala nätverket ser fortfarande multicast-frågorna som löser upp namnet, så adressen döljs för applikationen i stället för att tas bort från nätet.
Ordningen spelar också roll: en ny sidladdning samlar in en ny uppsättning, med en annan TURN-tilldelning och möjligen en annan reflexiv mappning. Två körningar som skiljer sig åt är inte nödvändigtvis två olika konfigurationer.
Tre kandidattyper, tre slags bevis
Varje rad härrör från en annan observation. Varje typ svarar på en annan fråga, och tabellen skiljer dem åt efter vad de kan och inte kan fastställa.
| 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 relaykandidat förväxlas rutinmässigt med användarens internetadress. Den tillhör TURN-servern, och dess närvaro visar att en relay var tillgänglig, inte att webbläsaren valde den. Samma förväxling går åt andra hållet med värdkandidater, där ett mDNS-namn döljer adressen för sidan medan nätverket fortfarande bär frågorna. Läs typen innan du läser värdet.
Det valda paret svarar på routingfrågan
ICE parar varje lokal kandidat med varje extern, kör anslutningskontroller på varje par och nominerar en vinnare. Det nominerade paret, synligt i webbläsarens egen diagnostik, bär mediet. Allt annat i listan är en möjlighet som förlorade.
Vinnaren berättar vägens form. Relay till relay går genom TURN-servern, ett värdpar stannar på det lokala nätverket, och ett serverreflexivt par går direkt genom NAT. Det är det faktum en VPN-kontroll behöver, och det är ett annat faktum än adresslistan. Två samtal med identiska kandidatlistor kan ta olika par.
Icke valda kandidater samlades ändå in, och insamling är nätverkstrafik som lämnar maskinen. Ett samtal som till slut använde relayen betyder inte att ingenting avslöjades medan listan byggdes.
Kontroller svarar mot mål, inte mot en läckagescore
WebRTC-specifikationen för IP-hantering beskriver flera policyer: att använda endast det gränssnitt som bär standardrutten, att använda alla gränssnitt, och att stänga av UDP utan proxy så att trafiken måste gå via en relay eller proxy. Var och en byter anslutning och latens mot en annan typ av exponering. Vilken en webbläsare implementerar, och under vilket namn, varierar med plattform och version.
Välj policyn utifrån målet. Att dölja lokala adresser för en sida är ett mål; att förhindra direkt peer-to-peer-trafik är ett annat; att hålla varje paket inne i tunneln är ett tredje. Det första handlar mest om vad applikationen lär sig, det andra om vilken väg som är tillåten, och det tredje måste också upprätthållas vid plattformens eller VPN:ens gräns.
Vilken kontroll du än väljer, verifiera båda halvorna: kör insamlingstestet och anteckna kandidattyperna, och granska sedan det valda paret under en riktig session. En ren adresslista med en direkt medieväg är fortfarande en väg du inte avsåg.