Houd het nftables-beleid stabiel terwijl de VPN-interface komt

Tunnels zijn wegwerpbaar; beleid zou dat niet moeten zijn. Op een Linux-gateway kan een nftables-regel die de tunnelinterface op naam matcht één keer worden geladen en blijft van toepassing telkens wanneer die interface verschijnt. De interface heeft toch een levenscyclus: hij wordt aangemaakt, hij verdwijnt, en de routes en vertalingen eromheen volgen hun eigen schema. Juist het scheiden van die eigenaren houdt de toegang stabiel tijdens een herverbinding.

Een naamovereenkomst overleeft de interface

nftables biedt numerieke interface-indexovereenkomsten en de dynamische naamovereenkomsten iifname en oifname. Regels met die namen laden schoon, zelfs wanneer het tunnelapparaat nog niet is aangemaakt, wat precies is wat een regelset bij het opstarten nodig heeft. De overeenkomst stopt als de interface wordt hernoemd en hervat wanneer een nieuwe interface die naam overneemt. Een numerieke index mist die eigenschap, daarom is de naamvorm de gebruikelijke keuze voor een tunnel.

De naam is een matchingssleutel, geen bewijs van wie aan de andere kant staat. Authenticatie van de peer blijft het werk van de VPN.

Lees de keten voordat u regels toevoegt

Kijk wat de regelset nu bevat en waar een nieuwe regel zou staan, want de volgorde bepaalt de uitkomst.

nft list ruleset
nft -c -f /etc/nftables.conf

De lijst toont ketens, regels en handles, en de controlemode valideert een kandidaatbestand zonder het te laden. Een toestemming alleen voor de tunnel die na een eerdere acceptatie voor dezelfde stroom staat, verandert niets, omdat de eerste overeenkomende regel wint. Daarom kan een late regel er correct uitzien en geen effect hebben. Lees de keten op volgorde en bevestig dat het verbod op verkeer van client naar uplink nog steeds voor alles breder komt.

Routes, vertaling en stromen hebben andere eigenaren

De aanwezigheid van de interface maakt geen routes en authenticeert de peer niet. Die horen bij de VPN-beheerder, terwijl de vertaling een derde levenscyclus heeft.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

De conntrack-lijst toont bestaande stromen met hun oorspronkelijke en vertaalde waarden, en de routelijst toont wat de beheerder voor de interface heeft geïnstalleerd. NAT-regels leggen de verbindingsbewakingstoestand bij het eerste pakket vast, dus een gevestigde stroom behoudt zijn vertaling zelfs nadat de regel is gewijzigd. Daarom zijn een regel die wordt bijgewerkt en een stroom die het nieuwe pad gebruikt twee verschillende uitspraken. Bepaal welke sessies opnieuw moeten verbinden en laat ongerelateerde stromen met rust.

Accepteer koude start, verlies en herstel

Test de gateway met de tunnel afwezig bij het opstarten, daarna aanwezig, en daarna na een onderbreking en een terugkeer. Bevestig dat verboden doorsturen geweigerd blijft zolang de tunnel ontbreekt, dat een nieuwe toegestane stroom werkt zodra de peer is geauthenticeerd en dat herstel niet vereist dat ongerelateerde toestand wordt gewist. Wis niet de hele POSTROUTING-keten of elke conntrack-vermelding als stopactie van één profiel, omdat andere diensten ze delen. Noteer welke component de interface, de route en het beleid heeft gewijzigd, in plaats van alleen dat een starthook met nul eindigde.

Een beleid dat een herverbinding overleeft, is er een waarvan de eigenaren zijn benoemd en de regels zijn getest met de tunnel zowel omlaag als omhoog. Een hook die succes meldt, bewijst alleen dat de hook liep.