OpenVPN sa Windows: awtomatikong simulan ang tunel at panatilihin ang mga ruta

Dalawang pangangailangan ang nagkakasalimuot dito: dapat na tumaas ang tunel bago pa mag-log in ang sinuman, at dapat na sundan ito ng trapiko para sa pangalawang site. Magkaibang problema ang mga ito na may magkaibang mekanismo. Ang pag-start ng serbisyo ang nagpapasya sa una, at ang buhay ng ruta sa pangalawa. Kapag nalutas ang isa, nananatili ang isa kung saan mismo ito naroon.

Unang hakbang: ilagay ang profile kung saan ito hinahanap ng serbisyo

Nagbabasa ang serbisyo ng Windows ng mga profile mula sa isang fixed na direktoryo, at nagbabasa ang GUI mula sa parehong lugar, kaya ang isang profile na gumagana kapag ini-import mo ay maaaring hindi pa rin makita sa boot. Ilagay ang mga file na .ovpn sa direktoryo ng config ng installation, na karaniwang nasa ilalim ng Program Files. Ang profile na naiwan sa folder na Downloads ng isang user ay wala talaga sa saklaw ng serbisyo.

Itinuturo ng lumang gabay ang isang folder na config-auto, na iginagalang ng ilang build noong panahon ng 2.5 at hindi ng mga susunod na release. Kaya maaaring gawing katahimikan ng isang upgrade ang gumaganang autostart, nang walang anuman sa log tungkol sa mga kredensyal. Kumpirmahin kung aling direktoryo ang aktwal na binabasa ng naka-install na build bago ilipat ang anumang file.

Kapag may ilang profile sa isang makina, bigyan ang bawat isa ng pinangalanang adapter sa pamamagitan ng dev-node. Kung hindi, nag-aagawan sila sa parehong interface at nabigo ang pangalawa sa paraang mukhang problema sa kredensyal.

Ikalawang hakbang: simulan ang serbisyo, hindi ang icon sa tray

Ang paglalagay ng serbisyo OpenVPN sa Automatic ay nagpapasimula nito sa boot nang walang pag-log in. Iyon ang mekanismo, at ang icon sa tray ay hindi bahagi nito. Kapag pag-aari ng serbisyo ang koneksyon, maaaring walang ipakitang icon o status ang GUI, na inaasahan at hindi sira.

Ang bunga ay ang pagdisconnect ay nangangahulugang paghinto ng serbisyo, hindi pag-click ng Disconnect. Sabihin ito sa sinumang sumusuporta sa makina, kung hindi, ang unang tawag sa suporta ay tungkol sa nawawalang icon.

Tiyakin na mababasa ng account ng serbisyo ang profile at ang key material. Ang problema sa pahintulot sa boot ay mukhang eksaktong pagkabigo ng pagpapatotoo sa log.

Ikatlong hakbang: itali ang ruta sa tunel

Ang permanenteng entry ay maling kasangkapan dito. Ang pagdaragdag ng ruta gamit ang -P ay ginagawa itong nakakaligtas sa mga reboot at, mas masahol pa, nakakaligtas sa pagsasara ng tunel. Kapag patay ang VPN, nakaturo pa rin ang unlapi sa isang gateway na wala na, kaya hindi maabot ng host ang destinasyong iyon hanggang may magbura ng entry.

Tatlong alternatibo ang kumikilos nang tama. Itulak ang ruta mula sa server, na nagdaragdag nito kapag kumonekta at nag-aalis kapag nadiskonekta. Idagdag ito sa isang script na route-up na nagbabasa ng route_vpn_gateway, para ang susunod na hop ay mula sa napagkasunduang tunel. O gamitin ang Add-VpnConnectionRoute sa isang native na profile ng VPN sa Windows, na nagtatali ng unlapi sa koneksyong iyon.

Kapag nag-aalok ang server ng higit sa kailangan ng site na ito, tinatanggihan ng route-nopull ang mga itinulak na ruta at hinahayaang lokal na lubos ang talahanayan. Bagay ito sa isang pinagsasaluhang profile na ang mga user ay hindi dapat makatanggap ng corporate default na ruta.

Ikaapat na hakbang: mabuhay sa isang malamig na boot

Ang pagsisimula ng serbisyo bago umiral ang network stack ay nagdudulot ng isang bigong pagtatangka at walang pag-uulit. Ang paglalagay nito sa Automatic (Delayed Start), o pagdaragdag ng dependency sa serbisyo ng network, ay nag-aalis ng karerang iyon. Pagkatapos ay ulitin ang pagsubok sa boot at tiyakin na hindi na kailangan ang ikalawang pagtatangka.

Ang mga pagbabago sa ruta at adapter ay nangangailangan ng karapatan ng administrator. Ang startup shortcut ng bawat user ay wala nito, kaya ang isang script na gumagana mula sa elevated shell ay maaaring tahimik na walang gawin sa pag-log on. I-iskedyul ito bilang gawain na may pinakamataas na pribilehiyo, o hayaang ang serbisyo ang mamahala ng pagbabago. Pagkatapos ay subukan ito bilang user na talagang mag-log in.

Subukan ang pagkakasunod-sunod na aktwal mong ipinapakalat, hindi ang kaya mong i-trigger sa kamay. Ang malamig na boot ay ang tanging pagsubok na nagsasanay ng pagkakasunod-sunod.

Ikalimang hakbang: i-verify nang walang GUI

Pagkatapos ng reboot at pag-log in, suriin ang tatlong bagay nang hindi binubuksan ang GUI. Dapat may address ang adapter,dapat ipakita ng talahanayan ng ruta ang unlapi ng site kasama ang gateway ng tunel bilang susunod na hop, at dapat tumugon ang ping sa isang address sa kabilang panig. Ang bawat pagsusuri ay tumutugma sa ibang mekanismo mula sa mga hakbang sa itaas.

Kapag hindi kailanman lumitaw ang adapter, ang driver ang pinaghihinalaan at hindi ang profile. Ang dalawang pagkabigong iyon ay hindi magkatulad sa log, at isa lamang sa kanila ang tumutugon sa muling pag-install ng software.