VPN serverio perkėlimas į naują viešą IP: ką patikrinti pirmiausia
Keitimas vietoje ir lygiagretus perjungimas lūžta skirtingose vietose. Peržiūrėkite konfigūracijas, NAT ir sertifikatus, tada patikrinkite, kaip kiekvienas klientas išsprendžia vardą.
Adreso perskyrimas užima minutę. Kita savaitė yra vieta, kurioje perkėlimas lūžta, ir retai ten, kur nurodo tiekėjo konsolė. Naujas viešas IP minimas keturiose vietose: lizdas, kuriame klausosi demonas, pasitikėjimo inkaras, kurį tikrina klientai, kiekviena taisyklė, įvardijanti seną adresą, ir DNS įrašas, kuris juos sieja. Du perkėlimai valdymo skydelyje atrodo vienodai, bet elgiasi visiškai skirtingai: adreso perskyrimas mašinoje, kurią valdote, arba antro endpoint pastatymas ir klientų perkėlimas į jį. Toliau pateikti patikrinimai pigias klaidas kelia į priekį, o kiekvienas skyrius nurodo, kuriam perkėlimui jis taikomas.
Keitimas vietoje ir lygiagretus perjungimas yra skirtingi darbai
Keitimas vietoje išlaiko hostą, raktus, maršrutizavimo lentelę ir vartotojų sąrašą; keičiasi tik adresas. Tai daro plūduriuojančio IP perskyrimas, ir kelių tiekėjų atveju svečias to net nepastebi, nes vertimas vyksta prieš instanciją. Perkūrimas arba tiekėjo perskyrimas yra grubesnis: svečias mato pokytį, ir viskas, kas turėjo seną reikšmę podėlyje, sužino apie jį tą pačią akimirką.
Lygiagretus endpoint yra antras hostas, atliekantis tą patį darbą. Pastatykite jį, išbandykite su vienu profiliu ir palikite senąjį atsakinėti, kol naujasis įrodys save realiame kelyje. Kaina yra būsena. Be bendrų peer įrašų, atšaukimų ir registravimo turite du tinklus, kurie atsitiktinai dalijasi vardu.
| 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 |
Raskite kiekvieną vietą, kur užrašytas senas adresas
Pradėkite nuo teksto paieškos, nes konfigūracijos failai yra lengvoji pusė. Ieškokite demono konfigūracijoje, ugniasienės fragmentuose, stebėjimo tiksluose ir bet kuriame diske sugeneruotame kliento pakete. Įtraukite IPv6 adresą, jei tokį skelbiate; perkėlimas, kuris seka tik A įrašą, palieka dvigubo kamino klientus sename kelyje.
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 endpoints
Tada peržiūrėkite branduolį, nes veikianti sistema laiko adresą vietose, kurių nemini joks failas. Statinė šaltinio NAT taisyklė, ipset įrašas, bind adresas ir conntrack įrašas išgyvena konfigūracijos pakeitimą, kuris juos pašalino, o kai kurie išgyvena ir perkrovimą, nes grįžo iš išsaugoto taisyklių rinkinio. Vienu sluoksniu aukščiau tiekėjo saugos grupės, apkrovos balansuotojo tikslai ir stebėjimo patikrinimai visai nėra jūsų failų sistemoje.
Užsirašykite inventorių prieš ką nors keisdami; jis taip pat tarnauja kaip atsukimo scenarijus.
Klientai pagal pagrindinio kompiuterio vardą atsigauna; klientai su tiesioginiu IP nutyla
Jei klientai pasiekia serverį pagal pagrindinio kompiuterio vardą, perjungimas daugiausia yra DNS problema, o vakar nustatytas TTL sprendžia, kaip blogai bus. Resolveriai kaupia podėlyje, stub resolveriai kaupia dar kartą, ir daug klientų vardą ieško tik naujame ryšyje, todėl užmegztas tunelis išlaiko pradinį adresą.
Jei endpoint yra tiesioginis adresas, niekas neišsprendžiama iš naujo ir niekas neįrašo skundo. WireGuard saugo išspręstą lizdo adresą: Endpoint = vpn.example.net:51820 tampa IP tuo momentu, kai paleidžiamas wg-quick up, ir išlieka tuo IP, kol jo nepakeisite. OpenVPN yra atlaidesnis: jis išsprendžia remote pagrindinio kompiuterio vardą prisijungimo metu ir su resolv-retry infinite vėl bando DNS prisijungus iš naujo. Su tiesioginiu IP abu toliau skambina mašinai, kurios jau nėra.
Žmones klaidina veidrodinis vaizdas. Klientas, jau nukreiptas į naują adresą, kol senasis klausytojas dar atsako, praeina kiekvieną testą, kurį atliekate nuo savo stalo. Mane irgi taip apgavo: naujasis endpoint pakilo telefone iš pirmo karto, o klientas su pasenusiu profiliu išryškėjo tik tada, kai senasis klausytojas buvo išjungtas daug vėliau.
Pasitikėjimas nepersikelia su adresu
WireGuard atskiria tapatybę nuo pasiekiamumo, todėl adreso perkėlimas beveik nemokamas. Peerai identifikuojami viešuoju raktu, o endpoint yra tik vieta, kur paketai dabar keliauja; hostas atnaujina peer endpoint pagal paskutinio autentifikuoto paketo šaltinio adresą. Neaktyvus peer vis tiek turi priežastį kalbėtis su nauja vieta, ir adresą sužino tik tada, kai jo sesija pasensta, o handshake pakartojimai nepavyksta matomoje vietoje. WireGuard trumpasis vadovas apima endpoint lauką.
TLS pagrįsti serveriai yra priešingas atvejis. Sertifikatas susietas su vardu, o klientas, renkantis adresą, lygina pasirinktą su subjekto alternatyviais vardais. Prisijunkite per IP prie sertifikato, kuriame yra tik DNS SAN, ir patikra nepavyksta: kliento naudotas vardas sertifikate neegzistuoja. Perleidimas su IP SAN sutvarko tą vieną ryšį ir pablogina kitą perkėlimą. Pagrindinio kompiuterio vardo laikymas profilyje ir verify-x509-name palikimas vietoje palaiko griežtą patikrą, kol adresas po juo keičiasi.
Tada patikrinkite, prie ko prijungtas demonas; prie seno adreso prisegtas lizdas tyliai nepavyksta. OpenVPN serveris, paleistas su local 203.0.113.10, atsisako kilti, kai tas adresas dingsta, o klausytojas ant 0.0.0.0 pokytį seka nemokamai. NAT skyla taip pat: MASQUERADE seka bet kurį adresą, kurį mašina dabar turi, o statinis SNAT --to-source 203.0.113.10 toliau perrašo į adresą, kurio nebeturite, todėl grįžtamasis srautas dingsta. Jei naujas adresas ateina su kitu upstream šliuzu, patikrinkite rp_filter: atvirkštinio kelio filtravimas numeta grįžtamąjį srautą, atvykstantį į sąsają, kurios branduolys nesitikėjo.
Perjungimo tvarka ir įrodymai, kad jis veikė
Sumažinkite TTL diena anksčiau, pastatykite naują klausytoją ir įrodykite jį profiliu, kurį turite tik jūs. Testas to paties tinklo viduje beveik nieko neįrodo, todėl naudokite telefoną mobiliojo ryšio tinkle ir išbandykite tai, ką tunelis turi pernešti, o ne ping į endpoint.
Stebėkite abu adresus per visą langą. wg show all latest-handshakes naujame hoste arba OpenVPN būsenos failas pasako, kiek peerų iš tiesų persikėlė. Kai naujasis endpoint turi lauktus peerus, o senajame likę tik atsilikėliai, išveskite senąjį klausytoją iš eksploatacijos, pašalinkite pasenusią NAT taisyklę ir išimkite adresą iš tiekėjo ugniasienės. Senojo klausytojo pašalinimas yra žingsnis, kuris praleidžiamas, ir jis uždaro spragą, kurioje pasenęs profilis dar pasiekia seną tinklą.
Prieš pradėdami raštu nustatykite atsukimo trigerį: jei po sutarto lango naujasis endpoint negauna handshake iš nė vieno realaus kliento, atkurkite seną adresą ir nustokite platinti profilius. Tada pakartokite paiešką ir patvirtinkite, kad nė vienas klausytojas nebėra susietas su išvestu adresu. Du dalykai pereina į kitą perkėlimą: pagrindinio kompiuterio vardas kliento profilyje, kad kitas pakeitimas būtų DNS redagavimas, ir inventorius, saugomas šalia serverio atkūrimo užrašų.