VPN-serveri kolimine uuele avalikule IP-le: mida esimesena kontrollida
Kohapealne vahetus ja paralleelne üleminek purunevad eri kohtades. Käige läbi konfiguratsioonid, NAT ja sertifikaadid, seejärel kontrollige, kuidas iga klient nime lahendab.
Aadressi ümberhindamine võtab minuti. Järgnev nädal on koht, kus kolimine katki läheb, ja harva seal, kuhu pakkuja konsool vihjab. Uut avalikku IP-d viidatakse neljas kohas: socket, millel deemon kuulab, usaldusankur, mida kliendid kontrollivad, iga reegel, mis nimetab vana aadressi, ja DNS-kirje, mis need kokku seob. Kaks kolimist näevad juhtpaneelilt identsed välja, kuid käituvad täiesti erinevalt: aadressi ümberhindamine masinas, mida te juhite, või teise endpointi püstitamine ja klientide sinna viimine. Allpool olevad kontrollid panevad odavad tõrked ette ja iga osa nimetab, millise kolimise kohta see kehtib.
Kohapealne vahetus ja paralleelne üleminek on erinevad tööd
Kohapealne vahetus säilitab hosti, võtmed, marsruutimistabeli ja kasutajate nimekirja; muutub ainult aadress. Seda teeb ujuva IP ümberhindamine, ja mitmel pakkujal ei märka külaline seda üldse, sest tõlge toimub instantsi ees. Ümberehitus või pakkuja poolt ümberhindamine on karmim: külaline näeb muudatust ja kõik, mis oli vana väärtuse vahemällu salvestanud, saab sellest teada samal hetkel.
Paralleelne endpoint on teine host, mis teeb sama tööd. Ehitage see, testige ühe profiiliga ja laske vanal vastata, kuni uus tõestab end päris teel. Hinnaks on olek. Ilma jagatud peer-kirjeteta, tühistamiste ja logimiseta on teil kaks võrku, mis juhtumisi jagavad nime.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
Leidke iga koht, kuhu vana aadress on kirja pandud
Alustage tekstipäringust, sest konfiguratsioonifailid on lihtne pool. Otsige deemoni konfiguratsioonist, tulemüüri fragmentidest, monitooringu sihtmärkidest ja kõigist kettal olevatest genereeritud kliendipakettidest. Kaasake IPv6-aadress, kui te seda avaldate; kolimine, mis järgib ainult A-kirjet, jätab kahe virna kliendid vanale teele.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsSeejärel käige läbi kernel, sest töötav süsteem hoiab aadressi kohtades, mida ükski fail ei maini. Staatiline lähteaadressi NAT-reegel, ipset-kirje, bind-aadress ja conntrack-kirje elavad üle konfiguratsioonimuudatuse, mis need eemaldas, ja mõned elavad üle taaskäivituse, sest tulid tagasi salvestatud reeglistikust. Üks kiht kõrgemal ei ole pakkuja turvagrupid, koormusjaoturi sihtmärgid ja monitooringukontrollid teie failisüsteemis üldse olemas.
Kirjutage inventuur üles enne, kui midagi muudate; see toimib ka tagasipööramisskriptina.
Hostinime-kliendid taastuvad; literal-IP-kliendid vaikivad
Kui kliendid jõuavad serverini hostinime kaudu, on üleminek peamiselt DNS-probleem ja eile seatud TTL otsustab, kui hulluks see läheb. Resolverid vahemällu salvestavad, stub-resolverid salvestavad veel kord ja paljud kliendid otsivad nime ainult uuel ühendusel, nii et loodud tunnel hoiab oma algset aadressi.
Kui endpoint on literaalne aadress, ei lahendata midagi uuesti ja miski ei logi kaebust. WireGuard salvestab lahendatud socketi aadressi: Endpoint = vpn.example.net:51820 muutub IP-ks hetkel, mil wg-quick up töötab, ja jääb selleks IP-ks, kuni te seda muudate. OpenVPN on leebem: see lahendab hostinime remote ühendamise hetkel ja proovib koos resolv-retry infinite uuesti DNS-i taasühendamisel. Literaalse IP korral valivad mõlemad edasi masinat, mida enam ei ole.
Inimesi eksitab peegelpilt. Klient, mis on juba uuele aadressile suunatud, samal ajal kui vana kuulaja veel vastab, läbib iga testi, mille te oma töölaualt teete. Mind on sellega ninapidi veetud: uus endpoint tuli telefonis esimese katsega üles ja vana profiiliga klient ilmnes alles siis, kui vana kuulaja palju hiljem välja lülitati.
Usaldus ei liigu aadressiga kaasa
WireGuard eraldab identiteedi kättesaadavusest, mis teeb aadressi kolimise peaaegu tasuta. Peere tuvastatakse avaliku võtmega ja endpoint on ainult see, kuhu paketid praegu lähevad; host uuendab peeri endpointi viimase autenditud paketi lähteaadressist. Tühikäigul olev peer vajab siiski põhjust uue kohaga rääkimiseks ja õpib aadressi alles siis, kui selle sessioon vananeb ja handshake'i korduskatsed mõnes nähtavas kohas ebaõnnestuvad. WireGuardi kiirjuhend katab endpointi välja.
TLS-il põhinevad serverid on vastupidine juhtum. Sertifikaat on seotud nimega ja aadressi valiv klient võrdleb valitut subject alternative name'idega. Ühenduge IP-ga sertifikaadi külge, mis kannab ainult DNS SAN-i, ja kontroll ebaõnnestub: kliendi kasutatud nimi ei ole sertifikaadis. IP SAN-iga uuesti väljastamine parandab selle ühe ühenduse ja teeb järgmise kolimise hullemaks. Hostinime profiilis hoidmine ja verify-x509-name paigale jätmine hoiab kontrolli rangena, samal ajal kui aadress selle all muutub.
Seejärel kontrollige, millega deemon on seotud; vana aadressi külge kinnitatud socket ebaõnnestub vaikselt. local 203.0.113.10-ga käivitatud OpenVPN-server keeldub üles tulemast, kui see aadress kaob, samas kui 0.0.0.0 peal olev kuulaja järgib muudatust tasuta. NAT jaguneb samamoodi: MASQUERADE järgib seda, milline aadress masinal nüüd on, ja staatiline SNAT --to-source 203.0.113.10 kirjutab edasi aadressile, mida te enam ei oma, nii et tagasitulev liiklus kaob. Kui uus aadress tuleb teise upstream-lüüsiga, kontrollige rp_filter: vastassuunalise tee filtreerimine viskab ära tagasituleva liikluse, mis saabub liidesele, mida kernel ei oodanud.
Ülemineku järjekord ja tõendid, et see töötas
Langetage TTL-i päev varem, püstitage uus kuulaja ja tõestage seda profiiliga, mis on ainult teil. Test samast võrgust ei tõesta peaaegu midagi, seega kasutage mobiilivõrgus telefon ja testige midagi, mida tunnel peaks kandma, mitte pingi endpointi.
Jälgige akna jooksul mõlemat aadressi. wg show all latest-handshakes uuel hostil või OpenVPN-i olekufail ütleb, kui mitu peeri on tegelikult liikunud. Kui uuel endpointil on oodatud peerid ja vanal ainult mahajääjad, võtke vana kuulaja kasutusest välja, eemaldage vananenud NAT-reegel ja eemaldage aadress pakkuja tulemüürist. Vana kuulaja eemaldamine on samm, mis vahele jääb, ja see sulgeb lünga, kus vananenud profiil jõuab veel vanasse võrku.
Pange tagasipööramise päästik enne alustamist kirja: kui uuel endpointil ei ole kokkulepitud akna järel handshake'i ühestki päris kliendist, taastage vana aadress ja lõpetage profiilide jagamine. Käivitage pärast seda otsing uuesti ja kinnitage, et ükski kuulaja ei ole enam kasutusest võetud aadressi küljes. Kaks asja lähevad järgmisse kolimisse kaasa: hostinimi kliendiprofiilis, et järgmine muudatus oleks DNS-i redaktsioon, ja serveri taastamisümärkuste kõrval hoitav inventuur.