Un tabel VPN gol nu blochează nimic de la sine

O regulă de politică trimite pachetele marcate către un tabel dedicat, iar așteptarea obișnuită este că pierderea rutei VPN le blochează. Mecanismul face altceva. Când un tabel nu conține nicio rută potrivită, căutarea continuă către regula următoare în loc să se oprească, iar tabelul main păstrează încă o rută implicită obișnuită pentru uplink. Rezultatul este o configurație care pare fail-closed și se comportă ca fail-open.

Nimic nu este stricat; așa este specificată rutarea bazată pe politici.

Căutarea continuă când un tabel nu are nimic

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

Luați acel set de reguli: o căutare marcată merge în tabelul 42, iar o regulă ulterioară trimite aceeași marcă într-un tabel numit default. Cât timp tabelul 42 conține o rută implicită utilizabilă, prima căutare furnizează calea. Când acea rută dispare și nimic altceva din tabelul 42 nu se potrivește, căutarea nu devine o aruncare; procesarea trece la regula următoare, iar când nici aceasta nu găsește nimic, ajunge la tabelul main. Nimic din acea secvență nu raportează care regulă a produs răspunsul final, așa că o conexiune funcțională arată ca o politică funcțională.

Tabelul 253, numit convențional default, este un tabel de rutare obișnuit și este de obicei gol. Numele său nu este o instrucțiune de a arunca pachete și nu este același lucru cu o rută de destinație implicită în interiorul unui tabel.

Acțiunile terminale încheie căutarea

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

O regulă terminală poate urma căutării VPN în locul unei căutări într-un tabel gol. Cu aceeași marcă, o acțiune prohibit plasată după regula tabelului 42 încheie căutarea atunci când acel tabel nu oferă nimic, returnând o respingere administrativă în loc să ofere tabelului main încă o șansă. Unreachable și blackhole sunt și ele terminale, cu un comportament de eroare diferit pentru expeditor.

O rută de tip throw este diferită: în interiorul acelui tabel se comportă ca și cum nimic nu s-ar fi potrivit, astfel încât regulile ulterioare își primesc totuși rândul. Asta face throw util pentru o revenire deliberată și greșit ca blocaj final.

Verificați cu marca și interfața reale

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

Inspectați regulile și tabelul reale, nu o diagramă, apoi interogați fluxul cu contextul de sursă, marcă și intrare pe care îl are cu adevărat. O căutare doar pentru citire îndreptată spre o destinație, căreia i se indică adresa sursă, interfața și marca, raportează ruta pe care nucleul ar alege-o fără ca un pachet să iasă. Furnizarea unei mărci în interogare nu demonstrează că firewall-ul marchează trafic real; aceasta este o verificare separată a regulilor de marcare. Confirmați valoarea cu un contor sau un jurnal înainte de a trage concluzii din interogare.

Cererile generate local au nevoie de propriul context, deoarece calea lor de marcare diferă adesea de cea a traficului redirecționat. Verificați-le cu interfața de ieșire pe care aplicația ar folosi-o cu adevărat.

Două stări de eșec, nu una

O stare de eșec este dispariția rutei VPN și căderea traficului pe uplink. Un tunel mort a cărui rută rămâne instalată este alta: pachetele rămân îndreptate într-o cale inutilizabilă în loc să cadă, iar simptomul este pierdere silențioasă, nu o conexiune directă vizibilă. Testați ambele și, de asemenea, comportamentul la pornire, reconectare și oprirea serviciului.

O astfel de regulă ajută doar cât timp există și cât timp pachetele mai poartă marca ce o selectează. Un script de oprire care șterge regula, sau o cale care elimină marca, restaurează comportamentul deschis. Acele tranziții merită exersate.

Aplicați politica pe IPv6 separat și păstrați excepțiile de punct final aprobate explicite, nu implicite.