VPN ng bisita at VPN ng host: aling ruta ang talagang nananalo

Dalawang kliyente ang tumatakbo nang sabay, bawat isa ay kumbinsido na siya ang may-ari ng default na ruta, at ang sintomas ay dumarating bilang kakaibang bagay: gumagana ang isang aplikasyon ng bisita, ang isa ay nare-resolve sa maling lugar. Ang isang VPN sa loob ng bisita at isang VPN sa host ay maaaring magkasamang umiral, ngunit kapag ang panlabas na landas at ang panloob na patakaran ay nagkasundo kung sino ang magdadala ng ano. Ang pagsisimula ng dalawa ay hindi mismo gumagawa ng kadena. Itala muna ang koneksyon, pagkatapos ay baguhin ang isang bagay sa isang pagkakataon.

Itala muna ang koneksyon ng bisita

Naabot ng bisita ang kanyang VPN server sa landas na ibinigay ng hypervisor: NAT sa likod ng host, isang tulay patungo sa pisikal na segment o isang network na para sa host lamang na may routing na idinagdag sa itaas. Binabago ng bawat koneksyon kung ano ang nakikita ng bisita at kung ano ang magagawa ng host sa trapiko nito. Sa ilalim ng NAT ang mga packet ng bisita ay tila nagmumula sa host, kaya ang sariling tunnel ng host ay maaaring magdala sa kanila nang walang alam ang bisita. Sa ilalim ng tulay ang bisita ay may sariling presensya sa segment at sariling default na gateway.

Itala ang koneksyon bago hawakan ang anumang configuration, kasama kung aling kliyente ang dapat magdala ng aling aplikasyon. Ang pangungusap na iyon ang lumulutas sa karamihan ng ganitong kaso, dahil ang dalawang kliyente ay karaniwang itinayo sa magkaibang palagay. Ang bisitang inaasahang gagamit ng tunnel ng host ay hindi rin dapat magkaroon ng sariling karibal na default na ruta.

Sundan ang endpoint ng bisita palabas

Ang VPN ng bisita ay nangangailangan ng magagamit na landas patungo sa sariling server bago gumana ang anupamang bagay. Kapag nakataas ang tunnel ng host at ang bisita ay nakaupo sa likod ng NAT, ang handshake ng bisita ay lumalabas sa tunnel ng host, na alinman sa disenyo o aksidenteng walang naidokumento. Kapag bumagsak ang tunnel ng host at umasa ang bisita dito, nawawalan ng koneksyon ang bisita nang walang kahit isang pagbabago sa panig nito. Ang pagsunod sa endpoint palabas ay nagsasabi kung alin sa dalawang iyon ang talagang mayroon ka.

Ang malawak na ruta sa alinman sa dalawang konteksto ay humuhuli ng trapikong inaasahan ng kabilang kliyente. Ang rutang 0.0.0.0/0 sa loob ng bisita at ang kliyente ng host na may buong tunnel ay parehong nag-aangkin ng lahat, at ang huling naipatupad ang nananalo. Ang mga overlap sa pagitan ng mga virtual network ng bisita, ng lokal na LAN at ng malalayong network ay may kaparehong epekto para sa mga pribadong prefix, na may mga pagkabigo na kahawig ng mga problema sa authentication; ang pag-uugali ng pagsasalin ng address ay kapareho ng inilarawan para sa container networking.

Ihambing ang tala bago at pagkatapos

Kumuha ng baseline na patay ang tunnel ng host, o sa anumang kontroladong estado na pinapayagan ng patakaran mo, at itale ang ruta at resolver ng bisita. Pagkatapos ay ilapat ang pinagsamang configuration at ihambing ang dalawang tala, na panatilihing buo ang mga pangangailangan sa privacy. Kung ang direktang baseline ay hindi angkop, isulat ang limitasyong iyon sa tala sa halip na laktawan ang paghahambing.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Ang query ng ruta ay nagpapangalan ng interface at source address na magdadala ng partikular na destinasyon, at ito ang pinakamahalagang linya sa imbestigasyong ito. Ipinapakita ng listahan ng panuntunan kung ang policy routing ay nagpapadala ng ilang destinasyon sa pamamagitan ng ikalawang talahanayan. Ipinapakita ng output ng resolver kung sinundan ng DNS ang tunnel ng bisita o nanatili sa landas ng host. Patakbuhin ang parehong tatlong utos bago at pagkatapos ng pagbabago, at ang pagkakaiba ang magsasabi ng salarin.

Panatilihing malinaw ang pagmamay-ari sa mga restart

Ang paghihigpit sa lokal na pag-access ng isang kliyente ng host ay maaaring humarang sa trapiko patungo sa virtual NAT o tulay, at ang paghihigpit na iyon ay madalas na napagkakamalang problema sa kredensyal ng bisita. Basahin ang naidokumentong pag-uugali ng kliyente sa halip na patayin ang paghihigpit upang pumasa ang isang pagsubok. Pagkatapos ng suportadong pagwawasto, subukan muli ang aplikasyon ng bisita at ang patakaran sa pagkabigo na kailangan mo. Ang host na matagumpay na muling kumokonekta ay walang pinapatunayan tungkol sa ruta o resolver ng bisita.

Magpasya kung aling panig ang may-ari ng default na ruta at isulat iyon sa runbook. Ang restart ng bisita o pagpapalit ng network sa host na tahimik na binabaligtad ang pagmamay-ari ay gumagawa ng ulat ng bug tungkol sa isang VPN na hindi kailanman nagkasala. Dapat na makaligtas ang kaayusan sa isang reboot nang walang naaalala ng kahit sino kung bakit ito gumana.