OpenVPN daŭre reprovas post TLS-eraro: kiel haltigi ĝin

La kliento konektiĝas, malsukcesas dum TLS-traktado, atendas kaj reprovas la saman servilon kun la sama rezulto. Sub kontrolilo, kiu restartigas malsukcesan procezon, tiuj provoj fariĝas senfina buklo en la ĵurnalo, kaj la unua diagnoza linio forglitas el la vido. OpenVPN liveras opcion, kiu transformas tiun traktad-malsukceson en videblan eliron anstataŭ plian reprovon. Ĝi estas agordo por diagnozo kaj kontrolo, ne riparo, do parigu ĝin kun politiko, kiu efektive lasas la procezon resti haltigita.

La ciklo, kiu kaŝas la unuan eraron

Tio, kion vi vidas, estas ripetiĝanta bloko, ne unu malsukceso: konekta provo, TLS-eraro, paŭzo kaj poste la sama sinsekvo. Ĉiu ripeto puŝas la originalan linion pli supren en la ĵurnalo. Se la unuo restartigas ĉe malsukceso, la ciklo povas daŭri horojn, sen ke iu legas la kaŭzon. La simptomo estas la buklo, kvankam la suba difekto estas unu sola traktad-problemo.

Interagaj sesioj toleras tion, ĉar pasema malsukceso povas malaperi ĉe la sekva provo. Aŭtomataj konektoj ne povas permesi al si la saman optimismon: la procezo devas halti, por ke homo aŭ monitoro vidu la staton.

Antaŭ ol ŝanĝi ion, registru unu plenan ciklon. Notu la malproksiman adreson, la TLS-etapon nomitan en la eraro, kaj ĉu la procezo entute eliras.

La reprova mekanismo malantaŭ la buklo

Reprovi estas la defaŭlto, ĉar pluraj nerilataj tempolimoj kunhavas la saman mekanismon. connect-retry starigas la intervalon inter konektaj provoj, connect-retry-max povas limigi kiom ofte ĉiu malproksima ero estas provata, kaj resolv-retry regas ripetajn nomserĉojn. TLS-traktad-malsukceso atingas tiun mekanismon kiel transporta evento, do la kliento planas plian provon anstataŭ raporti. La defaŭlto helpas ĉe malstabila ligo kaj malhelpas ĉe difekto, kiu ne povas resaniĝi.

La opcio --tls-exit ŝanĝas nur la traktad-okazon. La manlibro priskribas ĝin kiel eliri ĉe TLS-traktad-malsukceso, kio estas pli mallarĝa ol eliri ĉe ĉiu eraro. Tempolimoj, solvilo-malsukcesoj kaj aŭtentikaj rifuzoj konservas sian propran konduton.

Igi la klienton eliri ĉe TLS-malsukceso

Metu tls-exit en la profilon, kiun la kliento efektive ŝarĝas, aŭ donu --tls-exit ĉe lanĉo, kaj rulu ĝin unufoje en la malfono. Legu la eliran staton kaj la lastan protokolan linion, ĉar la stato estas tio, sur kio kontrolilo agas. Ne-nula eliro post traktad-malsukceso estas la celata rezulto. Se la procezo daŭre reprovas anstataŭ finiĝi, la opcio ne estas en la profilo, kiun la kliento efektive ŝarĝas.

La kontrolilo decidas, ĉu tiu eliro estas videbla. systemd-unuo kun Restart=always aŭ Restart=on-failure restartigas la klienton, do la buklo daŭras kaj la opcio ŝajnas fari nenion. Kontrolu la politikon antaŭ ol kulpigi la klienton:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no lasas la procezon haltigita, kaj Restart=on-failure ankoraŭ restartigas post ne-nula stato. Se vi volas, ke la malsukceso estu videbla sed la servo resaniĝu de nerilataj kraŝoj, agordu Restart=on-failure kaj uzu StartLimitBurst kaj StartLimitIntervalSec por haltigi la restartan ŝtormon. Poste legu la staton de la unuo por konfirmi la lastan eliran kodon: systemctl status raportas ĝin, kaj la ĵurnalo konservas la unuan eraron super la restartoj.

Skribu la decidon en la unuon aŭ en la profilajn notojn. Profilo, kiu eliras ĉe TLS-malsukceso, aspektas kiel akcidento al la sekva persono, se la kialo ne estas registrita. Deklaru, kiuj malsukcesoj devas haltigi la procezon kaj kiuj devas esti reprovataj.

Pruvi tion per forĵetebla finpunkto

Por vidi la konduton antaŭ ol fidi ĝin, kopiu la profilon kaj direktu la kopion al finpunkto, kiu akceptas TCP-konekton sed neniam parolas OpenVPN. Sufiĉas aŭskultanto, kiu respondas kaj poste silentas. Kun tls-exit, la kliento devus finiĝi, kiam la manpremo malsukcesas; sen ĝi, la sama profilo devus daŭre cikli. Uzu la kopion, neniam la laboran profilon.

Komparu la du ruladojn laŭ elira stato kaj laŭ la unua erara linio, ne laŭ kiom longe ĉiu daŭris. La stato diras al vi, ĉu la opcio ekfunkciis, kaj la unua linio diras, kiu etapo malsukcesis.

Forigu la testan profilon, kiam vi finos. Kopio kun intence malĝusta finpunkto estas kaptilo por iu, kiu poste lanĉas ĉiun profilon en la dosierujo.

Etapoj, kiujn ĉi tiu opcio neniam atingas

Aŭtentika rifuzo estas pli posta etapo. Se la servilo pritaksas la konton kaj rifuzas ĝin, TLS jam estis traktita, do tls-exit ne ekfunkcias. La reprovaj agordoj por aŭtentikigo estas la sekva loko por rigardi, kaj la kialo de la servilo pli gravas ol la lasta linio de la kliento. Malĝusta pasvorto kaj mankanta atestilo povas produkti similajn mesaĝojn ĉe la klienta flanko.

Mankanta itinero, malĝusta solvilo aŭ neatingebla kunligilo ankaŭ estas ekster la opcio, ĉar ili ne estas traktad-malsukcesoj. Silenta paketa perdo estas la plej malmulte evidenta kazo: depende de tio, kiom progresis la interŝanĝo, la kliento povas raporti traktad-malsukceson aŭ simple tempolimi.

Konservu la distingon en viaj notoj. La agordo estas por diagnozo kaj kontrolo, ne por riparo, do ĝi ne riparas neakordon de ĉifro, atestilan problemon aŭ malĝustan pordon. Riparu unue la kaŭzon de la malsukcesinta traktado, poste decidas, ĉu tuja eliro ankoraŭ taŭgas por la deplojo.