Koble en OpenVPN-klient til på nytt: tre kontroller, tre omfang

Noen ber om at VPN-klienten kobles til på nytt, og forespørselen kan bety tre forskjellige ting. Det kan bety å droppe én autentisert økt, å varsle hver klient om at en UDP-server forsvinner, eller å starte daemonen selv på nytt. Hver har ulik påvirkningsradius, og feil valg gjør en retting for én bruker til et avbrudd. Omfanget er beslutningen, og kommandoen følger av den.

Spør hvem som skal rammes før du spør hvilken kontroll som skal brukes.

Én instans: administrasjonsgrensesnittet

Et konfigurert administrasjonsgrensesnitt kan liste tilkoblede instanser og droppe nøyaktig én av dem. Hver økt bærer en klientidentifikator, og client-kill CID retter seg mot den identifikatoren i stedet for et felles navn. Les den levende identifikatoren fra gjeldende statusutskrift, fordi en verdi kopiert fra en eldre logg viser til en økt som ikke finnes lenger. Å droppe instansen avslutter den tilkoblingen og ingenting annet.

Det garanterer ikke en ny tilkobling. Om klienten kommer tilbake avhenger av gjenforsøksinnstillingene, de gjenværende eksterne oppføringene, autentiseringskravene og om overvåkingsapplikasjonen fortsatt kjører. En klient som kommer tilbake får en ny identifikator, og derfor er sammenligning av identifikatorer den eneste pålitelige måten å skille gammel fra ny.

En UDP-avgangsmelding er ikke en kommando per klient

explicit-exit-notify er en konfigurasjonsdirektiv om avgangs- og omstartshendelser. På en UDP-klient forteller den motparten at økten slutter, og det numeriske argumentet styrer hvor mange ganger meldingen gjentas. Når serveren kjører over UDP, sender den en omstartskontrollmelding til de tilkoblede klientene, og de dokumenterte verdiene skiller mellom å koble til samme server på nytt og å flytte til en annen ekstern oppføring. Det er et livssyklussignal med et bredt publikum.

Ingenting i den velger en vilkårlig klient på et vilkårlig tidspunkt. Å behandle den som en gjentilkoblingsknapp når alle tilkoblede økter samtidig.

Signaler virker på prosessen, ikke på en økt

SIGUSR1 ber en kjørende prosess starte tilkoblingen på nytt uten å lese konfigurasjonen på nytt, og innstillingene for varighet avgjør hva som overlever den omstarten. SIGHUP går lenger: den leser konfigurasjonsfilen på nytt og åpner ressursene sine på nytt. SIGTERM og SIGINT ber om en ryddig avslutning. Det er operasjoner på prosessnivå: på en server med mange klienter rammer de hver økt prosessen bærer, ikke den som er nevnt i billetten.

Når prosessen kjører under en tjenestebehandler, bruk behandlerens egen kontroll i stedet for å sende signal til en PID du fant i en prosessliste. Les enheten for å se hvilket signal behandleren sender, fordi en omstart og en omlasting gjør forskjellige ting med samme daemon.

Bestem omfanget før du velger kontrollen

Tre spørsmål avgjør det. Hvem skal rammes: én bruker, hver klient på én server, eller daemonen og alt den bærer. Hva skal overleve: konfigurasjonen, tunnelens tilstand eller ingen av dem. Hvem har tillatelse: administrasjonsintegrasjonen, tjenesteeieren eller nettverksoperatøren som styrer avgangsmeldingen. Svar på det, og bare én kontroll passer.

Å legge til en uautentisert administrasjonslytter for å få en gjentilkoblingsknapp gir langt mer enn den knappen til den som når porten.

Verifiser den nye økten, ikke frakoblingen

En frakoblingshendelse beviser at den gamle økten sluttet. Den sier ingenting om en ny økt som autentiseres, mottar en adresse, installerer ruter eller når ressursen brukeren trengte. Kontroller den nye identifikatoren, deretter tunnelens tilstand, deretter én reell ressurs. De tre trinnene er forskjellen mellom en gjentilkobling og en tilkobling som virker.

Skriv omfanget i endringsprotokollen. «Jeg koblet klienten til på nytt» er ikke en beskrivelse når klienten var én av førti på en delt server.