Што открива STUN одговорот кога VPN работи на рутерот
Адресата на тунелот на рутерот не е локалната адреса на прелистувачот. Следете како секое барање се рутира и преведува пред да прочитате што известува рефлекторот.
Кога тунелот живее на рутерот, машината што го извршува прелистувачот воопшто нема тунелски интерфејс. Прашајте ја таа машина за нејзините локални адреси и ќе добиете приватна LAN адреса и јамка, ништо што личи на VPN адреса. Сепак, STUN серверот од другата страна сѐ уште може да извести нешто значајно за патеката, и тоа што го известува целосно зависи од тоа како токму тоа барање било рутирано и преведено.
Токму тој дел заслужува да се забави. „Прелистувачот не ја поседува VPN адресата“ одговара на прашање за интерфејси, додека рефлектираната адреса е одговор за патека низ превод. Мешањето на двете дава самоуверени заклучоци за откривање што доказите не ги поддржуваат.
Два уреда, два сета интерфејси
Во поставеност базирана на рутер, тунелот завршува на рутерот и LAN клиентот испраќа обичен сообраќај до својот стандарден портал. Списокот на интерфејси на клиентот останува краток: една приватна адреса, можеби втора за друга мрежа, и јамката. Ризикот не е во тоа што една од нив случајно е адресата на тунелот; ризикот е во тоа што барањето излегува по патека што не сте ја избрале.
Прашајте го клиентот која патека би ја зазел одредено одредиште наместо да прашате кои интерфејси постојат. Одговорот именува портал и изворната адреса што јадрото би ја користело, што е веќе поинформативно од кој било список на адреси.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsДокументациските опсези се добри тест одредишта бидејќи никогаш не се разрешуваат во вистинска услуга. Споредете што вели клиентот со тоа што вели рутерот, и секое несогласување третирајте го како доказ дека рутирањето по политика, правило за поделен тунел или втор стандарден пат прави нешто што не сте го зеле предвид.
Што смее да каже еден Binding одговор
RFC 8489 го дефинира барањето и одговорот Binding, каде серверот ја известува изворната транспортна адреса што ја набљудувал за тоа барање. Тоа е изјава за една петорка во еден момент, а не попис на интерфејсите на клиентот. Затоа сето интересно се случува помеѓу клиентот и точката на набљудување.
Таа празнина ја пополнуваат рутирањето и преводот. Рутерот што прави изворен NAT на излезниот сообраќај ја заменува приватната изворна адреса на клиентот со својата адреса на излезниот интерфејс. Ако тој интерфејс е тунелот, рефлекторот ја гледа адресата на тунелот. Ако пакетот е исклучен од тунелот, рефлекторот го гледа тоа што го создал WAN преводот. Ист клиент, ист рефлектор, различен одговор.
Три случаи што изгледаат исто и не се
Корисната разлика не е јавно наспроти приватно, туку која точка на спроведување го обработила пакетот. Разгледајте ги случаите со отворени сопствени табели на рутерот, зашто еден прелистувач може да ги создаде сите три зависно од правило што заборавивте дека сте го напишале.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Само вториот случај го крши барањето одреден сообраќај никогаш да не излегува директно, и само првиот и третиот откриваат идентификатор од страната на тунелот. Ниту една од трите редови не е тврдење за однесувањето на конкретен давател: дали приватен рефлектор е воопшто достапен зависи од рутирањето, дозволените IP адреси на другата страна и политиката на огнениот ѕид на двата краја.
Имањето сметка кај истиот давател не докажува ништо од тоа. Вреди да се запомни и дека рутирано барање може да ја задржи LAN изворната адреса на клиентот ако ништо не ја преведува, па полето за извор мора да се следи, а не да се претпоставува од тополошката слика.
Собирањето не е избирање
WebRTC собира кандидатски адреси за испробување, а кандидат што се појавува во дијагностички список може никогаш да не пренесе медиум. Читањето на списокот како „ова е она што другата страна го научила“ го преценува доказот. Избраниот пар е она што навистина ја пренел сесијата, и тој живее во друго поле.
HTTPS проверувачот на излез одговара на уште едно прашање: изворната адреса што веб серверот ја видел за тоа барање. Тоа е корисна вкрстена проверка токму затоа што користи друг протокол и често друга цел од UDP рефлекторот, а несовпаѓањето помеѓу двете обично упатува на правило за рутирање, а не на грешка.
Одлучете ја политиката, потоа прочитајте го одговорот
Запишете ја намерата пред тестирањето: кој сообраќај мора да го користи тунелот, кој смее да излезе директно, кои семејства на адреси се во опфатот и што треба да се случи кога тунелот е исклучен. Без таа основна линија секое набљудување е двосмислено, зашто не можете да го одделите истекувањето од патека што намерно сте ја дозволиле.
Потоа прашајте едно прашање во еден момент. Која патека ја зазема ова одредиште. Која адреса ја известува овој рефлектор. Кој кандидатски пар го избрала сесијата. Држете ги одговорите до политиката и датирајте ги, зашто ажурирање на фирмверот може да го промени стандардното однесување на начин што тивко ја поништува ланешната заклучок.
Рутерот сѐ уште е силна точка на спроведување, зашто гледа сообраќај што клиентот не може да го заобиколи без да се преконфигурира самиот. Тоа не е ветување дека секое поле во секој апликациски протокол не открива ништо, и не е замена за запишувањето на патеките што избравте да ги дозволите.