Unha táboa VPN baleira non bloquea nada por si soa

Unha regra de política envía os paquetes marcados a unha táboa dedicada, e a expectativa habitual é que a perda da ruta VPN os bloquee. O mecanismo fai outra cousa. Cando unha táboa non contén ningunha ruta coincidente, a busca continúa cara á regra seguinte en lugar de deterse, e a táboa main aínda conserva unha ruta predeterminada ordinaria para o enlace ascendente. O resultado é unha configuración que parece fail-closed e compórtase como fail-open.

Nada está roto; así é como se especifica o encamiñamento por políticas.

A busca continúa cando unha táboa non ten nada

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

Tome ese conxunto de regras: unha busca marcada vai á táboa 42, e unha regra posterior envía a mesma marca a unha táboa chamada default. Mentres a táboa 42 mantén unha ruta predeterminada utilizábel, a primeira busca fornece o camiño. Cando esa ruta desaparece e nada máis na táboa 42 coincide, a busca non se converte nun descarte; o procesamento pasa á regra seguinte, e cando esa tampouco atopa nada, chega á táboa main. Nada nesa secuencia informa de que regra produciu a resposta final, así que unha conexión que funciona parece unha política que funciona.

A táboa 253, chamada convencionalmente default, é unha táboa de encamiñamento ordinaria e normalmente está baleira. O seu nome non é unha instrución para descartar paquetes, e non é o mesmo ca unha ruta de destino predeterminada dentro dunha táboa.

As accións terminais terminan a busca

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

Unha regra terminal pode seguir a busca VPN en lugar dunha busca nunha táboa baleira. Coa mesma marca, unha acción prohibit colocada despois da regra da táboa 42 termina a busca cando esa táboa non dá nada, devolvendo un rexeitamento administrativo en vez de ofrecer á táboa main outra oportunidade. Unreachable e blackhole tamén son terminais, cun comportamento de erro distinto para o remitente.

Unha ruta de tipo throw é distinta: dentro desa táboa compórtase coma se nada coincidise, así que as regras posteriores seguen tendo a súa quenda. Iso fai que throw sexa útil para un retroceso deliberado e incorrecto como bloque final.

Verifique coa marca e a interface reais

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

Inspeccione as regras e a táboa reais en lugar dun diagrama, e despois consulte o fluxo co contexto de orixe, marca e entrada que realmente ten. Unha busca de só lectura dirixida a un destino, á que se indica o enderezo de orixe, a interface e a marca, informa da ruta que o núcleo elixiría sen que saia ningún paquete. Fornecer unha marca na consulta non demostra que o cortafogos marque tráfico real; iso é unha comprobación aparte das regras de marcado. Confirme o valor cun contador ou un rexistro antes de sacar conclusións da consulta.

As solicitudes xeradas localmente necesitan o seu propio contexto, porque o seu camiño de marcado adoita diferir do do tráfico reenviado. Compróbeas coa interface de saída que a aplicación usaría realmente.

Dous estados de fallo, non un

Un estado de fallo é que a ruta VPN desapareza e o tráfico caia ao enlace ascendente. Un túnel morto cuxa ruta permanece instalada é outro: os paquetes seguen dirixidos a un camiño inutilizábel en lugar de caer, e o síntoma é unha perda silenciosa en lugar dunha conexión directa visíbel. Probe ambos, e tamén o comportamento no arranque, na reconexión e na parada do servizo.

Unha regra así só axuda mentres existe e mentres os paquetes aínda levan a marca que a selecciona. Un script de apagado que elimine a regra, ou un camiño que quite a marca, restaura o comportamento aberto. Paga a pena ensaiar esas transicións.

Aplique a política a IPv6 por separado e manteña explícitas, en lugar de implícitas, as excepcións de punto final aprobadas.