Cum să restaurezi un server VPN fără a duplica identități

Ați restaurat backupul, serviciul a pornit și un client s-a conectat din prima încercare. Acel succes este capcana. O restaurare aduce înapoi fișierele pe care le avea serverul în momentul instantaneului, nu starea de acces care s-a schimbat de atunci, iar dacă punctul final vechi este încă accesibil aveți acum două mașini care răspund la o singură identitate. Soluția nu este un backup mai bun; soluția este să decideți ce are voie să fie gazda restaurată înainte de a răspunde la un singur handshake.

Un backup aduce înapoi fișiere, nu autoritate

Instantaneul conține configurația serverului, cheile private, autoritatea de certificare, lista de parteneri și regulile de firewall așa cum erau când a rulat backupul. Nu poate conține ce s-a schimbat după: dispozitivul pe care l-ați revocat, cheia pe care ați reemis-o, partenerul pe care l-ați eliminat când s-a vândut un laptop, subrețeaua pe care ați mutat-o. Restaurarea derulează fișierele înapoi la acel moment. Nu derulează deciziile pe care oamenii le-au luat de atunci.

Prejudiciul vine exact din acest gol. Un laptop furat revocat la două săptămâni după backup prezintă un certificat care încă se validează împotriva CRL-ului mai vechi din arborele restaurat, iar serverul acceptă un dispozitiv pe care l-ați scos din uz. WireGuard este mai direct: un partener este autorizat prin faptul că apare în listă, așa că un partener șters după instantaneu este pur și simplu din nou prezent. Nimeni nu a reaprobat acel acces. Fișierul vechi a făcut-o.

Identitatea serverului și identitatea clientului eșuează în moduri diferite

La WireGuard identitatea serverului este cheia privată din wg0.conf, așa că copierea acelui fișier pe o a doua gazdă accesibilă creează două servere cu aceeași identitate și fără să știe unul de altul. Fiecare își ține propria listă de parteneri. Eliminați un partener pe gazda nouă și cea veche îl acceptă în continuare; verificați wg show pe una și vedeți jumătate din adevăr. Nici clienții nu comută singuri: un profil poartă un singur Endpoint, așa că un dispozitiv continuă să vorbească cu adresa cu care a fost configurat, care poate fi gazda pe care voiați să o scoateți din uz.

OpenVPN se duplică la același strat cu un certificat de server, cheia sa privată și cheia statică tls-auth sau tls-crypt. Copiați toate trei și un client nu poate distinge instanțele; dacă ambele sunt accesibile, o reconectare poate ateriza pe oricare, iar fiecare fișier de jurnal spune o poveste parțială. Autoritatea de certificare este copia mai profundă. Un arbore easy-rsa restaurat este o a doua sursă de adevăr care poate emite un certificat valid pentru orice nume îi dați.

Și clienții sunt duplicați, de obicei în timpul migrării înseși. Copierea unui profil pe un dispozitiv de rezervă „doar pentru test” produce un al doilea dispozitiv cu aceeași cheie și același nume comun. Cu duplicate-cn ambele sesiuni pot rămâne active simultan, iar o atribuire statică de adresă în ccd sau ifconfig-pool-persist poate intra în conflict cu dispozitivul original. Sunt două mașini cu o singură identitate, și nimic din configurația serverului nu le distinge.

Alegeți una dintre trei stări pentru punctul final vechi

O restaurare este sigură doar după ce soarta punctului final vechi este decisă. Scoateți-l din uz: serviciul vechi trebuie să nu mai accepte portul VPN înainte ca gazda nouă să pornească, iar dacă nu puteți ajunge la mașină, blocați acel port la marginea rețelei pentru tot, cu excepția sursei dumneavoastră administrative. Reparați aceeași gazdă: reutilizarea identității este în regulă pentru că o singură mașină o deține, dar apoi distrugeți copia pe disc sau instantaneul VM al cheii vechi ca să nu poată reveni. Construiți o pereche de disponibilitate: două gazde au nevoie de identități de gazdă distincte plus un punct final comun, cum ar fi o adresă flotantă, un balansator de încărcare sau un DNS pe care îl puteți muta. Copierea cheii private nu este un design de failover; sunt două servere care revendică un singur nume.

Confirmați în ce stare sunteți cu adevărat înainte de a atinge clienții. Gazda veche care răspunde pe portul VPN este cea care va accepta dispozitivul revocat, chiar dacă DNS-ul s-a mutat. Verificați ascultătorii și cheia publică:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Reconciliați mai întâi partenerii, revocările și adresele

Enumerați ce pretinde restaurarea față de ce este autorizat acum. La WireGuard, wg show wg0 dă cheia, punctul final, ultimul handshake și contoarele de transfer ale fiecărui partener, suficient pentru a observa un dispozitiv pe care nu îl mai dețineți. Eliminați-l live cu wg set wg0 peer <key> remove, apoi editați și configurația, altfel partenerul revine la următoarea pornire. wg show wg0 allowed-ips expune a doua problemă: doi parteneri pe o adresă, sau o adresă pe care ați realocat-o deja.

La OpenVPN lista de revocare este un fișier cu o dată, iar o restaurare poate aduce una veche. Verificați-o înainte ca clienții să se conecteze:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Dacă ultima actualizare precedă revocarea, serverul încă onorează un certificat pe care l-ați revocat. OpenVPN 2.4 și versiunile ulterioare recitesc fișierul CRL la fiecare conexiune nouă, așa că înlocuirea fișierului oprește sesiunile noi, dar tunelurile stabilite persistă până la renegociere; valoarea implicită a reneg-sec este 3600 de secunde, iar scăderea ei sau repornirea serviciului este ce vă dă schimbarea acum. Versiunile mai vechi pot să nu citească fișierul la fel de fiabil, așa că reporniți când nu puteți confirma comportamentul versiunii. Manualul wg(8) acoperă eliminarea partenerilor și sintaxa allowed-ips folosite mai sus.

Curățați și atribuielile statice pentru dispozitive care nu mai există. Reutilizarea adresei unui dispozitiv scos din uz pentru unul nou, în timp ce profilul vechi este încă instalat, creează exact duplicatul pe care încercați să îl evitați.

Verificați cu un client pe care l-ați revocat

Rulați verificările în ordine, dintr-o rețea din afara tunelului. Mai întâi un dispozitiv autorizat se conectează, rezolvă DNS prin resolverul împins și ajunge la o resursă privată. Apoi dispozitivul revocat trebuie să eșueze, folosind profilul existent și nu unul nou. Apoi încercați punctul final vechi din exterior: dacă portul VPN încă finalizează un handshake, gazda veche este vie și duplicarea este reală, nu teoretică.

Reporniți gazda restaurată și repetați verificările de autorizat și revocat, pentru că atunci fișierul de configurare învinge ce ați schimbat în timpul rulării. Comparați cheia publică sau amprenta certificatului gazdei cu cea folosită de mașina scoasă din uz. Amprente identice pe două mașini vii înseamnă că restaurarea a clonat identitatea; amprente identice pe o singură mașină sunt normale. Notați versiunile restaurate, amprentele cheilor și numărul de serie sau cheia partenerului revocat, apoi faceți următorul backup după această reconciliere, ca să reprezinte serviciul așa cum este acum. Testul care funcționează nu este că un client se conectează. Ci că clientul pe care l-ați eliminat rămâne afară în timp ce punctul final vechi rămâne închis.