Håll nftables-policyn stabil medan VPN-gränssnittet kommer

Tunnlar är engångs; policy bör inte vara det. På en Linux-gateway kan en nftables-regel som matchar tunnelgränssnittet på namn laddas en gång och fortsätter att gälla varje gång gränssnittet dyker upp. Gränssnittet har ändå en livscykel: det skapas, det försvinner, och rutterna och översättningarna runt det följer sitt eget schema. Det är separationen av dessa ägare som håller åtkomsten stabil under en återanslutning.

En namnmatchning överlever gränssnittet

nftables erbjuder numeriska gränssnittsindexmatchningar och de dynamiska namnmatchningarna iifname och oifname. Regler som använder dessa namn laddas rent även när tunnelingenheten ännu inte har skapats, vilket är precis vad en regeluppsättning behöver vid uppstart. Matchningen upphör om gränssnittet byter namn och återupptas när ett nytt gränssnitt tar namnet. Ett numeriskt index saknar den egenskapen, därför är namnformen det vanliga valet för en tunnel.

Namnet är en matchningsnyckel, inte bevis för vem som finns i andra änden. Autentisering av peer är fortfarande VPN:s uppgift.

Läs kedjan innan du lägger till regler

Titta på vad regeluppsättningen innehåller nu och var en ny regel skulle sitta, eftersom ordningen avgör resultatet.

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

Listningen visar kedjor, regler och handtag, och kontrolläget validerar en kandidatfil utan att ladda den. Ett tillstånd bara för tunneln som placeras efter ett tidigare godkännande för samma flöde ändrar ingenting, eftersom den första matchande regeln vinner. Därför kan en sen regel se korrekt ut och inte ha någon verkan. Läs kedjan i ordning och bekräfta att förbudet för trafik från klient till upplänk fortfarande kommer före allt bredare.

Rutter, översättning och flöden har andra ägare

Gränssnittets närvaro skapar inga rutter och autentiserar inte peeren. Det hör till VPN-hanteraren, medan översättningen har en tredje livscykel.

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

conntrack-listningen visar befintliga flöden med deras ursprungliga och översatta värden, och ruttlistningen visar vad hanteraren installerade för gränssnittet. NAT-regler upprättar tillstånd för anslutningsspårning vid det första paketet, så ett upprättat flöde behåller sin översättning även efter att regeln ändras. Därför är en regel som uppdateras och ett flöde som använder den nya vägen två olika påståenden. Bestäm vilka sessioner som måste återansluta och låt orelaterade flöden vara.

Acceptera kallstart, förlust och återhämtning

Testa gatewayen med tunneln frånvarande vid uppstart, sedan närvarande och sedan efter ett avbrott och en återkomst. Bekräfta att otillåten vidarebefordran fortsätter att nekas medan tunneln saknas, att ett nytt tillåtet flöde fungerar när peeren har autentiserats och att återhämtning inte kräver att orelaterat tillstånd rensas. Rensa inte hela POSTROUTING-kedjan eller varje conntrack-post som en profils stoppåtgärd, eftersom andra tjänster delar dem. Anteckna vilken komponent som ändrade gränssnittet, rutten och policyn, i stället för bara att en starthook avslutades med noll.

En policy som överlever en återanslutning är en där ägarna är namngivna och reglerna har testats med tunneln både nere och uppe. En hook som rapporterar framgång bevisar bara att hooken kördes.