UFW-uitzondering voor VPN wanneer het endpointadres verandert

De client probeert opnieuw te verbinden en er verlaat niets de machine, hoewel hetzelfde profiel vorige week nog werkte. De hostnaam van het endpoint wijst nu naar een ander adres, en de uitgaande uitzondering noemt nog het oude. Die ene verouderde toestemming is genoeg om een werkende kill switch in een totale storing te veranderen, en ze is onzichtbaar in elke statusindicator die de desktop toont. De reparatie is een kleine werkstroom, geen wijziging van één regel.

De tunnel verbindt opnieuw, en dan gaat er niets meer uit

Een uitgaande regel die een bestemmingsadres noemt is een momentopname, en DNS-antwoorden zijn dat niet. Wanneer de provider een adres roteert, past het pakket dat de client naar de nieuwe peer stuurt op niets en wordt het door de standaardweigering weggegooid. De client meldt dan een time-out, wat eerder als een serverprobleem dan als een firewallprobleem klinkt.

Het adres vastzetten dat een openbare lookup teruggeeft laat vandaag werken en laat morgen stuk. Dat is een eenmalige wijziging, geen onderhoudsbeleid.

Beschrijf de uitzondering die u werkelijk bedoelt

Begin met het opschrijven van de vier waarden die de regel nodig heeft: de goedgekeurde endpointnaam of adressenset, het transport, de bestemmingspoort en de interface waar het pakket uitgaat. Alle vier maken deel uit van de toestemming, en elk ervan kan fout zijn terwijl de regel er nog plausibel uitziet. Een regel die op drie ervan klopt, faalt precies zoals een regel die op alle vier fout is. Schrijf ze op voordat u het commando typt, want een regel is alleen zo goed als de beschrijving erachter.

Het commando hieronder toont de vorm voor één IPv4 UDP-endpoint op een bekabelde uplink. Vervang beide waarden door de waarden die u tegen de uitrol hebt gecontroleerd.

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

Die toestemming staat geen willekeurige bestemmingen op dezelfde poort toe, maakt geen listener aan en dekt geen TCP. De UFW-handleidingspagina beschrijft hoe adres, interface en protocol een regel vernauwen, en die vernauwing is het hele punt.

Ververs het als één werkstroom

Behandel de uitzondering als een resource met een eigenaar en een overgang, niet als een commando dat iemand zich herinnert. Haal eerst een kandidaat uit de resolver en de endpointinventaris van de uitrol zelf, en bepaal bewust hoe die naam wordt opgelost voordat de tunnel bestaat. Valideer de kandidaat daarna tegen het beoogde protocol, de poort en de adresfamilie voordat u de regelset aanraakt.

Installeer eerst de nieuwe smalle toestemming en bevestig dat die is geladen, want de client vragen een adres te gebruiken dat de firewall nog blokkeert levert een fout op die op een serverfout lijkt. Laat ongerelateerde regels tijdens de wijziging ongemoeid.

Observeer de overgang van de client via zijn ondersteunde herverbindingspad en bevestig welk extern adres hij koos. Alleen DNS bijwerken verplaatst een bestaande socket niet, en een instelling voor endpointpersistentie kan de client nog lang op de oude peer houden nadat de record is gewijzigd.

Trek ten slotte de verouderde toestemming bewust terug, met inachtneming van het goedgekeurde overlopplevenster zolang een oude sessie nog actief is. De oude vermelding te vroeg verwijderen geeft een korte storing; haar voor altijd laten staan laat een toestemming achter die niemand kan uitleggen.

Trek de oude toestemming bewust terug

Verwijderen is waar het meeste risico zit, omdat de oude regel het enige is dat nu werkt. Als de installatie van de kandidaat is mislukt, ga dan niet verder en verwijder de vermelding niet die nog verkeer draagt. Als het verwijderen zelf mislukt, noteer de verouderde toestemming dan als verouderd in plaats van het beleid actueel te verklaren.

Herhaal de hele beoordeling wanneer de uplink van Ethernet naar Wi-Fi verandert, wanneer het transport verandert of wanneer een dienst over meerdere adressen roteert. Een interfacespecifieke regel hoort na een netwerkwijziging niet meer te matchen, en dat gedrag is correct ook al lijkt het op een regressie.

Bewijs daarna het contract met onschadelijk verkeer. Het goedgekeurde endpoint moet tijdens de installatie bereikbaar zijn, de beschermde toepassing moet werken zodra ze verbonden is, en ongerelateerd direct verkeer moet tijdens een storing geblokkeerd blijven. Neem beide adresfamilies en één bewust mislukte updatepoging op, want een verbinding die slaagt na één wijziging van een vastgezet adres bewijst geen van die gevallen.