En tom VPN-tabel blokerer ikke noget i sig selv

En politikregel sender markerede pakker til en dedikeret tabel, og den sædvanlige forventning er, at tabet af VPN-ruten blokerer dem. Mekanismen gør noget andet. Når en tabel ikke indeholder nogen matchende rute, fortsætter opslaget til den næste regel i stedet for at stoppe, og tabellen main holder stadig en almindelig standardrute for uplink. Resultatet er en konfiguration, der ser fail-closed ud og opfører sig fail-open.

Intet er i stykker; sådan er policy routing specificeret.

Opslaget fortsætter, når en tabel ikke har noget

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

Tag det regelsæt: et markeret opslag går til tabel 42, og en senere regel sender samme markering til en tabel ved navn default. Så længe tabel 42 har en brugbar standardrute, leverer det første opslag stien. Når den rute forsvinder, og intet andet i tabel 42 matcher, bliver opslaget ikke et drop; behandlingen går videre til den næste regel, og når den heller ikke finder noget, når den tabellen main. Intet i den sekvens rapporterer hvilken regel der gav det endelige svar, så en fungerende forbindelse ligner en fungerende politik.

Tabel 253, som konventionelt kaldes default, er en almindelig routingtabel og er normalt tom. Dens navn er ikke en instruks om at droppe pakker, og det er ikke det samme som en standarddestinationsrute inde i en tabel.

Terminale handlinger afslutter søgningen

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

En terminal regel kan følge VPN-opslaget i stedet for et opslag i en tom tabel. Med samme markering afslutter en prohibit-handling, der placeres efter tabel-42-reglen, søgningen, når den tabel ikke giver noget, og returnerer en administrativ afvisning i stedet for at give tabellen main en ny chance. Unreachable og blackhole er også terminale, med anderledes fejlopførsel for afsenderen.

En rute af typen throw er anderledes: inden for den tabel opfører den sig, som om intet matchede, så senere regler får stadig deres tur. Det gør throw nyttig til bevidst tilbagerulning og forkert som en endelig blokering.

Verificer med den rigtige markering og grænseflade

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øg de rigtige regler og tabellen i stedet for et diagram, og forespørg derefter flowet med den kilde, markering og indgangskontekst, det faktisk har. Et skrivebeskyttet opslag rettet mod en destination, som får angivet kildeadresse, grænseflade og markering, rapporterer den rute, kernen ville vælge, uden at en pakke forlader systemet. At angive en markering i forespørgslen beviser ikke, at firewallen markerer rigtig trafik; det er en separat kontrol af markeringsreglerne. Bekræft værdien med en tæller eller en log, før du drager konklusioner ud fra forespørgslen.

Lokalt genererede anmodninger har brug for deres egen kontekst, fordi deres markeringsvej ofte adskiller sig fra videresendt trafiks. Kontroller dem med den udgangsgrænseflade, som programmet reelt ville bruge.

To fejltilstande, ikke én

Én fejltilstand er, at VPN-ruten forsvinder, og trafikken falder igennem til uplink. En død tunnel, hvis rute forbliver installeret, er en anden: pakkerne forbliver rettet ind i en ubrugelig sti i stedet for at falde igennem, og symptomet er tavst tab i stedet for en synlig direkte forbindelse. Test begge, og test også opstart, genopkobling og servicestop.

En sådan regel hjælper kun, mens den findes, og mens pakkerne stadig bærer den markering, der vælger den. Et nedlukningsscript, der sletter reglen, eller en sti, der fjerner markeringen, genskaber den åbne opførsel. De overgange er værd at øve.

Anvend politikken på IPv6 separat, og hold godkendte undtagelser for endepunkter eksplicitte i stedet for underforståede.