Een lege VPN-tabel blokkeert op zichzelf niets

Een beleidsregel stuurt gemarkeerde pakketten naar een aparte tabel, en de gebruikelijke verwachting is dat het verliezen van de VPN-route ze blokkeert. Het mechanisme doet iets anders. Wanneer een tabel geen overeenkomende route bevat, gaat de opzoeking verder naar de volgende regel in plaats van te stoppen, en de tabel main bevat nog steeds een gewone standaardroute voor de uplink. Het resultaat is een configuratie die fail-closed lijkt en fail-open gedraagt.

Niets is kapot; zo is beleidsroutering gespecificeerd.

De opzoeking gaat verder als een tabel niets heeft

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Neem die regelset: een gemarkeerde opzoeking gaat naar tabel 42, en een latere regel stuurt dezelfde markering naar een tabel met de naam default. Zolang tabel 42 een bruikbare standaardroute bevat, levert de eerste opzoeking het pad. Wanneer die route verdwijnt en niets anders in tabel 42 overeenkomt, wordt de opzoeking geen verwerping; de verwerking gaat verder naar de volgende regel, en wanneer die ook niets vindt, bereikt ze de tabel main. Niets in die reeks meldt welke regel het definitieve antwoord opleverde, dus een werkende verbinding lijkt op een werkend beleid.

Tabel 253, gewoonlijk default genoemd, is een gewone routingtabel en is normaal leeg. De naam is geen instructie om pakketten te laten vallen, en het is niet hetzelfde als een standaardbestemmingsroute binnen een tabel.

Terminale acties beëindigen de zoektocht

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Een terminale regel kan op de VPN-opzoeking volgen in plaats van een opzoeking in een lege tabel. Met dezelfde markering beëindigt een prohibit-actie die na de tabel-42-regel staat de zoektocht wanneer die tabel niets oplevert, en geeft een administratieve afwijzing terug in plaats van de tabel main nog een kans te geven. Unreachable en blackhole zijn ook terminaal, met ander foutgedrag voor de afzender.

Een route van het type throw is anders: binnen die tabel gedraagt hij zich alsof niets overeenkwam, zodat latere regels toch hun beurt krijgen. Dat maakt throw nuttig voor bewuste terugval en onjuist als definitieve blokkade.

Controleer met de echte markering en interface

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Onderzoek de echte regels en tabel in plaats van een diagram, en bevraag dan de stroom met de bron-, markerings- en ingangscontext die hij werkelijk heeft. Een alleen-lezen-opzoeking gericht op een bestemming, waaraan bronadres, interface en markering worden gegeven, meldt de route die de kernel zou kiezen zonder dat er een pakket vertrekt. Een markering in de query opgeven bewijst niet dat de firewall echt verkeer markeert; dat is een aparte controle van de markeringsregels. Bevestig de waarde met een teller of een log voordat u conclusies uit de query trekt.

Lokaal gegenereerde verzoeken hebben hun eigen context nodig, omdat hun markeringspad vaak verschilt van dat van doorgestuurd verkeer. Controleer ze met de uitvoerinterface die de toepassing werkelijk zou gebruiken.

Twee faaltoestanden, niet één

Eén faaltoestand is dat de VPN-route verdwijnt en het verkeer naar de uplink doorvalt. Een dode tunnel waarvan de route geïnstalleerd blijft is een andere: pakketten blijven naar een onbruikbaar pad geleid in plaats van door te vallen, en het symptoom is stil verlies in plaats van een zichtbare directe verbinding. Test beide, en test ook het gedrag bij opstarten, opnieuw verbinden en stoppen van de dienst.

Zo’n regel helpt alleen zolang hij bestaat en zolang pakketten nog de markering dragen die hem selecteert. Een afsluitscript dat de regel verwijdert, of een pad dat de markering stript, herstelt het open gedrag. Die overgangen zijn het oefenen waard.

Pas het beleid afzonderlijk toe op IPv6, en houd goedgekeurde uitzonderingen voor eindpunten expliciet in plaats van impliciet.