Ang OpenVPN na nagsisimula bago handa ang network ay hindi kabiguan

Sinimulan mo ang kliyente sa boot, aktibo ang ulat ng unit, at wala ang tunel. Ang likas na konklusyon ay nabigo ang serbisyo sa pagsisimula, at ang likas na lunas ay simulan itong muli. Pareho silang mali nang sapat na madalas para maging alituntunin: ang tumatakbong kliyente na nag-uulit ng pagsubok ay eksaktong mukhang sira kapag tinitingnan mula sa labas. Ang pagkakaiba ay nasa ginagawa ng proseso, hindi sa kalagayan ng unit.

Mito: ang nasimulang serbisyo ay nangangahulugang gumaganang tunel

Pinatutunayan ng aktibong unit na inilunsad ang proseso at hindi pa lumabas. Hindi nito pinatutunayan na na-load ang profile, tinanggap ang sertipiko, o sumagot ang kabilang dulo. Ang nakabalot na kliyente ay maaaring manatili sa paulit-ulit na pagsubok nang ilang minuto habang ang systemd ay tagumpay lamang ang iniuulat. Ang agwat na iyon sa pagitan ng kalagayan at pag-uugali ang buong paksa.

Ang kabaligtaran ay kasingkaraniwan. Maaaring lumabas ang proseso matapos mabigong basahin ang isang susi, at pagkatapos ay nag-uulat ang unit ng kalagayang bigo na walang sinasabi tungkol sa dahilan. Kailangan ng log ang dalawang kalagayan upang maihiwalay.

Basahin ang journal ng instance na iyon sa halip na ang kalagayan ng unit. Nasa log ang linyang dahilan, hindi sa label ng kalagayan.

Mito: sinasaklaw ng mga setting ng pag-uulit ang bawat kabiguan

Ang paglutas ng pangalan at mga pag-uulit ng transportasyon ay magkahiwalay na kontrol na may magkahiwalay na default. Ang resolv-retry ang namamahala sa paulit-ulit na paghahanap ng malayong hostname, at ang nakadokumentong default ay patuloy na sumusubok nang walang hanggan. Itinatakda ng connect-retry ang pagitan ng mga pagsubok, samantalang maaaring limitahan ng connect-retry-max kung ilang beses susubukan ang bawat malayong entry. Tingnan kung aling yugto ang binabanggit ng log bago baguhin ang alinman sa mga ito.

Wala sa mga ito ang naaangkop sa sirang profile, hindi mababasang pribadong susi o tinanggihang account. Kailangan ng mga iyon ng pagwawasto, at ang kliyenteng paulit-ulit na sumusubok sa mga iyon ay hindi sumusulong.

Ang paulit-ulit na pagsubok sa hindi aprubadong sertipiko magpakailanman ay hindi dahilan upang alisin ang beripikasyon. Ito ay dahilan upang basahin ang error.

Mito: sapat ang isang launcher, kaya magdagdag ng isa pa

Ang koneksyong pinamamahalaan na ng NetworkManager o ng nakabalot na unit ay hindi kailangan ng pangalawang launcher. Dalawang prosesong nag-aagawan sa parehong ruta ay gumagawa ng doble na interface, nakalilitong log at tunel na paulit-ulit na bumababa dahil sa mga dahilang walang nakikita. Karaniwang dumarating ang pangalawang kopya bilang paraan dahil mabagal ang una.

Magpasya kung aling bahagi ang may-ari ng tunel bago magdagdag ng anuman. Pagkatapos ay alisin ang isa pang launcher sa halip na patayin ito at umasa.

Tinutukoy din ng may-ari kung saan nagmumula ang mga pag-uulit at kredensyal, kaya nauuna ang desisyong ito bago ang anumang pagsasaayos. Nauuna ang pagmamay-ari dahil mismo sa kadahilanang iyon.

Ano ang talagang kailangan ng pagkakasunod-sunod

Maaaring maghintay ang pagkakasunod-sunod sa naka-configure na address, at iyon lang ang ginagarantiya nito. Pinapaliban ng network-online.target ang activation hanggang ituring ng manager na handa ang network, at ang kahulugan ng handa ay nakadepende sa manager. Wala itong sinasabi kung nalulutas ang hostname ng VPN, kung sumasagot ang listener, o kung pinapasok na ng captive portal ang device.

Basahin ang naka-install na unit at anumang drop-in bago magdagdag ng dependencies. Ang malawak na After= sa bawat serbisyo ng network ay nagpapabagal ng boot nang hindi nagtatatag ng koneksyong talagang kailangan mo.

Ayusin ang dependency na masusubok mo, at suriin ang lahat ng iba sa pamamagitan ng pagsubok sa kahandaan. Ang pagsubok na nagbubukas ng tunel ay nananalo sa timer na nanghuhula.

Ano ang nangyayari matapos unang umangat ang tunel

Ang boot ay isang pangyayari sa marami. Nagbabago ang access link, nag-eexpire ang portal session, nagre-restart ang peer. Ihiwalay ang panloob na muling pagkonekta sa paglabas ng prosesong hinahawakan ng service manager, dahil magkaiba ang may-ari ng dalawa at magkaiba ang ebidensyang iniiwan.

Ang interaktibong pagpapatotoo ay nililimitahan ang pagbangon na walang nagbabantay. Ang background unit ay hindi nagbubukas ng keyring ng desktop at hindi sumasagot sa kahilingang MFA, kaya sundin ang aprubadong kaayusan ng kredensyal para sa konteksto ng serbisyo.

Magpasya nang hiwalay kung ano ang maaaring gawin ng mga aplikasyon habang nakababa ang tunel. Ibinabalik ng pag-uulit ang koneksyon, samantalang ang patakaran sa pagharang ang nagpapasya kung pinapayagan ang direktang trapiko sa agwat na iyon.