OpenVPN siger, at initialiseringen er fuldført: hvorfor prompten ikke kommer tilbage

Intet hænger, når terminalen bliver tavs efter den sidste loglinje. Det er den forventede form for en klient i forgrunden: den er færdig med at starte og sidder nu der og bærer trafik. Kommandoprompten er ikke det tegn på succes, som den ser ud til.

Behandl meddelelsen som grænsen mellem opstart og stabil tilstand, for det er præcis det, den markerer.

Meddelelsen markerer slutningen på opstarten, ikke slutningen på processen

OpenVPN udskriver den linje, efter at den har åbnet enheden, konfigureret grænsefladen, installeret ruter og afsluttet TLS-udvekslingen med partneren. Derefter fortsætter processen med at køre, fordi dens opgave er at holde tunnelen åben og videresende pakker. Et program i forgrunden vender ikke tilbage til prompten, mens det stadig udfører den opgave. Tavs output bagefter er normalt, da klienten kun siger noget, når noget ændrer sig.

Hvis linjen vises, og forbindelsen senere dør, er det en anden hændelse, og loggen vil sige det bagefter.

Ctrl+C er en beslutning, ikke en løsning

Et tryk på Ctrl+C sender en afbrydelse, som klienten behandler som en anmodning om at lukke ned. Prompten kommer tilbage, tunnelen forsvinder, og enhver session, der bruger den, slutter. Det ligner fremskridt og er faktisk det modsatte. Hvis målet er en vedvarende forbindelse, er svaret at flytte processen et sted hen, hvor den kan køre videre uden din terminal, ikke at afbryde den.

At lade den blive i forgrunden er det rigtige valg, mens du fejlfinder, fordi senere fejl forbliver synlige i samme vindue. Et stille minut beviser intet i nogen af retningerne; test en ressource gennem tunnelen i stedet for at holde øje med output.

Hvad meddelelsen ikke beviser

Fuldførelse er et lokalt udsagn om klientens egen opsætning. Den siger ikke, at den anden side svarer, at de installerede ruter passer til det, du har brug for, eller at navneopløsning gennem tunnelen virker. En profil med delt tunnel kan være helt initialiseret, mens en virksomhedsressource forbliver utilgængelig, fordi ruten eller DNS-politikken aldrig dækkede den. Instanser på serversiden udskriver en lignende linje, når de er klar til at tage imod klienter, hvilket ikke er det samme som, at en klient er forbundet.

»Serveren startede« og »laptop’en kan åbne ressourcen« er observationer fra to forskellige steder, og at blande dem sender dig i gang med at fejlfinde den forkerte vært.

At køre den uden terminal

Til en vedvarende udrulning skal du bruge den serviceopsætning, som platformen understøtter. På en systemd-vært er det en openvpn-client@office-instans med profilen i /etc/openvpn/client, startet og aktiveret, så den overlever genstarter. Community OpenVPN tilbyder også --daemon sammen med --log eller --log-append, hvilket løsner processen og sender output til en fil. Begge tilgange ændrer, hvordan processen kører; ingen af dem retter en rute eller gør et eksternt program sundt.

Kontroller, at du ikke starter en anden instans ved siden af den, en tjeneste allerede styrer. To klienter, der kræver samme profil, giver forvirrende logge og én tunnel, du ikke havde tænkt dig.

Vælg den opsætning, der passer til opgaven

Forgrund til diagnostik, service til alt, der skal overleve sessionen, daemontilstand når der ikke er nogen serviceadministrator at læne sig op ad. De tre dækker de almindelige tilfælde, og hver har en klar grund til at findes. At vælge en af dem ved et uheld er det, der giver rapporten »det virker, indtil vinduet lukkes«.

Når tunnelen skal blive, skal du bagefter bekræfte, at den kommer tilbage efter en genstart, og at dens logge lander et sted, du vil se. Initialiseringslinjen vises også i de logge, og på det tidspunkt behøver ingen at holde øje med en terminal for dens skyld.