Återansluta en OpenVPN-klient: tre styrningar, tre omfång

Någon ber att VPN-klienten ska återanslutas, och begäran kan betyda tre olika saker. Det kan betyda att släppa en autentiserad session, att meddela varje klient att en UDP-server försvinner, eller att starta om daemonen själv. Var och en har en annan påverkansradie, och fel val gör en rättelse för en användare till ett avbrott. Omfånget är beslutet, och kommandot följer av det.

Fråga vem som ska påverkas innan du frågar vilken styrning som ska användas.

En instans: administrationsgränssnittet

Ett konfigurerat administrationsgränssnitt kan lista anslutna instanser och släppa exakt en av dem. Varje session bär en klientidentifierare, och client-kill CID riktar sig mot den identifieraren i stället för ett gemensamt namn. Läs den levande identifieraren från aktuell statusutskrift, eftersom ett värde som kopierats från en äldre logg avser en session som inte finns längre. Att släppa instansen avslutar den anslutningen och inget annat.

Det garanterar inte en ny anslutning. Om klienten kommer tillbaka beror på dess återförsöksinställningar, återstående fjärrposter, autentiseringskrav och om det övervakande programmet fortfarande körs. En klient som kommer tillbaka får en ny identifierare, och därför är jämförelse av identifierare det enda tillförlitliga sättet att skilja gammalt från nytt.

Ett UDP-utgångsmeddelande är inte ett kommando per klient

explicit-exit-notify är en konfigurationsdirektiv om utgångs- och omstarts händelser. På en UDP-klient talar den om för motparten att sessionen slutar, och det numeriska argumentet styr hur många gånger meddelandet upprepas. När servern körs över UDP skickar den ett omstartskontrollmeddelande till sina anslutna klienter, och de dokumenterade värdena skiljer mellan att återansluta till samma server och att flytta till en annan fjärrpost. Det är en livscykelsignal med en bred publik.

Inget i den väljer en godtycklig klient vid en godtycklig tidpunkt. Att behandla den som en återanslutningsknapp når alla anslutna sessioner på en gång.

Signaler verkar på processen, inte på en session

SIGUSR1 ber en körande process starta om sin anslutning utan att läsa konfigurationen igen, och inställningarna för varaktighet avgör vad som överlever den omstarten. SIGHUP går längre: den läser konfigurationsfilen igen och öppnar sina resurser igen. SIGTERM och SIGINT begär en ordnad avstängning. Det är åtgärder på processnivå: på en server med många klienter påverkar de varje session som processen bär, inte den som nämns i ärendet.

När processen körs under en tjänstehanterare, använd hanterarens egen styrning i stället för att skicka en signal till en PID du hittade i en processlista. Läs enheten för att se vilken signal hanteraren skickar, eftersom en omstart och en omladdning gör olika saker med samma daemon.

Bestäm omfånget innan du väljer styrning

Tre frågor avgör det. Vem ska påverkas: en användare, varje klient på en server, eller daemonen och allt den bär. Vad ska överleva: konfigurationen, tunnelns tillstånd eller inget av dem. Vem har behörighet: administrationsintegrationen, tjänsteägaren eller nätverksoperatören som styr utgångsmeddelandet. Svara på det, och bara en styrning passar.

Att lägga till en oautentiserad administrationslyssnare för att få en återanslutningsknapp ger långt mer än den knappen till den som når porten.

Verifiera den nya sessionen, inte frånkopplingen

En frånkopplingshändelse bevisar att den gamla sessionen avslutades. Den säger inget om en ny som autentiserar sig, tar emot en adress, installerar rutter eller når resursen användaren behövde. Kontrollera den nya identifieraren, sedan tunnelns tillstånd, sedan en verklig resurs. De tre stegen är skillnaden mellan en återanslutning och en anslutning som fungerar.

Skriv omfånget i ändringsloggen. ”Jag återanslöt klienten” är ingen beskrivning när klienten var en av fyrtio på en delad server.