Host iptables só con VPN: nomee o dispositivo tun, non tun+

Escribir -o tun+ parece unha instrución precisa e en realidade é un comodín que abrangue cada túnel que ten o núcleo. Un segundo cliente VPN, unha ponte de contedores ou unha interface que deixou unha sesión caída satisfáeno todos, e o host entón permite tráfico que a política pretendía impedir. O procedemento de abaixo fixa un nome de dispositivo, ordena as excepcións para que o túnel poida formarse de verdade e déixalle unha vía de volta se as regras saen mal. Cada paso é o bastante curto para desfelo por separado.

Paso 1: anote as regras que ten agora

Antes de cambiar unha política predeterminada, garde o estado actual para que a reversión sexa un comando e non un recordo. iptables-save > /root/iptables.pre escribe cada táboa nun ficheiro que pode restaurar, e un segundo terminal cunha sesión root aberta non é paranoia cando a política que vai establecer corta a conexión que a transporta. Se traballa en remoto, programe tamén un flush como interruptor de home morto.

Despois liste as interfaces, porque un nome que supuxo é un nome que debería ter lido: ip -br link mostra o que existe agora mesmo, e o túnel non aparecerá ata que estea levantado. Apunte os nomes dos dispositivos a medida que os le.

Paso 2: déalle ao túnel o seu propio nome

OpenVPN acepta dev tun_work na configuración do cliente, e entón Linux crea unha interface exactamente con ese nome en lugar de asignar tun0. O nome mantense estable entre reconexións mentres nada máis o reclame, e iso é o que fai significativa unha regra que nomea o dispositivo.

Onde o nome non se pode controlar, faga coincidir o enderezo do túnel ou unha marca de paquete. Ambas funcionan, ambas son máis difíciles de ler e ambas fallan máis en silencio cando o túnel cambia a numeración. En calquera caso, faga coincidir unha soa cousa e sexa explícito sobre cal.

Paso 3: escriba a política coa excepción do endpoint primeiro

Un host só con VPN é un host de denegación predeterminada cunha lista curta de excepcións, e a excepción que máis importa é a que permite que o túnel exista. Constrúaa nesta orde, coa regra do endpoint antes da regra do dispositivo do túnel, para que o handshake teña onde ir:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

O enderezo e o port literais do endpoint son do seu provedor, non desta páxina. Se o endpoint é un nome de host, resólvao unha vez e fixe o resultado, porque unha regra non pode consultar un nome e unha resposta que rota romperá a política en silencio tras o seguinte cambio de DNS. Comprobe tamén o port, porque os provedores que o pasan a TCP 443 necesitarán se non unha regra que ninguén escribiu. Un túnel que só funciona cun protocolo adoita ser esta omisión e non un fallo da devasa.

Nun router a mesma forma vai á cadea FORWARD para os clientes que hai detrás, e o tráfico propio do router necesita as súas propias regras. Un conxunto de regras que só cobre paquetes reenviados deixa SSH e DNS polo camiño antigo, e así é como un router se volve inalcanzable no momento en que o túnel sobe.

Paso 4: comprobe a orde, non só a presenza

As regras avalíanse en secuencia, así que un ACCEPT que chega antes simplemente oculta o REJECT que engadiu despois. A coincidencia established e related é a que deixa volver as respostas ás súas propias peticións de saída sen abrir un camiño de entrada xeral, e colocala despois da aceptación do túnel significa que un túnel caído aínda deixa pasar tráfico de volta pola súa propia interface.

Manteña o número de regras o bastante pequeno para lelo nunha pantalla. Un conxunto de regras que non pode auditar é un que parcheará engadindo excepcións arriba, e así é como as políticas de denegación predeterminada adquiren aos poucos un bordo de permiso predeterminado. Conte os ACCEPT antes e despois do cambio.

Paso 5: faga que sobreviva ao arranque e á familia de enderezos

As regras introducidas a man desaparecen ao reiniciar, así que cárgueas desde o servizo de devasa da distribución ou desde unha unidade que se executa despois de que exista a interface do túnel. Referenciar tun_work nun script que se executa antes de que arrinque OpenVPN é unha forma habitual de producir un bucle de arranque de tráfico descartado.

Despois comprobe IPv6 por separado, porque unha boa política de denegación predeterminada para IPv4 non di nada sobre a outra familia. ip -6 route diralle se o host ten unha ruta que puidese levar tráfico arredor dun túnel que só xestiona IPv4, e ip6tables ou nftables necesita as súas propias regras equivalentes. Probe cun destino IPv6-only en lugar de confiar na simetría do conxunto de regras.

Paso 6: verifique e estea listo para restaurar

Levante o túnel, confirme que o servizo previsto funciona e despois probe algo que a política debería rexeitar. Restaure con iptables-restore < /root/iptables.pre se a resposta o sorprende, e só entón comece a editar regras. A persistencia máis unha vía de restauración probada é o que fai disto un cambio que pode facer dúas veces.