Genopkobling af en OpenVPN-klient: tre kontroller, tre omfang

Nogen beder om, at VPN-klienten bliver genopkoblet, og anmodningen kan betyde tre forskellige ting. Det kan betyde at droppe én godkendt session, at fortælle hver klient, at en UDP-server forsvinder, eller at genstarte dæmonen selv. Hver har en forskellig slagradius, og det forkerte valg gør en rettelse for én bruger til et nedbrud. Omfanget er beslutningen, og kommandoen følger af den.

Spørg, hvem der skal rammes, før du spørger, hvilken kontrol der skal bruges.

Én instans: administrationsgrænsefladen

En konfigureret administrationsgrænseflade kan liste forbundne instanser og droppe præcis én af dem. Hver session bærer en klientidentifikator, og client-kill CID rammer den identifikator frem for et fælles navn. Læs den levende identifikator fra den aktuelle statusudskrift, fordi en værdi kopieret fra en ældre log henviser til en session, der ikke findes længere. At droppe instansen afslutter den forbindelse og intet andet.

Det garanterer ikke en ny forbindelse. Om klienten kommer tilbage afhænger af dens genforsøgsindstillinger, dens resterende fjernposter, dens godkendelseskrav og af, om det overvågende program stadig kører. En klient, der vender tilbage, får en ny identifikator, og derfor er sammenligning af identifikatorer den eneste pålidelige måde at skelne gammel fra ny.

En UDP-afgangsmeddelelse er ikke en kommando for hver klient

explicit-exit-notify er en konfigurationsdirektiv om afgangs- og genstartsbegivenheder. På en UDP-klient fortæller den modparten, at sessionen slutter, og det numeriske argument styrer, hvor mange gange meddelelsen gentages. Når serveren kører over UDP, sender den en genstartskontrolmeddelelse til sine forbundne klienter, og de dokumenterede værdier skelner mellem at genopkoble til samme server og at flytte til en anden fjernpost. Det er et livscyklussignal med et bredt publikum.

Intet i den vælger en vilkårlig klient på et vilkårligt tidspunkt. At behandle den som en genopkoblingsknap rammer alle forbundne sessioner på én gang.

Signaler virker på processen, ikke på en session

SIGUSR1 beder en kørende proces om at genstarte sin forbindelse uden at genlæse konfigurationen, og persistensindstillingerne afgør, hvad der overlever den genstart. SIGHUP går videre: den genlæser konfigurationsfilen og genåbner sine ressourcer. SIGTERM og SIGINT anmoder om en ordentlig nedlukning. Det er handlinger på procesniveau: på en server med mange klienter rammer de hver session, processen bærer, ikke den, der er nævnt i billetten.

Når processen kører under en tjenestestyring, brug styringens egen kontrol i stedet for at sende signal til et PID, du fandt i en procesliste. Læs unit-filen for at se, hvilket signal styringen sender, fordi en genstart og en genindlæsning gør forskellige ting ved den samme dæmon.

Afgør omfanget, før du vælger kontrollen

Tre spørgsmål afgør det. Hvem skal rammes: én bruger, hver klient på én server, eller dæmonen og alt, hvad den bærer. Hvad skal overleve: konfigurationen, tunnelens tilstand eller ingen af dem. Hvem har tilladelse til det: administrationsintegrationen, tjenesteejeren eller netværksoperatøren, der styrer afgangsmeddelelsen. Svar på det, og kun én kontrol passer.

At tilføje en uautentificeret administrationslytter for at få en genopkoblingsknap giver langt mere end den knap til enhver, der kan nå porten.

Verificér den nye session, ikke afbrydelsen

En afbrydelsesbegivenhed beviser, at den gamle session sluttede. Den siger intet om en ny, der godkendes, modtager en adresse, installerer ruter eller når den ressource, brugeren havde brug for. Kontrollér den nye identifikator, derefter tunnelens tilstand, derefter én rigtig ressource. De tre trin er forskellen mellem en genopkobling og en fungerende forbindelse.

Skriv omfanget i ændringsregistret. »Jeg genopkoblede klienten« er ikke en beskrivelse, når klienten var en af fyrre på en delt server.