Regras de entrada de SSH e VPN: que controla realmente a lista de permitidos

Conéctate unha vez antes de cambiar unha regra e anota se o cliente queda colgado ou é rexeitado de inmediato. Esa única diferenza diche que decisión descartou o paquete e aforra unha hora de ler ficheiros de políticas. O resto do percorrido é curto: o paquete atravesa un gancho, coincide cunha regra e chega a un oínte ou non. Unha lista de permitidos non é máis ca contabilidade arredor deses tres feitos.

Segue un intento de SSH ata o gancho de entrada

Un cliente envía un SYN ao enderezo do servidor no porto 22, e o núcleo decide se ese paquete é para un servizo local. Se o é, execútase a ruta de entrada e o conxunto de regras acepta o paquete ou descártao. O silencio significa que o SYN morreu antes de que o oínte o vise, mentres que un rexeitamento rápido significa que algo respondeu cun restablecemento. Son veredictos distintos de regras distintas, e ambos son resultados lexítimos.

Confirma despois o oínte, porque ningunha regra rescata un servizo que non está. Executa ss -ltnp e comproba que algo está ligado ao porto e á familia de enderezos que esperas, e despois le ssh -v no cliente para ver onde se detén.

O reenvío é unha decisión á parte

Nun servidor VPN o gancho máis interesante é forward, porque o tráfico do cliente encamiñase a través da máquina en lugar de entregarse a ela. Un servidor que só executa o seu propio cliente VPN necesita un conxunto de regras moito menor ca un que reenvía paquetes doutras persoas. Mesturar os dous deseños nunha soa máquina produce regras que parecen correctas e non deixan pasar nada.

Escribe a política interior como unha pregunta propia: que enderezos de cliente poden acadar que destinos a través do túnel. Mantén a ruta administrativa, como SSH, na ruta de entrada coa súa propia restrición de orixe. Unha regra forward permisiva engadida durante as probas é o defecto clásico que sobrevive á proba, así que revisa todo o conxunto de regras tras un cambio en lugar da liña que editaches. Abrir o oínte do túnel non é permiso para que cada cliente conectado administre o servidor.

Descartar e rexeitar son accións, non políticas

A política dunha cadea base acepta ou descarta, e esa é toda a lista de opcións, como di a referencia de nftables. O rexeitamento existe como acción de regra cunha resposta escollida, e por iso escribilo como política falla tanto en nftables coma en iptables. Na práctica, un drop non dálle ao cliente ningunha información, mentres que un reject dálle un erro co que pode traballar.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Le ese esquema como a forma dunha decisión e non como un ficheiro para pegar, xa que os rangos de enderezos son exemplos. Un reject explícito no porto SSH fai que un cliente non autorizado falla nun segundo en lugar de agardar un tempo de espera, o que acurta a túa propia depuración. O silencio disuade o escaneo casual e non lle di absolutamente nada a un usuario autorizado. Escolle por servizo e anota por que, porque doutro xeito a persoa seguinte cambiaráo de volta.

Conserva o tráfico de control que realmente necesitas

Bloquear todo o ICMP é un valor por defecto popular que rompe o descubrimento de MTU da ruta, e o síntoma é unha conexión que se establece e despois atasca con paquetes grandes. O descubrimento de veciños en IPv6 depende dos seus propios tipos de ICMPv6, e descartalos rompe a ligazón antes de que se consulte calquera regra TCP. Ambos pertencen á lista de permitidos como dependencias nomeadas e non como permisos xerais. Unha política que rompe o descubrimento en silencio é peor ca unha que admite algo de tráfico de diagnóstico.

Permite os estados established e related para as conexións que iniciaste, e deixa que o motor con estado se ocupe das respostas. Despois confirma que a ruta de resposta non está bloqueada máis fóra, porque unha restrición só de saída augas arriba produce o mesmo tempo de espera que estabas a punto de culpar ao servidor.

Demostra a recuperación antes de retirar a ruta antiga

Mantén aberta unha sesión de consola, aplica o cambio e abre unha conexión de xestión completamente nova desde outro terminal. Unha sesión existente non demostra nada, porque pode sobrevivir a unha regra que bloquea cada inicio de sesión novo, o que a converte no falso positivo máis convincente do traballo con devasas. Se un sistema de monitorización comproba o servidor, engade o seu enderezo de orixe antes do cambio e non despois da primeira alerta. Despois proba un paquete grande e un pequeno para demostrar que o descubrimento aínda funciona.

Para un servizo VPN, repite desde un cliente que nunca se conectou, porque unha sesión retomada pode reutilizar estado que unha nova debe negociar. Anota o conxunto exacto de regras que pasou, cunha suma de verificación ou unha copia, para que unha edición posterior se poida comparar en lugar de adiviñar. Coordínate con quen posúe a orde das regras, porque unha regra anterior gaña en silencio á que engadiches.