OpenVPN anunță că inițializarea s-a încheiat: de ce promptul nu revine

Nimic nu este blocat când terminalul devine tăcut după ultima linie din jurnal. Aceasta este forma așteptată pentru un client în prim-plan: a terminat pornirea și acum stă acolo transportând trafic. Promptul shell-ului nu este semnul de succes pe care pare.

Tratați mesajul ca granița dintre pornire și starea stabilă, pentru că exact asta marchează.

Mesajul marchează sfârșitul pornirii, nu sfârșitul procesului

OpenVPN afișează acea linie după ce a deschis dispozitivul, a configurat interfața, a instalat rutele și a terminat schimbul TLS cu partenerul. Apoi procesul continuă să ruleze, pentru că sarcina lui este să țină tunelul deschis și să transmită pachete. Un program în prim-plan nu revine la prompt cât timp își face această sarcină. Ieșirea tăcută după aceea este normală, fiindcă clientul vorbește doar când se schimbă ceva.

Dacă linia apare și conexiunea moare mai târziu, acesta este un alt eveniment, iar jurnalul va spune asta după fapt.

Ctrl+C este o decizie, nu o reparație

Apăsarea Ctrl+C trimite o întrerupere, pe care clientul o tratează ca o cerere de oprire. Promptul revine, tunelul dispare și orice sesiune care îl folosea se termină. Asta pare progres și de fapt este opusul. Dacă scopul este o conexiune persistentă, răspunsul este să mutați procesul undeva unde poate continua fără terminalul dumneavoastră, nu să îl întrerupeți.

Lăsarea lui în prim-plan este alegerea corectă în timp ce depanați, pentru că erorile ulterioare rămân vizibile în aceeași fereastră. Un minut tăcut nu dovedește nimic în nici o direcție; testați o resursă prin tunel în loc să urmăriți ieșirea.

Ce nu dovedește mesajul

Finalizarea este o afirmație locală despre configurația clientului însuși. Nu spune că cealaltă parte răspunde, că rutele instalate corespund cu ce aveți nevoie sau că rezolvarea numelor prin tunel funcționează. Un profil cu tunel divizat poate fi perfect inițializat în timp ce o partajare a companiei rămâne inaccesibilă pentru că ruta sau politica DNS nu a acoperit-o niciodată. Instanțele din partea serverului afișează o linie similară când sunt gata să accepte clienți, ceea ce nu este același lucru cu un client conectat.

«Serverul a pornit» și «laptopul poate deschide partajarea» sunt observații din două locuri diferite, iar amestecarea lor vă trimite să depanați gazda greșită.

Rulare fără terminal

Pentru o implementare persistentă, folosiți aranjamentul de serviciu pe care platforma îl susține. Pe o gazdă systemd este o instanță openvpn-client@office cu profilul în /etc/openvpn/client, pornită și activată ca să supraviețuiască repornirilor. Community OpenVPN oferă și --daemon împreună cu --log sau --log-append, ceea ce detașează procesul și trimite ieșirea într-un fișier. Ambele abordări schimbă felul în care rulează procesul; niciuna nu repară o rută sau nu face sănătoasă o aplicație la distanță.

Verificați că nu porniți o a doua instanță lângă una deja administrată de un serviciu. Doi clienți care revendică același profil produc jurnale confuze și un tunel pe care nu l-ați dorit.

Alegeți aranjamentul potrivit sarcinii

Prim-plan pentru diagnostic, serviciu pentru tot ce trebuie să supraviețuiască sesiunii, modul daemon când nu există un manager de servicii pe care să vă sprijiniți. Acestea trei acoperă cazurile obișnuite și fiecare are un motiv clar de a exista. Alegerea unuia dintre ele din greșeală este ce produce raportul «funcționează până se închide fereastra».

Când tunelul trebuie să rămână, confirmați după aceea că revine după o repornire și că jurnalele lui ajung undeva unde veți privi. Linia de inițializare apare și în acele jurnale, iar atunci nimeni nu mai trebuie să supravegheze un terminal pentru ea.