VPN-palvelimen siirtäminen uuteen julkiseen IP-osoitteeseen: mitä tarkistaa ensin

Osoitteen uudelleen osoittaminen kestää minuutin. Seuraava viikko on se kohta, jossa siirto rikkoutuu, ja harvoin siinä, mihin palveluntarjoajan konsoli viittaa. Uuteen julkiseen IP-osoitteeseen viitataan neljässä paikassa: socket, jota daemon kuuntelee, luottamuksen ankkuri, jonka asiakkaat varmistavat, jokainen sääntö, joka nimeää vanhan osoitteen, ja DNS-tietue, joka sitoo ne yhteen. Kaksi siirtoa näyttävät hallintapaneelista samoilta mutta käyttäytyvät täysin eri tavoin: osoitteen uudelleen osoittaminen koneessa, jota itse ajat, tai toisen endpointin pystyttäminen ja asiakkaiden siirtäminen siihen. Alla olevat tarkistukset asettavat halvat viat ensin, ja jokainen osio kertoo, mihin siirtoon se pätee.

Paikan päällä tehtävä vaihto ja rinnakkainen siirtymä ovat eri töitä

Paikan päällä tehtävä vaihto säilyttää isäntäkoneen, avaimet, reititystaulun ja käyttäjäluettelon; vain osoite muuttuu. Sen tekee kelluvan IP-osoitteen uudelleen osoittaminen, ja usealla palveluntarjoajalla vieras ei huomaa mitään, koska käännös tapahtuu instanssin edessä. Uudelleenrakennus tai palveluntarjoajan uudelleen osoittaminen on kovempi: vieras näkee muutoksen, ja kaikki vanhan arvon välimuistiin tallentanut oppii sen samalla hetkellä.

Rinnakkainen endpoint on toinen isäntä, joka tekee saman työn. Rakenna se, testaa sitä yhdellä profiililla ja jätä vanha vastaamaan, kunnes uusi todistaa itsensä todellisella polulla. Hinta on tila. Ilman jaettuja peer-tietueita, peruutuksia ja lokitusta sinulla on kaksi verkkoa, jotka sattumalta jakavat nimen.

Etsi jokainen paikka, johon vanha osoite on kirjoitettu

Aloita tekstihaul, koska asetustiedostot ovat helppo puolisko. Hae daemonin asetuksista, palomuurin katkelmista, valvonnan kohteista ja kaikista levylle generoiduista asiakaspaketeista. Sisällytä IPv6-osoite, jos julkaiset sellaisen; siirto, joka seuraa vain A-tietuetta, jättää kaksoispinon asiakkaat vanhalle polulle.

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

Käy sitten läpi ydin, koska käynnissä oleva järjestelmä pitää osoitetta paikoissa, joita mikään tiedosto ei mainitse. Staattinen lähde-NAT-sääntö, ipset-merkintä, bind-osoite ja conntrack-merkintä elävät pidempään kuin asetusmuutos, joka ne poisti, ja jotkut elävät uudelleenkäynnistyksen yli, koska ne palasivat tallennetusta sääntöjoukosta. Yhden kerroksen ylempänä palveluntarjoajan tietoturvaryhmät, kuormantasaimen kohteet ja valvontatarkistukset eivät ole tiedostojärjestelmässäsi lainkaan.

Kirjoita luettelo muistiin ennen kuin muutat mitään; se toimii myös palautusskriptinä.

Isäntänimen asiakkaat toipuvat; kirjaimellisen IP:n asiakkaat vaikenevat

Jos asiakkaat saavuttavat palvelimen isäntänimen kautta, siirtymä on enimmäkseen DNS-ongelma, ja eilen asetettu TTL ratkaisee, kuinka pahaksi se menee. Ratkaisijat välimuistittavat, stub-ratkaisijat välimuistittavat uudelleen, ja monet asiakkaat etsivät nimen vain uudella yhteydellä, joten muodostettu tunneli pitää alkuosoitteensa.

Jos endpoint on kirjaimellinen osoite, mikään ei ratkea uudelleen eikä mikään kirjaa valitusta. WireGuard tallentaa ratkaistun socket-osoitteen: Endpoint = vpn.example.net:51820 muuttuu IP:ksi heti, kun wg-quick up ajetaan, ja pysyy tämänä IP:nä, kunnes muutat sitä. OpenVPN on lempeämpi: se ratkaisee remote-isäntänimen yhteyden hetkellä ja yrittää resolv-retry infinite-asetuksella DNS:ää uudelleen yhdistäessä. Kirjaimellisella IP:llä molemmat soittavat edelleen koneeseen, jota ei enää ole.

