Прашањето звучи како едно пребарување, а всушност се три одлуки. Која рута ја зема binding request, кој извор го избира јадрото за таа рута и дали нешто на патот го препишува тој извор. Променете една од трите и адресата што ја пријавува STUN серверот се менува со неа. Затоа тврдењето дека VPN-от стои на рутерот само по себе не кажува речиси ништо.

Одлуката почива на три факти

Прво рутата: правилата на политиката и табелата за рутирање одлучуваат дали барањето излегува низ тунелот или низ обичниот WAN, а исклучената дестинација ја зема втората патека дури и кога тунелот е активен. Потоа изворот: јадрото избира извор за избраната рута, а тој избор зависи од претпочитаниот извор на рутата и од секое правило што се совпаднало. На крајот преводот: NAT на патот го заменува избраниот извор. Рефлектираната адреса е производ на сите три, а не својство на тунелот.

Променете една од трите и одговорот се менува додека секоја компонента во сопствениот дневник уште изгледа здрава. Тоа е вообичаената причина зошто оваа дијагноза заглавува.

Запишете ги трите факти за текот што го тестирате пред да почнете. Интерфејс, рута и правило за превод се доволни за да се предвиди резултатот, а токму предвидувањето го прави изненадувањето поучно. Ако не можете да пополните еден од трите, таа празнина е вистинскиот наод.

Следете еден binding request низ патеката

STUN binding request бара од серверот да ја пријави забележаната изворна транспортна адреса. Одговорот ја опишува патеката што ја помина барањето, а не попис на интерфејси на клиентската машина. Две барања по две патеки искрено ќе пријават две различни адреси.

Path takenSource the reflector seesWhat it means
Tunnel to a public exit that translatesThe exit's public addressThe reflector learns nothing about the LAN
Tunnel to a private reflector, translated to the tunnel address, no later translationThat tunnel addressAn internal identifier is disclosed to that reflector
Excluded flow over the ordinary WANThe WAN addressThe tunnel was not used at all

Читајте ја табелата како збир услови, а не како мени на добавувачи. Средниот ред бара приватниот рефлектор да биде достапен под сопственото рутирање и peer политика на тунелот; тоа е конфигурациски факт што можете да го проверите, а не нешто што подразбира ниво на сметка. Долниот ред обично е оној што е важен за политиката, бидејќи тој сообраќај требаше да остане во тунелот. Меѓу нив е вообичаениот случај, во кој излезот преведува, а рефлекторот го гледа само излезот.

Кандидатите домаќин и серверски-рефлексните кандидати доаѓаат од различни механизми, па списокот на кандидати не кажува која патека медиумите навистина ја користеле. Читајте го избраниот пар, а не дневникот за собирање, кога сакате да знаете каде отишла сесијата.

Што не е адресата на тунелот на рутерот

Адреса на тунел доделена на рутерот припаѓа на интерфејс на рутерот. Прелистувач на домаќин во LAN има свои адреси на интерфејси и нема директен поглед во тунелскиот интерфејс на рутерот. Ако се постапува со двете како замениви, се добиваат самоуверени погрешни одговори за тоа што може да научи една web-страница.

Препраќањето е она што ги поврзува. Барањето го поминува рутерот како рутиран сообраќај, а неговиот извор е она што го создале рутирањето и преводот.

Ако патеката на тунелот го зачува LAN изворот, приватен рефлектор може да ја научи таа LAN адреса, што е вистинско откривање и различно од адресата на тунелот. Ако патеката преведува во адресата на тунелот, рефлекторот наместо тоа ја учи адресата на тунелот. Двата исхода се согласуваат со истиот прелистувач на истиот домаќин, затоа набљудувањето мора да биде врзано за одреден тек. Прашајте го јадрото кој извор би го користело пред да ја обвините апликацијата.

Откривање наспроти заобиколување: два наода, две поправки

Рефлектирана адреса на тунел открива внатрешен идентификатор по патека што сте ја дозволиле. Барање директно преку WAN заобиколува патека што сте сакале да ја барате. Првото е информациско прашање, второто прашање на спроведување, и се поправаат на различни места. Ако ги споите во еден збор, добивате поправка што не решава ниту едно.

WebRTC го прави ова повидливо без да го направи погрешно, бидејќи собирањето кандидат не е исто што и неговиот избор.

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

Извршете го барањето за рута за секоја дозволена адреса на рефлектор, со изворот што очекувате дека тој тек го носи, потоа извршете го повторно за исклучените опсези за да видите што избира резервата. Споредете ги двата одговора со политиката што сте ја запишале. Кога се разликуваат на начин што не сте го намериле, ја најдовте точката за поправка, а воопшто не моравте да ја толкувате списокот на кандидати на прелистувачот.

Поврзани статии