UFW-undtagelse til VPN, når slutpunktets adresse ændres

Klienten forsøger at genoprette forbindelsen, og der forlader intet maskinen, selv om samme profil virkede i sidste uge. Slutpunktets værtsnavn opløses nu til en anden adresse, og undtagelsen for udgående trafik nævner stadig den gamle. Den ene forældede tilladelse er nok til at forvandle en fungerende kill switch til et totalt udfald, og den er usynlig i hver statusindikator på skrivebordet. Reparationen er et lille forløb, ikke en ændring på én linje.

Tunnelen genoprettes, og så forlader intet maskinen

En udgående regel, der navngiver en destinationsadresse, er et øjebliksbillede, og DNS-svar er det ikke. Når udbyderen roterer en adresse, matcher den pakke, klienten sender mod den nye peer, ingenting og kastes af standardafvisningen. Klienten rapporterer derefter en timeout, som lyder som et serverproblem snarere end et firewallproblem.

At fastlåse den adresse, et offentligt opslag returnerer, får det til at virke i dag og efterlader det brudt i morgen. Det er en enkeltstående ændring, ikke en vedligeholdelsespolitik.

Beskriv den undtagelse, du faktisk mener

Start med at skrive de fire værdier ned, som reglen har brug for: det godkendte slutpunktsnavn eller adressesæt, transporten, destinationsporten og det interface, pakken forlader via. Alle fire er en del af tilladelsen, og enhver af dem kan være forkert, mens reglen stadig ser rimelig ud. En regel, der er korrekt på tre af dem, fejler præcis som en regel, der er forkert på alle fire. Skriv dem ned, før du taster kommandoen, for en regel er kun så god som beskrivelsen bag den.

Kommandoen nedenfor viser formen for ét IPv4 UDP-slutpunkt på en kablet uplink. Erstat begge værdier med dem, du har verificeret mod udrulningen.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Den tilladelse autoriserer ikke vilkårlige destinationer på samme port, opretter ikke en lytter og dækker ikke TCP. UFW-manualsiden beskriver, hvordan adresse, interface og protokol indsnævrer en regel, og indsnævringen er hele pointen.

Forny det som ét forløb

Behandl undtagelsen som en ressource med en ejer og en overgang, ikke som en kommando, nogen husker at køre. Skaf først en kandidat fra udrulningens egen resolver og slutpunktsinventar, og definer bevidst, hvordan navnet opløses, før tunnelen findes. Validér derefter kandidaten mod den tilsigtede protokol, port og adressefamilie, før du rører regelsættet.

Installer først den nye snævre tilladelse, og bekræft at den blev indlæst, for at bede klienten om at bruge en adresse, som firewallen stadig blokerer, giver en fejl, der ligner en serverfejl. Lad urelaterede regler være urørte under ændringen.

Observer klientens overgang gennem dens understøttede genopkoblingsvej, og bekræft hvilken fjernadresse den valgte. At opdatere DNS alene flytter ikke en eksisterende socket, og en indstilling for slutpunktspersistens kan holde klienten på den gamle peer længe efter, at posten er ændret.

Til sidst skal du bevidst trække den forældede tilladelse tilbage og tillade det godkendte overlapningsvindue, mens en gammel session stadig er aktiv. At fjerne den gamle post for tidligt giver et kort udfald; at lade den blive for evigt efterlader en tilladelse, ingen kan forklare.

Træk den gamle tilladelse bevidst tilbage

Fjernelsen er der, hvor det meste af risikoen ligger, fordi den gamle regel er det eneste, der virker lige nu. Hvis installationen af kandidaten fejlede, må du ikke fortsætte og slette den post, der stadig bærer trafik. Hvis selve fjernelsen fejler, skal du registrere den forældede tilladelse som forældet i stedet for at erklære politikken aktuel.

Gentag hele gennemgangen, når uplinken skifter fra Ethernet til Wi-Fi, når transporten ændres, eller når en tjeneste roterer over flere adresser. En interfacespecifik regel skal stoppe med at matche efter et netværksskift, og den adfærd er korrekt, selv om det ligner en regression.

Bevis derefter kontrakten med ufarlig trafik. Det godkendte slutpunkt skal kunne nås under opsætningen, den beskyttede applikation skal virke, når der er forbindelse, og urelateret direkte trafik skal forblive blokeret under et udfald. Medtag begge adressefamilier og ét bevidst mislykket opdateringsforsøg, da en forbindelse, der lykkes efter en enkelt ændring af en fastlåst adresse, ikke beviser noget af det.