OpenVPN startanta antaŭ ol la reto estas preta ne estas fiasko

Vi startas la klienton ĉe la ŝargado, la unuo raportas aktiva, kaj la tunelo forestas. La natura konkludo estas ke la servo fiaskis starti, kaj la natura riparo estas restarti ĝin. Ambaŭ sufiĉe ofte malpravas por meriti regulon: funkcianta kliento, kiu reprovas, aspektas de ekstere ĝuste kiel difektita. La diferenco kuŝas en tio, kion faras la procezo, ne en la stato de la unuo.

Mito: startinta servo signifas funkciantan tunelon

Aktiva unuo pruvas ke la procezo estis lanĉita kaj ne eliris. Ĝi ne pruvas ke la profilo ŝarĝiĝis, ke la atestilo estis akceptita, aŭ ke la alia flanko respondis. Pakaĵa kliento povas sidi en reprova buklo dum minutoj, dum systemd raportas nur sukceson. Tiu breĉo inter stato kaj konduto estas la tuta temo.

La kontraŭa kazo estas same ofta. La procezo eble eliris post malsukceso legi ŝlosilon, kaj la unuo tiam raportas fiaskan staton, kiu diras nenion pri la kialo. Ambaŭ statoj bezonas la protokolon por esti distingitaj.

Legu la protokolon por la kazo anstataŭ la staton de la unuo. La kialo estas en la protokolo, ne en la statusa etikedo.

Mito: reprovaj agordoj kovras ĉiun fiaskon

Nomresolvado kaj transportaj reprovoj estas apartaj kontroloj kun apartaj defaŭltoj. resolv-retry regas ripetajn serĉojn de fora gastiganta nomo, kaj la dokumentita defaŭlto daŭre provas senfine. connect-retry fiksas la intervalon inter provoj, dum connect-retry-max povas limigi kiom da fojoj ĉiu fora rikordo estas provata. Kontrolu kiun etapon la protokolo nomas antaŭ ol ŝanĝi iun ajn el ili.

Nenio el tio validas por difektita profilo, nelegebla privata ŝlosilo aŭ malakceptita konto. Ili bezonas korekton, kaj kliento, kiu daŭre reprovas ilin, ne progresas.

Senfine reprovi neaprobatan atestilon ne estas kialo forigi la kontroladon. Ĝi estas kialo legi la eraron.

Mito: unu lanĉilo sufiĉas, do aldonu alian

Konekto jam administrata de NetworkManager aŭ de pakaĵa unuo ne bezonas duan lanĉilon alkroĉitan. Du procezoj konkurantaj pri la samaj itineroj produktas duplikatajn interfacojn, konfuzajn protokolojn kaj tunelon, kiu flirtas pro kialoj, kiujn neniu vidas. La dua kopio kutime alvenas kiel ĉirkaŭvojo ĉar la unua estas malrapida.

Decidu, kiu komponanto posedas la tunelon antaŭ ol aldoni ion ajn. Poste forigu la alian lanĉilon anstataŭ malŝalti ĝin kaj esperi.

La posedanto ankaŭ determinas de kie venas reprovoj kaj akreditiloj, tial ĉi tiu decido antaŭas ĉian agordadon. Posedado venas unue ĝuste pro tiu kialo.

Kio vere bezonas ordigon

La ordigo povas atendi agorditan adreson, kaj tio estas ĉio, kion ĝi garantias. network-online.target prokrastas aktivigon ĝis la administranto konsideras la reton preta, kaj la difino de preta dependas de la administranto. Ĝi diras nenion pri tio, ĉu la VPN-gastignomo solviĝas, ĉu la aŭskultanto respondas, aŭ ĉu kaptita portalo akceptis la aparaton.

Legu la instalitan unuon kaj ĉiujn drop-in dosierojn antaŭ ol aldoni dependecojn. Larĝa After= sur ĉiu reta servo prokrastas la ŝargadon sen establi la konekton, kiun vi efektive bezonas.

Ordigi tiun dependecon, kiun vi povas testi, kaj kontrolu ĉion alian per preteca sondilo. Sondilo, kiu malfermas la tunelon, superas tempigilon, kiu divenas.

Kio okazas post kiam la tunelo unue leviĝas

Ŝargado estas unu evento inter multaj. La alirilo ŝanĝiĝas, portala sesio eksvalidiĝas, la samulo restartas. Distingu internan rekonekton de proceza eliro, kiun traktas la serva administranto, ĉar la du havas malsamajn posedantojn kaj lasas malsamajn spurojn.

Interaga aŭtentikigo limigas senhoman reakiron. Fona unuo ne malŝlosas labortablan ŝlosilringon nek respondas al MFA-peto, do sekvu la aprobitan akreditilan aranĝon por la serva kunteksto.

Decidu aparte, kion aplikoj rajtas fari dum la tunelo estas malsupra. Reprovo restarigas konekton, dum bloka politiko decidas ĉu rekta trafiko estas permesata en tiu breĉo.