Када WebRTC тест страница испише 172.20.4.15, сазнала је да на тој мрежи постоји локални интерфејс. То је стварно откриће и није исти налаз као „медиј је изашао кроз VPN излаз“. Откривање кандидата и рутирање пакета су одвојени механизми, а већина извештаја о цурењу их спаја у једну пресуду. Који од њих гледате одлучује поправку.

Прикупљање иде пре него што се било шта пошаље

Прегледач набраја локалне интерфејсе, шаље захтев за повезивање STUN серверу и тражи алокацију од TURN сервера, а затим резултате уписује у опис сесије као линије кандидата. Све то завршава без позива, без медија и без саговорника. Листа кандидата је зато запис откривања, а не преноса.

Савремени прегледачи могу заменити дословну адресу host кандидата mDNS именом .local, па страница не може прочитати приватни IP. Локална мрежа ипак види multicast упите који разрешавају то име, дакле адреса је скривена од апликације, а не уклоњена са мреже.

Редослед је такође важан: ново учитавање странице прикупља нови скуп, уз другу TURN алокацију и могуће другачије рефлексивно мапирање. Два покретања која се разликују нису нужно две различите конфигурације.

Три типа кандидата, три врсте доказа

Свака линија произлази из другог опажања. Сваки тип одговара на друго питање, а табела их раздваја по томе шта могу и шта не могу утврдити.

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

Relay кандидат се рутински замењује с корисниковом интернет адресом. Он припада TURN серверу, а његово присуство показује да је relay био доступан, не да га је прегледач одабрао. Иста забуна иде и у супротном смеру код host кандидата, где mDNS име скрива адресу од странице док мрежа још носи упите. Прочитајте тип пре него прочитате вредност.

Изабрани пар одговара на питање рутирања

ICE спаја сваког локалног кандидата са сваким удаљеним, изводи провере повезаности на сваком пару и номинује победника. Тај номиновани пар, видљив у дијагностици самог прегледача, носи медиј. Све остало на листи је могућност која је изгубила.

Победник вам говори облик пута. Relay према relay пролази кроз TURN сервер, host пар остаје на локалној мрежи, а серверски рефлексивни пар иде директно кроз NAT. То је чињеница која треба VPN провери и она је различита од листе адреса. Два позива са идентичним листама кандидата могу изабрати различите парове.

Неодабрани кандидати су ипак прикупљени, а прикупљање је мрежни саобраћај који напушта машину. Позив који је на крају користио relay не значи да ништа није откривено док је листа грађена.

Контроле одговарају циљевима, не оцени цурења

WebRTC спецификација за руковање IP-ом описује неколико политика: коришћење само интерфејса који носи подразумевану руту, коришћење свих интерфејса и искључивање непроксираног UDP-а тако да саобраћај мора ићи кроз relay или proxy. Свака размењује повезаност и латенцију за другу врсту изложености. Коју политику прегледач спроводи и под којим именом зависи од платформе и верзије.

Одаберите политику према циљу. Скривање локалних адреса од странице је један циљ; спречавање директног саобраћаја између равноправних рачунара је други; држање сваког пакета унутар тунела је трећи. Први се углавном тиче онога што апликација сазна, други тога који је пут дозвољен, а трећи се мора наметнути и на граници платформе или VPN-а.

Коју год контролу одабрали, проверите обе половине: покрените тест прикупљања и забележите типове кандидата, па прегледајте одабрани пар током стварне сесије. Чиста листа адреса са директним медијским путем и даље је пут који нисте намеравали.

Повезани чланци