Hoe lang moet OpenConnect een weggevallen VPN blijven proberen?

--reconnect-timeout beantwoordt één smalle vraag: na het wegvallen van de tunnel, hoe lang blijft dit clientproces het proberen voordat het opgeeft en afsluit. De handleidingspagina van OpenConnect vermeldt die optie met een gedocumenteerde standaard van 300 seconden voor nieuwe pogingen die volgen op een verloren link of een peer die stopte met antwoorden, en het getal is een deadline voor één draaiende client, geen bewijs dat de VPN bereikbaar blijft. Het is ook geen beleid om het proces in leven te houden, en daar begint het meeste misverstand.

Het misverstand groeit zodra een tweede mechanisme erbovenop zit. Een supervisor die de client herstart, een probe die de gateway pingt en het ingebouwde venster voor nieuwe pogingen kunnen allemaal op één storing reageren, en het incident levert dan drie tijdlijnen op die niemand kan verzoenen.

Wat het herverbindingsvenster werkelijk begrenst

Stel je voor dat het toegangsnetwerk een paar seconden verdwijnt. De client ziet de link wegvallen, of hoort geen antwoorden meer van de dode peer, en begint de sessie opnieuw op te bouwen terwijl hij vasthoudt wat hij kan. De pogingen gaan door tot de gateway weer accepteert of het venster afloopt, en een afgelopen venster eindigt in een exit die niet nul is. Die exit, niet de time-outwaarde, is het punt waar het eigenaarschap van de levenscyclus overgaat naar wie het proces ook bewaakt.

Het venster zegt niets over hoe vaak een probe draait, en het kan de authenticatie niet verlengen. Als de gateway de sessie heeft ingetrokken, of het account nu een nieuwe tweede factor eist, maakt langer wachten de oude sessie niet opnieuw geldig. Een nieuwe poging slaagt alleen als het pad terugkomt, de gateway de sessie nog herkent en de gevraagde inloggegevens bruikbaar blijven, dus lees het getal als een deadline en niet als een levensvatbaarheidsinterval.

Het venster bepaalt ook niet wat toepassingen doen terwijl het loopt. Afhankelijk van het platform en hoe ver de storing kwam, kan de client opnieuw verbinden terwijl de routes nog zijn geïnstalleerd, of nadat ze zijn ingetrokken. Daarom blijft een verzoek dat midden in een storing wordt gedaan, hangen tot de time-out in plaats van snel te mislukken.

Supervisor-herstarten en clientpogingen zijn twee lagen

Laat de draaiende client zijn eigen venster verbruiken, en laat de servicemanager op de exit reageren. Een client op de voorgrond onder systemd met een herstartbeleid geeft precies die tweedeling: pogingen gedurende een begrensde periode, daarna één herstartbeslissing. Het resultaat is één tijdlijn die je achteraf nog kunt reconstrueren.

Een client op de achtergrond plus een onafhankelijke poller die een tweede kopie start wanneer hij geen interface ziet, is het patroon dat misgaat. Dan vechten beide processen om hetzelfde apparaatknooppunt, de routes en de resolver-instellingen. Als je echt een daemon wilt, zet de optie dan op de commandoregel waarmee de client werkelijk start:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Twee details in die regel wegen zwaar. --background koppelt het proces los, zodat het pid-bestand het enige betrouwbare handvat erop wordt, en de time-out wordt alleen verbruikt zolang datzelfde proces leeft; een supervisor die het doodt, laat geen budget over om door te gaan.

Opzettelijke verbrekingen hebben hun eigen signaal nodig. Een geplande pauze en een echte storing zien er voor een naïeve waarnemer identiek uit, beide worden gelezen als „niet verbonden”. Stuur de pauze via de stopbewerking van de supervisor, of een markering die de wrapper begrijpt, zodat een bewuste stop geen herstart uitlokt die niemand heeft gevraagd.

Voorkomen dat de overdracht het tegen de pogingslus opneemt

Onafhankelijk herstel hangt af van inloggegevens die zonder aanwezige persoon worden vernieuwd. Een sleutelhanger die alleen in een interactieve desktopsessie opent, of een token dat altijd een getypte code nodig heeft, laat de client stranden in de authenticatiefase zodra het pad terug is. Regel die werkstroom voordat je het venster verlengt, want een langer venster geeft alleen dezelfde geblokkeerde prompt meer tijd om te mislukken.

Serververificatie mag niet worden versoepeld om prompts te verminderen. Juist de pin of het vertrouwensanker dat de gateway valideert, maakt een automatische herverbinding veilig, en het uitschakelen daarvan om een certificaatvraag te vermijden ruilt een zichtbare onderbreking in voor een onzichtbare. Houd de geverifieerde identiteit en repareer in plaats daarvan de prompt; een client die bereid is met elke gateway te verbinden, is slechter dan een die stopt en wacht.

De aanwezigheid van een interface is ook geen gezondheidssignaal. Een tunnelapparaat kan bestaan met een dode sessie erachter, en een startproces kan bestaan zonder enige tunnel. Geen van die observaties doorstaat een echt verzoek. Gezondheid moet komen van wat de gebruiker nodig heeft, zoals een verzoek dat door de tunnel naar een bekende interne dienst gaat.

Wat te verifiëren tijdens en na een storing

Voer vier gebeurtenissen uit als aparte tests: een onderbreking korter dan het venster, een storing langer dan dat, een authenticatiefout en een bewuste stop. Elk moet eindigen in een andere, voorspelbare toestand, en de grens tussen de eerste twee is de hele reden om een waarde te kiezen.

Houd de controles naar buiten gericht, want de procestabel bewijst op zichzelf heel weinig. Kijk of de pid stabiel blijft tijdens de korte onderbreking, en bevestig daarna dat hij weg is en één keer vervangen na de lange:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Bevestig tijdens de korte onderbreking dat de client echt opnieuw probeerde in plaats van vroeg af te sluiten, en dat routes en resolver-vermeldingen zonder duplicaten terugkwamen. Voor de langere storing bevestigt u een schone exit en precies één herstart daarna. Voor de authenticatiefout bevestigt u dat de client niet draait tegen een gateway die hem blijft weigeren. Voeg een controle toe dat de pid terugkeert naar één waarde in plaats van zich op te hopen.

Voor de bewuste stop moet de health-URL onbereikbaar blijven en moet het proces omlaag blijven. Sluit dan de lus vanaf de toepassingskant: hetzelfde verzoek moet mislukken terwijl de tunnel weg is en moet slagen nadat hij terugkomt, vanaf het bronadres dat uw beleid verwacht. Een groen tunnelpictogram is geen bewijs, maar een voltooid verzoek is dat wel.