Klienten prøver å koble til på nytt, og ingenting forlater maskinen, selv om samme profil fungerte forrige uke. Vertsnavnet til endepunktet løses nå opp til en annen adresse, og unntaket for utgående trafikk nevner fortsatt den gamle. Den ene foreldede tillatelsen er nok til å gjøre en fungerende kill switch om til et totalt avbrudd, og den er usynlig i hver statusindikator skrivebordet viser. Reparasjonen er en liten arbeidsflyt, ikke en endring på én linje.

Tunnelen kobler til på nytt, og så forlater ingenting maskinen

En utgående regel som nevner en destinasjonsadresse er et øyeblikksbilde, og DNS-svar er det ikke. Når leverandøren roterer en adresse, passer ikke pakken klienten sender mot den nye peeren til noe og slippes av standardnektelsen. Klienten rapporterer da en tidsavbrudd, som høres ut som et serverproblem snarere enn et brannmurproblem.

Å låse adressen et offentlig oppslag returnerer får det til å virke i dag og lar morgendagen være ødelagt. Det er en engangsendring, ikke en vedlikeholdspolicy.

Beskriv unntaket du faktisk mener

Begynn med å skrive ned de fire verdiene regelen trenger: det godkjente endepunktnavnet eller adresseområdet, transporten, destinasjonsporten og grensesnittet pakken forlater gjennom. Alle fire er en del av tillatelsen, og hvilken som helst av dem kan være feil mens regelen fortsatt ser rimelig ut. En regel som er riktig på tre av dem, feiler nøyaktig som en regel som er feil på alle fire. Skriv dem ned før du skriver kommandoen, for en regel er bare så god som beskrivelsen bak den.

Kommandoen nedenfor viser formen for ett IPv4 UDP-endepunkt på en kablet uplink. Erstatt begge verdiene med dem du verifiserte mot utrullingen.

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

Den tillatelsen autoriserer ikke vilkårlige destinasjoner på samme port, oppretter ikke en lytter og dekker ikke TCP. UFW-manualsiden beskriver hvordan adresse, grensesnitt og protokoll snevrer inn en regel, og den innsnevringen er hele poenget.

Forny det som én arbeidsflyt

Behandle unntaket som en ressurs med en eier og en overgang, ikke som en kommando noen husker å kjøre. Skaff først en kandidat fra utrullingens egen resolver og endepunktinventar, og definer bevisst hvordan det navnet løses opp før tunnelen finnes. Valider deretter kandidaten mot den tiltenkte protokollen, porten og adressefamilien før du rører regelverket.

Installer først den nye snevre tillatelsen og bekreft at den ble lastet, for å be klienten bruke en adresse brannmuren fortsatt blokkerer gir en feil som ser ut som en serverfeil. La urelaterte regler være urørt under endringen.

Observer klientens overgang gjennom dens støttede gjentilkoblingsvei og bekreft hvilken fjernadresse den valgte. Å bare oppdatere DNS flytter ikke en eksisterende socket, og en innstilling for endepunktspersistens kan holde klienten på den gamle peeren lenge etter at posten er endret.

Til slutt trekker du den foreldede tillatelsen tilbake med vilje, og tillater det godkjente overlappvinduet mens en gammel økt fortsatt er aktiv. Å fjerne den gamle oppføringen for tidlig gir et kort avbrudd; å la den bli for alltid etterlater en tillatelse ingen kan forklare.

Trekk den gamle tillatelsen tilbake med vilje

Fjerningen er der mesteparten av risikoen ligger, fordi den gamle regelen er det eneste som virker akkurat nå. Hvis installasjonen av kandidaten mislyktes, ikke fortsett og ikke slett oppføringen som fortsatt bærer trafikk. Hvis selve fjerningen mislykkes, registrer den foreldede tillatelsen som foreldet i stedet for å erklære policyen oppdatert.

Gjenta hele gjennomgangen når uplinken skifter fra Ethernet til Wi-Fi, når transporten endres, eller når en tjeneste roterer over flere adresser. En grensesnittspesifikk regel skal slutte å matche etter en nettverksendring, og den oppførselen er riktig selv om den ser ut som en regresjon.

Bevis deretter kontrakten med ufarlig trafikk. Det godkjente endepunktet må være nåbart under oppsettet, den beskyttede applikasjonen må virke når den er tilkoblet, og urelatert direkte trafikk må forbli blokkert under et avbrudd. Ta med begge adressefamiliene og ett bevisst mislykket oppdateringsforsøk, siden en tilkobling som lykkes etter én enkelt endring av en låst adresse ikke beviser noen av disse tilfellene.

Relaterte artikler