Bakit hindi tinutukoy ng pagkakasunod-sunod ng adapter ang ruta ng VPN sa lab mo

Ang pagiging una ng adapter 1 sa listahan ng hypervisor ay pagkakasunod-sunod lamang ng pagpapakita, at hindi ito binabasa ng talahanayan ng ruta ng bisita. Ang nagtatakda ng landas ay ang prefix, ang sukatan at anumang tuntunin ng patakaran na nalalapat bago ang dalawa. Kaya ang pagdaragdag ng adapter na tulay sa isang VM sa lab ay maaaring lumikha ng ikalawang default na landas habang ang lumang interface ng NAT ay lumilitaw pa rin na naroon at nakabilang na pangalawa. Ang resulta ay isang VM na kung minsan ay gumagamit ng tunel at kung minsan ay hindi, nang walang anumang pagbabago sa configuration na magpapaliwanag nito.

Tatlong kundisyon ang nagtatakda ng landas

Ang tatlong kundisyon ay kung aling prefix ang mas tiyak, ano ang ginagawa ng mga sukatan kapag pantay ang mga prefix, at anong mga tuntunin ang inilapat ng bisita pagkatapos ng pagbabago sa hardware. Ang bawat isa ay masasagot ng isang utos lamang, at wala sa mga ito ang may kinalaman sa pagbilang ng hypervisor.

Ang huling puntong iyon ang desisyon: kung hindi mo masabi kung aling prefix ang mananalo para sa sariling address ng dulo ng VPN, wala kang patakaran sa pagruruta, mayroon kang topolohiya na nagkataong gumagana ngayon.

Unang kundisyon: aling prefix ang mananalo

Ang rutang patungo sa 10.8.0.0/24 ay tinatalo ang default na ruta para sa isang address sa loob nito, anuman ang mga sukatan at anuman ang pagkakasunod-sunod ng adapter. Ito ang dahilan kung bakit ang isang kliyente ng VPN na nagluluklok ng tiyak na ruta ay patuloy na gumagana kahit lumitaw ang ikalawang adapter na may mas mababang sukatan: ang pagiging tiyak ay nananalo bago isaalang-alang ang gastos. Suriin gamit ang ip route show ang talahanayang inaakala mong ginagamit, at gamit ang ip route get 203.0.113.9 ang sagot na talagang ibibigay ng kernel para sa isang tiyak na destinasyon.

Ang sariling address ng dulo ang pinakamahalagang pagsubok. Kung ang address ng server ng VPN ay nireresolba sa pamamagitan ng bagong idinagdag na adapter na tulay, maaaring hindi kailanman maitatag ang tunel, o maitatag ito at pagkatapos ay mawala ang sarili nitong landas ng transportasyon. Itanong nang tiyak ang address na iyon sa halip na ipagpalagay na ang interface ng tunel ang sagot.

Ikalawang kundisyon: ano ang ginagawa ng sukatan at ano ang hindi

Ang tungkulin nito ay mas makitid kaysa inaasahan ng karamihan. Ang mga sukatan ay nagtatanggal ng pagkakapantay sa pagitan ng mga ruta patungo sa parehong prefix; hindi nila hinahayaang talunin ng mas malawak na ruta ang mas tiyak. Sa pagkakapantay, mas pinipili ang mas maliit na bilang, at ang magkaibang sistema ng pagpapatakbo ay nagbibilang sa magkasalungat na direksyon, kaya ang payong kinopya sa pagitan ng Linux at Windows ay madalas na sumasalungat sa sarili nito.

Sa bisita, ang ip route show ay naglilimbag ng sukatan sa tabi ng bawat ruta, at ang Get-NetRoute sa Windows ay naglilimbag ng InterfaceMetric at sukatan ng ruta. Basahin ang dalawa, dahil ang mabisang kagustuhan ay maaaring kabuuan at hindi isang field. Kung may dalawang default na ruta, iyon ang natuklasan: may dalawang labasan ang bisita, at kung alin ang mananalo ay tungkulin ng mga bilang na maaaring baguhin ng pagbabago sa hardware.

Ikatlong kundisyon: ano ang aktwal na inilapat ng bisita

Ang configuration ay hindi katulad ng inilapat na kalagayan. Ang mga pangalan ng interface ay hindi matatag sa mga pagbabago sa hardware sa bawat plataporma, at ang configuration na tumugma sa pangalan ay maaaring hindi na mailapat sa anuman ngayon.

Suriin ang inilapat na kalagayan at hindi ang pinlano. Ipinapakita ng ip -br link ang mga interface na umiiral ngayon, at sa host na may NetworkManager ipinapakita ng nmcli connection show kung aling profile ang nakatali sa aling device. Ang profile na nabigong makatali ay nag-iiwan sa interface na bukas nang walang address, na mukhang problema sa pagruruta ngunit problema sa pagpapangalan. Ang mga naibalik na snapshot ay nagpapalala nito, dahil ang naka-save na kalagayan ng bisita ay maaaring tumukoy sa mga pagkakakilanlan ng adapter na hindi na ibinibigay ng bagong hardware.

Panatilihing maaaring ulitin ang topolohiya ng lab

I-save ang mga pinlanong koneksyon sa virtual na network kasama ng configuration ng bisita, upang ang pagmamapa mula sa tungkulin patungo sa adapter ay nakasulat at hindi hinuhulaan mula sa posisyon sa listahan.

Karaniwang sapat ang apat na tungkulin upang pangalanan: pribadong link, pamamahala, panlabas na transportasyon at tunel. Ang bawat isa ay dapat tumugma sa isang tiyak na adapter at isang tiyak na interface ng bisita, sa isang file.

Pagkatapos ay subukan ang aktwal na aplikasyon pagkatapos ng pagbabago sa hardware, pag-restart o naibalik na snapshot, at isama ang ruta patungo sa dulo ng VPN sa pagsubok na iyon. Kung ang VM ng gateway ang dapat maging tanging labasan, tiyakin na ang VM ng pagsubok ay walang hindi sinasadyang ikalawang default na landas, dahil ang adapter na tulay ay nagdaragdag ng eksaktong ikalawang default na landas. Subukan mula sa bisita, hindi mula sa console ng hypervisor, dahil maaaring hindi magkasundo ang dalawa kung aling interface ang alin.

Inilalarawan ng dokumentasyon ng networking ng VirtualBox ang mga mode ng adapter at kung ano ang kinakabitan ng bawat isa, at iyon ang bahaging sulit basahin bago magdagdag ng pangalawa. Ang lab na tumutukoy kung aling adapter ang nagsisilbi sa bawat tungkulin ay ginagawang maipaliwanag ang pagbabago ng ruta. Ang lab na umaasa sa pagbilang ng hypervisor ay ginagawang eksperimento ang bawat pagbabago.