Aling IPv6 source ang pinipili ng VPN request, at bakit mahalaga ito

Nagdagdag ka ng VPN address at inaasahan mong gagamitin ito ng request, ngunit ang server ay nag-log pa rin ng lumang prefix. Walang nabigo sa tunnel; pumili ang host ng source address bago pa nito tinignan ang ruta na tinititigan mo. Ang pagpili ng IPv6 source ay isang hiwalay at nakaayos na kompetisyon sa pagitan ng mga kandidatong address ng host, at ang pinakamahabang tugmang prefix ay isa lamang tuntunin malapit sa dulo nito. Upang makuha ang resultang gusto mo, kailangang malaman kung aling tuntunin ang nanalo na. Ang mga tuntunin mismo ay nakakabagot at tumpak, at iyon ang dahilan kung bakit dapat basahin ang mga ito nang sunod-sunod.

Dalawang lookup, hindi isa

Ang pagpili ng destinasyon ay nagtatakda ng susunod na hop at ng papalabas na interface. Pagkatapos, ang pagpili ng source ay nagtatakda kung alin sa mga address ng host ang lalabas sa header, at ang dalawang tanong ay sinasagot ng magkaibang mekanismo kahit parehong gumagamit ng prefix. Ang host na may pisikal na address, pansamantalang address at VPN address ay may tatlong kandidato para sa anumang destinasyon, at ang ruta patungo sa VPN ay hindi awtomatikong nagmumungkahi ng pangatlo.

Ito ang dahilan kung bakit ang tamang ruta at maling source ay napakadaling magkasamang umiral, at kung bakit ang parehong request ay maaaring kumilos nang iba mula sa browser at mula sa sapilitang binding. Tratuhin ang dalawang lookup bilang hiwalay hanggang may ebidensya kang nag-uugnay sa kanila.

Basahin ang mga tuntunin bilang nakaayos na kompetisyon

Inililista ng RFC 6724 ang mga tuntunin nang sunod-sunod, at bawat isa ay tumitigil lamang sa tabla na iniwan ng mga nauna. Ang preperensya sa papalabas na interface at ang pagtutugma ng label ay lumalabas nang malayo bago ang paghahambing ng prefix, kaya ang address sa interface na ginagamit ng ruta ay may kalamangan nang hindi kayang burahin ng mas mahusay na tugmang prefix. Kasama rin ang pagka-luma at saklaw, at iyon ang dahilan kung bakit ang lumang address ay minsang humihinto sa pagpili nang walang nagbabago sa patakaran.

Ang praktikal na pagbasa ay hindi ka makakapangatuwiran tungkol sa panalo mula sa destinasyon lamang. Ilista ang mga kandidato, daanan ang mga tuntunin nang sunod-sunod at tingnan kung saan talaga ginawa ang desisyon.

Pansinin din na ito ang kalahating source ng problema. Ang paghahalo ng dalawang paghahambing ng prefix ay lumilikha ng mga paliwanag na parang mahigpit ngunit hinuhulaan ang maling address. Sabihin kung aling paghahambing ang ibig mong sabihin tuwing ginagamit mo ang salitang prefix sa isang ticket.

Binabago ng binding ng application ang tanong

Ang isang application ay maaaring humiling ng partikular na source address, at ang wastong tahasang pagpili ay naglilipat ng tanong mula sa “aling address ang pipiliin ng host” patungo sa “makakaabot ba ang address na iyon sa destinasyon at makakabalik”. Ang mga tool na nagbi-bind sa isang source, o humihingi ng karagdagang data tungkol sa piniling address, ay direktang naglalantad nito, at sila ang pinakamabilis na paraan upang patunayan kung aling address ang talagang ginamit ng isang koneksyon. Ang eksperimentong iyon ay mas mahusay kaysa sa ikatlong pagbasa ng routing table, dahil iniuulat nito ang napagpasyahan ng kernel at hindi ang na-configure mo. Ulitin ito pagkatapos ng pagbabago at ihambing ang dalawang sagot.

Ginagawa nitong parehong diagnostic tool at pansamantalang solusyon ang source binding: i-bind ang VPN address at tingnan kung nagtagumpay ang request. Kung oo, maayos ang landas at ang pagpili ang problema. Kung hindi, ang return path o ang patakaran sa malayong panig ang problema mula pa noong una.

Tiyakin na tinatanggap ng malayong panig ang source na iyon

Anuman ang piliin ng host, kailangan itong umangkop sa protektadong saklaw ng VPN at sa return route at mga tuntunin sa pag-access ng malayong dulo. Ang source sa labas ng mga selector ay maaaring pumasok sa tunnel at itapon sa malayong dulo, na parang one-way na pagkabigo at isinisisi sa routing. Ihambing ang piniling panloob na source sa saklaw ng proteksyon bago hawakan ang mga setting ng encryption, dahil ang pagpapalit ng mode ay hindi pumipili sa mga kandidatong address.

Ihiwalay din ang address ng panlabas na endpoint sa iyong pangangatuwiran. Tinutukoy nito ang transportasyon sa pagitan ng mga kalahok sa VPN at hindi ito ang source ng packet ng application sa loob.

Magpasya gamit ang apat na obserbasyon

Itala ang ginamit na destinasyon, ang mga karapat-dapat na lokal na source, ang aktwal na piniling source at ang epektibong papalabas na landas. Apat na linya ay sapat upang ipaliwanag ang halos lahat ng kaso, at maihahambing ang mga ito sa pagitan ng gumaganang host at ng nabigong host nang hindi pinag-uusapan muli ang teorya. Para sa hakbang ng pagpili, gamitin ang sariling sinusuportahang view ng operating system sa halip na pangalan mula sa pamantayan, dahil ang mga implementasyon ay nagdaragdag ng sarili nilang lokal na preperensya.

Kapag nagulat ka pa rin sa sagot, may ginagawa ang pag-order na hindi ginagawa ng iyong mental model, at ang lunas ay baguhin ang mga input sa halip na makipagtalo sa algorithm. Isulat ang apat na obserbasyon sa ticket at ang susunod na mambabasa ay maaaring muling gawin ang iyong konklusyon.