En tom VPN-tabell blockerar ingenting i sig själv

En policyregel skickar märkta paket till en dedikerad tabell, och den vanliga förväntan är att förlusten av VPN-rutten blockerar dem. Mekanismen gör något annat. När en tabell inte innehåller någon matchande rutt, fortsätter sökningen till nästa regel i stället för att stanna, och tabellen main har fortfarande en vanlig standardrutt för uplink. Resultatet är en konfiguration som ser fail-closed ut och beter sig fail-open.

Ingenting är trasigt; så är policybaserad routing specificerad.

Sökningen fortsätter när en tabell inte har något

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

Ta den regeluppsättningen: en märkt sökning går till tabell 42, och en senare regel skickar samma märkning till en tabell med namnet default. Så länge tabell 42 har en användbar standardrutt levererar den första sökningen vägen. När den rutten försvinner och ingenting annat i tabell 42 matchar, blir sökningen inte en kastning; behandlingen går vidare till nästa regel, och när den inte heller hittar något når den tabellen main. Ingenting i den sekvensen rapporterar vilken regel som gav det slutliga svaret, så en fungerande anslutning ser ut som en fungerande policy.

Tabell 253, som konventionellt kallas default, är en vanlig routingtabell och är normalt tom. Namnet är ingen instruktion att kasta paket, och det är inte samma sak som en standarddestinationsrutt inuti en tabell.

Terminala åtgärder avslutar sökningen

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

En terminal regel kan följa VPN-sökningen i stället för en sökning i en tom tabell. Med samma märkning avslutar en prohibit-åtgärd placerad efter tabell-42-regeln sökningen när den tabellen inte ger något, och returnerar en administrativ avvisning i stället för att ge tabellen main en ny chans. Unreachable och blackhole är också terminala, med annat felbeteende för avsändaren.

En rutt av typen throw är annorlunda: inom den tabellen beter den sig som om ingenting matchade, så senare regler får ändå sin tur. Det gör throw användbart för avsiktlig återgång och felaktigt som ett slutligt block.

Verifiera med den riktiga märkningen och gränssnittet

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

Undersök de riktiga reglerna och tabellen i stället för ett diagram, och fråga sedan flödet med den käll-, märknings- och ingångskontext som det faktiskt har. En skrivskyddad sökning riktad mot en destination, som får källadress, gränssnitt och märkning angivna, rapporterar den rutt som kärnan skulle välja utan att ett paket lämnar systemet. Att ange en märkning i frågan bevisar inte att brandväggen märker verklig trafik; det är en separat kontroll av märkningsreglerna. Bekräfta värdet med en räknare eller en logg innan du drar slutsatser av frågan.

Lokalt genererade förfrågningar behöver sin egen kontext, eftersom deras märkningsväg ofta skiljer sig från vidarebefordrad trafik. Kontrollera dem med det utgångsgränssnitt som programmet faktiskt skulle använda.

Två feltillstånd, inte ett

Ett feltillstånd är att VPN-rutten försvinner och trafiken faller igenom till uplink. En död tunnel vars rutt finns kvar är ett annat: paketen fortsätter att dirigeras in i en oanvändbar väg i stället för att falla igenom, och symptomet är tyst förlust i stället för en synlig direkt anslutning. Testa båda, och testa även beteendet vid start, återanslutning och tjänstestopp.

En sådan regel hjälper bara så länge den finns och så länge paketen fortfarande bär den märkning som väljer den. Ett avstängningsskript som tar bort regeln, eller en väg som tar bort märkningen, återställer det öppna beteendet. De övergångarna är värda att öva.

Tillämpa policyn på IPv6 separat och håll godkända undantag för slutpunkter explicita i stället för underförstådda.