Bloquea un rango de destino para cada pool de clientes VPN

Unha regra pode manter un pool VPN admitido lonxe dun rango de destino sen alterar nada máis do que fai a pasarela. A regra en si é curta; as partes que deciden se funciona son o hook no que vive e a súa posición na cadea. Errar nesas dúas produce un cortalumes que parece correcto e compórtase de forma inconsistente. Comeza polo que fai o paquete cando a regra o ve.

Que compara realmente a regra

A regra compara tres cousas á vez: unha interface de entrada, un prefixo de orixe e un prefixo de destino. As tres deben ser certas antes de que se aplique o drop, e iso é o que a mantén estreita. Leela como unha soa expresión é máis doado que lela como tres políticas separadas.

A coincidencia de interface é o que distingue o tráfico reenviado dos clientes das conexións propias da pasarela. Sen ela, unha regra que só nomease o pool de orixe tamén afectaría paquetes que a propia pasarela xera desde ese enderezo, se algunha vez o fai. O prefixo de orixe limita a política aos clientes admitidos, e o prefixo de destino limítaa a un só rango. Le a regra como unha intersección e non como unha lista.

Anota os tres valores antes de editar nada: o nome da interface do túnel, o pool que reparte o servidor e o prefixo que pretendes denegar. Unha errata en calquera deles produce unha regra que se analiza limpiamente e non protexe nada. Garda eses tres valores no rexistro de cambios xunto á regra.

O hook decide a quen se aplica a regra

Unha cadea de netfilter enganchase a un hook, e o hook decide que paquetes chega a ver a cadea. O hook forward ve o tráfico encamiñado a través da pasarela, que é xusto o tráfico de cliente a destino. Todo o demais da cadea apunta a outro público.

O hook input ve o tráfico dirixido á propia pasarela, así que unha regra colocada alí goberna o acceso aos seus propios servizos e non o tránsito. O hook output ve o tráfico que orixina a pasarela, que é o contrario do que necesita unha política de pool de clientes. Os nomes de cadea son etiquetas arbitrarias escollidas por quen escribiu o conxunto de regras, así que non deduzas o hook do nome. Comproba onde se engancha a cadea antes de supor que pode comparar.

Ler o enganche é unha comprobación dunha liña que impide que unha regra acabe nunha cadea que nunca ve o paquete.

Coloca a regra antes da aceptación ampla

As regras avalíanse en orde e o primeiro veredicto gaña. Unha aceptación ampla anterior na cadea remata a avaliación dos paquetes que coincide, así que un drop engadido despois nunca se executa para eles. Esa regra de orde é toda a razón pola que unha regra de aspecto correcto pode non ter efecto.

Insire a regra antes da aceptación en lugar de engadila ao final. Se a cadea xa contén unha aceptación xeral para a interface do túnel, a nova regra debe precedela ou é decorativa. Comproba a orde resultante e non o ficheiro que editaches, porque un conxunto de regras montado a partir de varios ficheiros pode non coincidir con ningún deles. Despois confírmao cun paquete de proba do pool.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

O terceiro comando analiza o ficheiro sen aplicalo, o que detecta erros de sintaxe antes de que se convertan nunha caída. Aplícao cun plan de reversión, porque unha regra equivocada nunha cadea forward pode cortar o túnel polo que traballas.

Os fluxos existentes non fan caso da túa regra nova

Unha entrada de conntrack creada antes de que existise a regra segue coincidindo coa aceptación anterior. Por iso un drop novo ás veces parece funcionar para conexións novas e non facer nada pola que se está probando.

Le a coincidencia de estado na parte superior da cadea. Se acepta tráfico established e related antes da túa regra, cada fluxo xa en curso segue fluíndo ata que se pecha. Normalmente ese é o comportamento que queres para unha regra de emerxencia, e resulta confuso cando esperas un corte inmediato. Decide que efecto queres antes de despregar. Unha proba que reutilice unha conexión aberta contarache unha historia equivocada.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

O primeiro comando mostra se existe un fluxo, e o segundo mostra se unha regra de estado temperá segue aceptándoo. Ambos son de só lectura e seguros durante un incidente.

Que non é esta regra

A regra non é unha lista negra de dominios, unha política IPv6 nin unha restrición sobre unha conta de aplicación concreta.

Cada unha desas cousas necesita o seu propio mecanismo. Un bloqueo de dominio ten que resolver nomes, algo que un filtro de paquetes non fai. O tráfico IPv6 necesita a súa propia coincidencia, porque unha expresión ip non di nada sobre paquetes ip6. Unha restrición a nivel de aplicación pertence ao servizo ou a un proxy autenticado, non a unha coincidencia de prefixo. Manter separados eses requisitos é o que evita pedirlle a unha regra estreita que faga catro traballos.

O contrato que entrega esta regra é preciso: denégase o tráfico dun pool admitido cara a un prefixo de destino, mentres que o tráfico non relacionado da pasarela conserva a súa política existente. Escribe esa frase xunto á regra, e a seguinte persoa saberá para que servía.