Om ’n VPN-bediener na ’n nuwe openbare IP te skuif: wat om eerste na te gaan
’n Omruiling op dieselfde plek en ’n parallelle oorskakeling breek op verskillende plekke. Deursoek konfigurasies, NAT en sertifikate, en kyk dan hoe elke kliënt die naam oplos.
Om ’n adres te hertoewys neem ’n minuut. Die week daarna is waar die skuif breek, en selde waar die verskaffer se konsole dit voorstel. ’n Nuwe openbare IP word op vier plekke verwys: die socket waarop die daemon luister, die vertrouensanker wat kliënte verifieer, elke reël wat die ou adres noem, en die DNS-rekord wat hulle saambind. Twee skuiwe lyk identies op ’n beheerpaneel maar gedra hulle heeltemal anders: die adres hertoewys op die masjien wat jy bestuur, of ’n tweede eindpunt opstel en kliënte daarheen skuif. Die kontroles hieronder plaas die goedkoop foute eerste, en elke afdeling noem vir watter skuif dit geld.
Skuiwe op dieselfde plek en parallelle oorskakeling is verskillende take
’n Omruiling op dieselfde plek behou die gasheer, die sleutels, die roetebelys en die gebruikerslys; net die adres verander. Dit is wat die hertoewysing van ’n drywende IP doen, en by verskeie verskaffers merk die gas nooit iets nie, want die vertaling gebeur voor die instansie. ’n Herbou of hertoewysing deur die verskaffer is harder: die gas sien die verandering, en alles wat die ou waarde gekas het, leer dit op dieselfde oomblik.
’n Parallelle eindpunt is ’n tweede gasheer wat dieselfde werk doen. Bou dit, toets dit met een profiel en laat die ou een antwoord totdat die nuwe homself oor ’n werklike pad bewys. Die prys is toestand. Sonder gedeelde peer-inskrywings, herroepings en logboeke het jy twee netwerke wat toevallig ’n naam deel.
| 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 |
Vind elke plek waar die ou adres neergeskryf is
Begin met ’n teks-soektog, want konfigurasielêers is die maklike helfte. Deursoek die daemon-konfigurasie, firewall-fragmente, moniteringsteikens en enige gegenereerde kliëntbondel op skyf. Sluit die IPv6-adres in as jy een publiseer; ’n skuif wat net die A-rekord volg, laat dubbelstapel-kliënte op die ou pad.
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
Deursoek dan die kern, want ’n lopende stelsel hou die adres op plekke wat geen lêer noem nie. ’n Statiese bron-NAT-reël, ’n ipset-inskrywing, ’n bindadres en ’n conntrack-inskrywing oorleef die konfigurasiewysiging wat hulle verwyder het, en sommige oorleef ’n herlaai omdat hulle uit ’n gestoorde reëlstel teruggekom het. Een laag hoër is verskaffer-sekuriteitsgroepe, lasbalanseerder-teikens en moniteringskontroles glad nie op jou lêerstelsel nie.
Skryf die inventaris neer voordat jy enigiets verander; dit dien ook as die terugrolskrip.
Gasheernaam-kliënte herstel; letterlike-IP-kliënte word stil
As kliënte die bediener per gasheernaam bereik, is die oorskakeling meestal ’n DNS-probleem, en die TTL wat jy gister gestel het, bepaal hoe erg dit word. Resolvers kas, stomp-resolvers kas weer, en baie kliënte soek die naam net op ’n nuwe verbinding op, so ’n gevestigde tonnel hou sy beginadres.
As die eindpunt ’n letterlike adres is, herresolver niks en teken niks ’n klag aan nie. WireGuard stoor ’n opgeloste socketadres: Endpoint = vpn.example.net:51820 word ’n IP op die oomblik dat wg-quick up loop en bly daardie IP totdat jy dit verander. OpenVPN is meer verdraagsaam: dit resolver die remote-gasheernaam by verbindingstyd en probeer met resolv-retry infinite weer DNS by herverbinding. Met ’n letterlike IP bly albei na ’n masjien skakel wat nie meer bestaan nie.
Wat mense mislei, is die spieëlbeeld. ’n Kliënt wat al na die nuwe adres wys terwyl die ou luisteraar nog antwoord, slaag elke toets wat jy van jou eie lessenaar af hardloop. Ek is al so geflous: die nuwe eindpunt het met een poging op ’n selfoon opgekom, en ’n kliënt met ’n verouderde profiel het eers opgeduik toe die ou luisteraar veel later afgeskakel is.
Vertroue beweeg nie saam met die adres nie
WireGuard skei identiteit van bereikbaarheid, wat ’n adresverskuiwing byna gratis maak. Peers word deur publieke sleutel geïdentifiseer, en die eindpunt is net waar pakkette tans heen gaan; ’n gasheer werk ’n peer se eindpunt by uit die bronadres van die mees onlangse geauthentiseerde pakket. ’n Ledige peer het steeds ’n rede nodig om met die nuwe plek te praat, en hy leer die adres eers wanneer sy sessie uitloop en die handdruk-herprobeersels op ’n sigbare plek misluk. Die beknopte handleiding vir WireGuard dek die eindpuntveld.
TLS-gebaseerde bedieners is die teenoorgestelde geval. Die sertifikaat is aan ’n naam gebind, en ’n kliënt wat ’n adres skakel, vergelyk wat hy geskakel het met die vak-alternatiewe name. Verbind per IP na ’n sertifikaat wat net ’n DNS-SAN dra, en verifikasie misluk: die naam wat die kliënt gebruik het, is nie in die sertifikaat nie. Heruitreiking met ’n IP-SAN maak daardie een verbinding reg en die volgende skuif erger. Om ’n gasheernaam in die profiel te hou en verify-x509-name in plek te laat, hou die kontrole streng terwyl die adres daaronder verander.
Kontroleer dan waaraan die daemon gebind is; ’n socket wat aan die ou adres vasgepen is, faal stil. ’n OpenVPN-bediener wat met local 203.0.113.10 begin is, weier om op te kom sodra daardie adres weg is, terwyl ’n luisteraar op 0.0.0.0 die verandering gratis volg. NAT splits dieselfde: MASQUERADE volg watter adres die boks nou ook het, en ’n statiese SNAT --to-source 203.0.113.10 hou aan om na ’n adres te herskryf wat jy nie meer besit nie, so terugkeerverkeer verdwyn. As die nuwe adres met ’n ander opstroom-gateway kom, kontroleer rp_filter: omgekeerde-pad-filtering laat terugkeerverkeer val wat op ’n koppelvlak aankom wat die kern nie verwag het nie.
Oorskakelorde en die bewyse dat dit gewerk het
Verlaag die TTL ’n dag vooruit, stel die nuwe luisteraar op en bewys dit met ’n profiel wat net jy het. ’n Toets van binne dieselfde netwerk bewys byna niks, so gebruik ’n selfoon op sellulêr en toets iets wat die tonnel veronderstel is om te dra eerder as ’n ping na die eindpunt.
Dophou albei adresse deur die venster. wg show all latest-handshakes op die nuwe gasheer, of die OpenVPN-statuslêer, vertel jou hoeveel peers werklik geskuif het. Wanneer die nuwe eindpunt die peers het wat jy verwag en die ou een net agterblwers het, tree die ou luisteraar af, verwyder die verouderde NAT-reël en haal die adres uit die verskaffer se firewall. Om die ou luisteraar te verwyder is die stap wat oorgeslaan word, en dit sluit die gaping waar ’n verouderde profiel nog die ou netwerk bereik.
Stel die terugrolsneller skriftelik voor jy begin: as die nuwe eindpunt ná die ooreengekome venster geen handdruk van ’n enkele werklike kliënt het nie, herstel die ou adres en stop die verspreiding van profiele. Hardloop die soektog daarna weer en bevestig dat geen luisteraar nog aan ’n afgetrede adres gebind is nie. Twee dinge dra vorentoe na die volgende skuif: ’n gasheernaam in die kliëntprofiel sodat die volgende verandering ’n DNS-wysiging is, en die inventaris wat langs die bediener se herstelnotas gestoor is.