OpenVPN-asiakkaan uudelleenyhdistäminen: kolme ohjausta, kolme laajuutta

Joku pyytää, että VPN-asiakas yhdistetään uudelleen, ja pyyntö voi tarkoittaa kolmea eri asiaa. Se voi tarkoittaa yhden todennetun istunnon pudottamista, jokaisen asiakkaan tiedottamista siitä, että UDP-palvelin poistuu, tai itse taustaprosessin uudelleenkäynnistystä. Jokaisella on erilainen vaikutussäde, ja väärä valinta muuttaa yhden käyttäjän korjauksen koko palvelun katkoksi. Laajuus on päätös, ja komento seuraa siitä.

Kysy, kehen sen pitäisi vaikuttaa, ennen kuin kysyt, mitä ohjausta käytetään.

Yksi instanssi: hallintaliittymä

Määritetty hallintaliittymä voi listata yhdistetyt instanssit ja pudottaa niistä täsmälleen yhden. Jokainen istunto kantaa asiakastunnistetta, ja client-kill CID kohdistuu tähän tunnisteeseen yleisnimen sijaan. Lue elävä tunniste nykyisestä tilatulosteesta, koska vanhemmasta lokista kopioitu arvo viittaa istuntoon, jota ei enää ole. Instanssin pudottaminen päättää kyseisen yhteyden eikä mitään muuta.

Se ei takaa uutta yhteyttä. Asiakkaan paluu riippuu sen uudelleenyritysasetuksista, jäljellä olevista etämerkinnöistä, todennusvaatimuksista ja siitä, onko valvova sovellus yhä käynnissä. Palaava asiakas saa uuden tunnisteen, ja siksi tunnisteiden vertailu on ainoa luotettava tapa erottaa vanha uudesta.

UDP-poistumisilmoitus ei ole asiakaskohtainen komento

explicit-exit-notify on konfigurointidirektiivi poistumis- ja uudelleenkäynnistystapahtumista. UDP-asiakkaassa se kertoo vastapuolelle, että istunto päättyy, ja numeerinen argumentti ohjaa, kuinka monta kertaa ilmoitus toistetaan. Kun palvelin toimii UDP:n yli, se lähettää uudelleenkäynnistyksen ohjausviestin yhdistetyille asiakkailleen, ja dokumentoidut arvot erottavat samaan palvelimeen uudelleenyhdistämisen siirtymisestä toiseen etämerkintään. Se on elinkaarisignaali laajalle yleisölle.

Mikään siinä ei valitse mielivaltaista asiakasta mielivaltaisella hetkellä. Sen pitäminen uudelleenyhdistämispainikkeena tavoittaa kaikki yhdistetyt istunnot kerralla.

Signaalit vaikuttavat prosessiin, eivät istuntoon

SIGUSR1 pyytää käynnissä olevaa prosessia käynnistämään yhteytensä uudelleen lukematta konfiguraatiota uudelleen, ja pysyvyysasetukset ratkaisevat, mikä selviää tästä uudelleenkäynnistyksestä. SIGHUP menee pidemmälle: se lukee konfiguraatiotiedoston uudelleen ja avaa resurssinsa uudelleen. SIGTERM ja SIGINT pyytävät hallittua sammutusta. Ne ovat prosessitason toimenpiteitä: monen asiakkaan palvelimella ne vaikuttavat jokaiseen istuntoon, jota prosessi kantaa, eivät vain tikettiin nimettyyn.

Kun prosessi toimii palvelunhallinnan alla, käytä hallinnan omaa ohjausta sen sijaan, että lähettäisit signaalin prosessilistasta löytämääsi PID:iin. Lue unit-tiedosto nähdäksesi, minkä signaalin hallinta lähettää, koska uudelleenkäynnistys ja uudelleenlataus tekevät samalle taustaprosessille eri asioita.

Päätä laajuus ennen ohjauksen valintaa

Kolme kysymystä ratkaisee sen. Kehen sen pitäisi vaikuttaa: yhteen käyttäjään, yhden palvelimen kaikkiin asiakkaisiin vai taustaprosessiin ja kaikkeen, mitä se kantaa. Mikä pitäisi säilyä: konfiguraatio, tunnelin tila vai ei kumpikaan. Kuka on siihen valtuutettu: hallintaintegraatio, palvelun omistaja vai verkkoylläpitäjä, joka hallitsee poistumisilmoitusta. Vastaa näihin, ja vain yksi ohjaus sopii.

Todentamattoman hallintakuuntelijan lisääminen uudelleenyhdistämispainikkeen saamiseksi antaa kenelle tahansa porttiin pääsevälle paljon enemmän kuin tuon painikkeen.

Tarkista uusi istunto, älä katkaisua

Katkaisutapahtuma todistaa, että vanha istunto päättyi. Se ei kerro mitään uudesta istunnosta, joka todennetaan, saa osoitteen, asentaa reitit tai saavuttaa resurssin, jota käyttäjä tarvitsi. Tarkista uusi tunniste, sitten tunnelin tila, sitten yksi todellinen resurssi. Ne kolme vaihetta ovat ero uudelleenyhdistämisen ja toimivan yhteyden välillä.

Kirjaa laajuus muutosmerkintään. ”Yhdistin asiakkaan uudelleen” ei ole kuvaus, kun asiakas oli yksi neljästäkymmenestä jaetulla palvelimella.