Hypervisor ng home lab hindi maabot sa pamamagitan ng VPN: saan titingin

Bumangon ang tunnel, nag-time out ang web page ng hypervisor, at sinasabi ng kliyente na konektado ito. Ang kombinasyong iyon ay nag-aalis ng maraming bagay: gumagana ang handshake ng VPN, may address ang kliyente, at naaabot ang endpoint. Ang natitira ay isang maikling listahan ng mga tanong sa routing at patakaran, at may natural silang pagkakasunod-sunod. Trabahuin ang mga ito mula sa hypervisor palabas at hindi mula sa kliyente papasok, dahil ang sariling estado ng hypervisor ang pinakamurang kumpirmahin.

Simulan sa segment ng pamamahala

Kumpirmahin ang address ng pamamahala ng hypervisor at ang serbisyong nakikinig dito, at kumpirmahin na naglo-load ang pahina mula sa ibang host sa segment na iyon bago mag-diagnose ng anuman nang malayuan. Ang lokal na pagsubok na nabigo ay hindi problema sa VPN, at ito ay limang minutong pagsusuri na nakakatipid ng isang oras.

Pagkatapos ang dalawang landas. Ang kliyente ng VPN ay nangangailangan ng ruta patungo sa network ng pamamahala, na karaniwang nangangahulugan na ang AllowedIPs ng kliyente o ang mga itinulak na ruta ay kasama ang subnet na iyon. Ang hypervisor, o ang default nitong gateway, ay nangangailangan ng rutang pabalik sa pool ng mga address ng kliyente, maliban kung sadyang isinasalin ng disenyo ang pinagmulan sa pasukan. Ito ay dalawang magkahiwalay na katotohanan at ang kawalan ng alinman ay nagdudulot ng parehong timeout. Suriin ang mga ito nang hiwalay: ip route get 192.168.10.20 sa kliyente, at isang pagkuha sa host ng hypervisor na nagpapakita kung dumating man ang packet.

Payagan ang tunay na malayuang tagapangasiwa

Ang awtorisasyon ay hiwalay na tanong mula sa pagiging maabot. Gumamit ng patakaran ng gateway at host na limitado sa mga pinagmulan at serbisyong nangangailangan ng access sa pamamahala. Ang guest VPN account na nangangailangan ng isang aplikasyon sa lab ay hindi dapat makarating doon sa eroplano ng pamamahala, at ang patag na tuntunin na tumatanggap sa buong subnet ng tunnel ang paraan kung paano nangyayari iyon.

Iwanang nakabukas ang pagpapatotoo ng hypervisor mismo at ang mga pagsusuri ng sertipiko. Ang pribadong ruta ay hindi dahilan para i-click ang isang hindi inaasahang babala sa pagkakakilanlan.

Ang babala ay dapat ituring na natuklasan at hindi hadlang. Kung ang sertipiko ay hindi tumutugma sa pangalang ginamit mo, mali ang pangalan o hindi ang serbisyong iniisip mo, at ang parehong sagot ay mas mahalaga sa interface ng pamamahala kaysa saanman. Abutin ang pahina sa pangalang inilabas ng sertipiko, at hayaang ituro ng DNS ang pangalang iyon sa address ng tunnel. Ang pribadong pangalan na hindi pantay na nareresolba sa pagitan ng LAN at tunnel ay karaniwang sanhi ng mga reklamo sa sertipiko na mukhang mga sira ng VPN.

Suriin ang mga pangalawang koneksyon

Ang ilang feature ay gumagamit ng mga koneksyon na hindi ginagamit ng web page. Ang console session, ISO upload, VNC o SPICE proxy at migration channel ay maaaring gumamit ng ibang port o ibang address ng host. Kapag nag-load ang pahina at nabigo ang isang feature, basahin ang pangangailangan ng produktong iyon sa halip na buksan ang bawat port sa host.

Ang pagbubukas ng lahat ay paraan kung paano nagiging hindi pinamamahalaan ang isang interface ng pamamahala. Ang bawat karagdagang port ay isa pang tagapakinig na kailangang panatilihing naka-patch, at ang hypervisor ay naglalantad na ng sapat. Tukuyin ang partikular na koneksyon na kailangan ng feature, kumpirmahin na naaabot ito sa pamamagitan ng tunnel, at iwanang sarado ang iba. Kung igigiit ng feature ang direktang koneksyon sa address ng host na hindi maruruta sa tunnel mo, iyon ay hadlang sa disenyo na sadyang lalampasan, hindi dahilan para mag-forward ng isang range.

Panatilihin ang daan pabalik bago hawakan ang network

Bago baguhin ang virtual network na nagdadala ng sarili mong VPN, kumpirmahin na mayroon kang lokal o independiyenteng daan pabalik.

Pinakamahalaga ito sa home lab, dahil ang endpoint ng VPN ay madalas na virtual machine sa mismong hypervisor na sinusubukan mong abutin. Ang pagbabago ng virtual switch, bridge o firewall rule nang malayuan ay maaaring mag-alis ng landas na ginagamit mo, at ang session ay maaaring mabuhay nang sapat upang makita iyon.

Subukan mula sa labas ng lab at hindi mula sa LAN, at i-verify ang mga pagtanggi gayundin ang mga pahintulot. Ang network na dapat manatiling hindi maabot mula sa tunnel ay dapat manatiling gayon pagkatapos ng iyong pagbabago, at iyon ay hiwalay na pahayag mula sa pag-load ng pahina ng pamamahala. Isulat ang parehong resulta, dahil ang pangalawa ang nilalaktawan at ang mahalaga kapag lumaki ang lab.

Ang talaan na dapat itago ay maikli: ang address at serbisyo ng pamamahala, ang rutang kailangan ng bawat panig, ang mga pagkakakilanlang pinapayagang makarating, at ang daan ng pagbangon. Sapat iyon para maireprodukto ng susunod na tao ang gumaganang estado nang hindi ito muling hinihinuha.

Kung nag-time out pa rin ang pahina pagkatapos ng lahat ng iyon, kumuha sa hypervisor at hanapin ang packet bago baguhin ang isa pang tuntunin. Ang packet na hindi kailanman dumarating ay tanong sa routing o firewall; ang packet na dumarating at tinatanggihan ay tanong sa serbisyo o patakaran; ang packet na dumarating at sinasagot habang naghihintay ang kliyente ay tanong sa daan pabalik. Ang dokumentasyon ng strongSwan sa pag-forward ay nagpapaliwanag kung paano ipinapaabot ng gateway ng Linux ang trapiko ng tunnel sa isang panloob na host. Tatlong pagkuha ang nananalo sa isa pang haka-haka.