Ihmisiä hämää peilikuva. Asiakas, joka osoittaa jo uuteen osoitteeseen, kun vanha kuuntelija vielä vastaa, läpäisee jokaisen testin, jonka teet omalta työpöydältäsi. Minua on huijattu sillä: uusi endpoint nousi puhelimessa ensimmäisellä yrityksellä, ja vanhan profiilin asiakas paljastui vasta, kun vanha kuuntelija sammutettiin paljon myöhemmin.

Luottamus ei siirry osoitteen mukana

WireGuard erottaa identiteetin tavoitettavuudesta, mikä tekee osoitteen siirtämisestä lähes ilmaista. Peerit tunnistetaan julkisella avaimella, ja endpoint on vain paikka, johon paketit tällä hetkellä menevät; isäntä päivittää peerin endpointin viimeisimmän todennetun paketin lähdeosoitteesta. Käyttämätön peer tarvitsee silti syyn puhua uudelle paikalle, ja se oppii osoitteen vasta, kun sen istunto vanhenee ja handshake-yritykset epäonnistuvat näkyvässä paikassa. WireGuardin pikaopas kattaa endpoint-kentän.

TLS-pohjaiset palvelimet ovat päinvastainen tapaus. Varmenne on sidottu nimeen, ja osoitteen valitseva asiakas vertaa valitsemaansa kohteen vaihtoehtoisiin nimiin. Yhdistä IP:llä varmenteeseen, jossa on vain DNS SAN, ja varmennus epäonnistuu: asiakkaan käyttämä nimi ei ole varmenteessa. Uudelleenmyöntäminen IP SAN:lla korjaa tuon yhden yhteyden ja pahentaa seuraavaa siirtoa. Isäntänimen pitäminen profiilissa ja verify-x509-name-asetuksen jättäminen paikalleen pitää tarkistuksen tiukkana, vaikka osoite sen alla muuttuu.

Tarkista sitten, mihin daemon on sidottu; vanhaan osoitteeseen kiinnitetty socket epäonnistuu hiljaa. local 203.0.113.10-asetuksella käynnistetty OpenVPN-palvelin kieltäytyy nousemasta, kun osoite häviää, kun taas 0.0.0.0-osoitteessa oleva kuuntelija seuraa muutosta ilmaiseksi. NAT jakautuu samoin: MASQUERADE seuraa, mikä osoite koneella nyt on, ja staattinen SNAT --to-source 203.0.113.10 kirjoittaa edelleen osoitteeseen, jota et enää omista, joten paluuliikenne katoaa. Jos uusi osoite tulee eri upstream-yhdyskäytävän kanssa, tarkista rp_filter: käänteisen polun suodatus pudottaa paluuliikenteen, joka saapuu rajapinnalle, jota ydin ei odottanut.

Siirtymän järjestys ja todisteet siitä, että se toimi

Laske TTL päivää aiemmin, pystytä uusi kuuntelija ja todista se profiililla, joka on vain sinulla. Testi saman verkon sisältä ei todista juuri mitään, joten käytä matkapuhelinverkossa olevaa puhelinta ja testaa jotain, mitä tunnelin on tarkoitus kuljettaa, ei pingiä endpointiin.

Seuraa molempia osoitteita koko ikkunan ajan. wg show all latest-handshakes uudella isännällä tai OpenVPN:n tilatiedosto kertoo, kuinka monta peeriä on todella siirtynyt. Kun uudella endpointilla on odottamasi peerit ja vanhalla vain perässä tulevat, poista vanha kuuntelija käytöstä, poista vanhentunut NAT-sääntö ja poista osoite palveluntarjoajan palomuurista. Vanhan kuuntelijan poistaminen on se vaihe, joka jää väliin, ja se sulkee aukon, jossa vanhentunut profiili yhä tavoittaa vanhan verkon.

Kirjaa palautuksen liipaisin ennen aloittamista: jos uudella endpointilla ei ole handshakea yhdeltäkään todelliselta asiakkaalta sovitun ikkunan jälkeen, palauta vanha osoite ja lopeta profiilien jakelu. Aja haku sen jälkeen uudelleen ja varmista, ettei mikään kuuntelija ole enää sidottu poistettuun osoitteeseen. Kaksi asiaa siirtyy seuraavaan siirtoon: isäntänimi asiakasprofiilissa, jotta seuraava muutos on DNS-muokkaus, ja palvelimen palautusmuistiinpanojen viereen tallennettu luettelo.