Кой адрес на източника вижда STUN с VPN на рутера?
Маршрутът, изборът на източник и транслацията решават адреса, която отразяващият сървър съобщава. Три факта за записване, после едно запитване за потвърждение кой път печели.
Въпросът звучи като едно търсене, а всъщност са три решения. Кой маршрут поема binding request, кой източник избира ядрото за този маршрут и дали нещо по пътя пренаписва този източник. Променете едно от трите и адресът, който STUN сървър съобщава, се променя с него. Затова твърдението, че VPN-ът стои на рутера, само по себе си не казва почти нищо.
Решението се крепи на три факта
Първо маршрутът: правилата на политиката и таблицата за маршрутизация решават дали заявката излиза през тунела или през обичайния WAN, а изключена дестинация поема втория път дори при активен тунел. После източникът: ядрото избира източник за избрания маршрут и този избор зависи от предпочитания източник на маршрута и от всяко правило, което е съвпаднало. Накрая транслацията: NAT по пътя заменя избрания източник. Отразеният адрес е произведение на трите, а не свойство на тунела.
Променете едно от трите и отговорът се променя, докато всеки компонент в собствения си журнал още изглежда здрав. Това е обичайната причина тази диагностика да зацикля.
Запишете трите факта за потока, който тествате, преди да започнете. Интерфейс, маршрут и правило за транслация са достатъчни, за да се предскаже резултатът, и именно предсказването прави изненадата полезна. Ако не можете да попълните едно от трите, тази празнина е действителната находка.
Проследете една binding request по пътя
STUN binding request иска от сървър да съобщи наблюдавания адрес на транспорта на източника. Отговорът описва пътя, който заявката е поела, а не опис на интерфейсите на клиентската машина. Две заявки по два пътя честно ще съобщят два различни адреса.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Четете тази таблица като набор от условия, не като меню от доставчици. Средният ред изисква частният отражател да е достъпен под собствената маршрутизация и peer политика на тунела; това е конфигурационен факт, който можете да проверите, а не нещо, което предполага ниво на акаунт. Долният ред обикновено е този, който има значение за политиката, защото този трафик е трябвало да остане в тунела. Между тях е обичайният случай, при който изходът превежда, а отражателят вижда само изхода.
Кандидатите домакин и сървърно-рефлексните кандидати идват от различни механизми, затова списъкът с кандидати не казва кой път медиите действително са използвали. Четете избраната двойка, а не журнала за събиране, когато искате да знаете къде е отишла сесията.
Какво адресът на тунела на рутера не е
Адрес на тунел, зададен на рутера, принадлежи на интерфейс на рутера. Браузър на хост в LAN има свои собствени адреси на интерфейси и никакъв директен изглед към тунелния интерфейс на рутера. Ако се третират като взаимозаменяеми, се получават самоуверени грешни отговори за това какво може да научи една уеб страница.
Препращането е това, което ги свързва. Заявката преминава през рутера като маршрутизиран трафик, а източникът ѝ е това, което са произвели маршрутизацията и транслацията.
Ако пътят през тунела запазва LAN източника, частен отражател може да научи този LAN адрес, което е истинско разкриване и различно от адреса на тунела. Ако пътят превежда към адреса на тунела, отражателят научава вместо това адреса на тунела. И двата изхода са съвместими с един и същ браузър на един и същ хост, затова наблюдението трябва да се обвърже с конкретен поток. Попитайте ядрото кой източник би използвало, преди да обвините приложението.
Разкриване срещу заобикаляне: две находки, две поправки
Отразен адрес на тунела разкрива вътрешен идентификатор по път, който сте разрешили. Заявка директно през WAN заобикаля път, който сте искали да изисквате. Първото е въпрос на информация, второто на прилагане, и се поправят на различни места. Ако ги слеете в една дума, получавате поправка, която не решава нито едното.
WebRTC прави това по-видимо, без да го прави грешно, защото събирането на кандидат не е същото като избирането му.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showИзпълнете заявката за маршрут за всеки разрешен адрес на отражател, с източника, който очаквате този поток да носи, после я изпълнете отново за изключените диапазони, за да видите какво избира резервният вариант. Сравнете двата отговора с политиката, която сте записали. Когато се различават по начин, който не сте имали предвид, сте намерили точката за поправка, без дори да се налага да тълкувате списъка с кандидати на браузъра.