’n Leë VPN-tabel blokkeer op sigself niks

’n Beleidsreël stuur gemerkte pakkette na ’n toegewyde tabel, en die gewone verwagting is dat die verlies van die VPN-roete hulle blokkeer. Die meganisme doen iets anders. Wanneer ’n tabel geen passende roete bevat nie, gaan die opsoek na die volgende reël voort eerder as om te stop, en die tabel main hou steeds ’n gewone verstekroete vir die uplink. Die resultaat is ’n opset wat soos fail-closed lyk maar fail-open optree.

Niks is stukkend nie; dit is hoe beleidsroetering gespesifiseer word.

Opsoek gaan voort wanneer ’n tabel niks het

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

Neem daardie reëlstel: ’n gemerkte opsoek gaan na tabel 42, en ’n latere reël stuur dieselfde merk na ’n tabel met die naam default. Terwyl tabel 42 ’n bruikbare verstekroete hou, lewer die eerste opsoek die pad. Wanneer daardie roete verdwyn en niks anders in tabel 42 pas nie, word die opsoek nie ’n verwerping nie; die verwerking gaan na die volgende reël voort, en wanneer dié ook niks vind nie, bereik dit die tabel main. Niks in daardie reeks rapporteer watter reël die finale antwoord gelewer het, so ’n werkende verbinding lyk soos ’n werkende beleid.

Tabel 253, wat gewoonlik default genoem word, is ’n gewone roetertabel en is normaalweg leeg. Die naam daarvan is nie ’n opdrag om pakkette te laat val nie, en dit is nie dieselfde ding as ’n verstekbestemmingsroete binne ’n tabel nie.

Terminale aksies beëindig die soektog

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

’n Terminale reël kan op die VPN-opsoek volg in plaas van ’n opsoek na ’n leë tabel. Met dieselfde merk beëindig ’n prohibit-aksie wat ná die tabel-42-reël geplaas word, die soektog wanneer daardie tabel niks oplewer nie, en gee ’n administratiewe verwerping terug in plaas daarvan om die tabel main nog ’n kans te gee. Unreachable en blackhole is ook terminaal, met ander foutgedrag vir die sender.

’n Roete van die tipe throw is anders: binne daardie tabel tree dit op asof niks gepas het nie, so latere reëls kry steeds hulle beurt. Dit maak throw nuttig vir doelbewuste terugval en verkeerd as ’n finale blok.

Verifieer met die werklike merk en koppelvlak

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

Ondersoek die werklike reëls en tabel eerder as ’n diagram, en bevraag dan die vloei met die bron, merk en inkomende konteks wat dit werklik het. ’n Lees-alleen-opsoek wat op ’n bestemming gerig is en die bronadres, koppelvlak en merk kry, rapporteer die roete wat die kernel sou kies sonder dat ’n pakket die masjien verlaat. Om ’n merk in die navraag te gee, bewys nie dat die firewall werklike verkeer merk nie; dit is ’n aparte kontrole van die merkende reëls. Bevestig die waarde met ’n teller of ’n log voordat jy gevolgtrekkings uit die navraag maak.

Plaaslik gegenereerde versoeke het hulle eie konteks nodig, want hulle merkpad verskil dikwels van dié van deurgestuurde verkeer. Kontroleer hulle met die uitvoerkoppelvlak wat die toepassing werklik sou gebruik.

Twee fouttoestande, nie een nie

Een fouttoestand is dat die VPN-roete verdwyn en die verkeer na die uplink deurval. ’n Dooie tonnel waarvan die roete geïnstalleer bly, is ’n ander een: pakkette bly in ’n onbruikbare pad ingestuur eerder as om deur te val, en die simptoom is stil verlies eerder as ’n sigbare direkte verbinding. Toets albei, en toets ook die gedrag by opstart, herverbinding en diensstop.

So ’n reël help net terwyl dit bestaan en terwyl pakkette steeds die merk dra wat dit kies. ’n Afskakelingskrip wat die reël verwyder, of ’n pad wat die merk stroop, herstel die oop gedrag. Daardie oorgange is die moeite werd om te oefen.

Pas die beleid afsonderlik op IPv6 toe, en hou goedgekeurde eindpunt-uitsonderings eksplisiet eerder as geïmpliseer.