Devasa do VPS: abra só o porto VPN e despois demóstroo

Unha devasa que só admite o porto VPN non é unha regra. Son tres decisións separadas que casualmente afectan o mesmo número de porto: a cadea de entrada decide que pode chegar a un proceso local, a cadea de reenvío decide que pode atravesar o anfitrión en nome dos clientes do túnel, e a táboa NAT reescribe o enderezo de orixe á saída. Equivoque unha delas e o resultado raramente é unha caída limpa. Obtén un anfitrión que acepta clientes pero non carga nada, ou un anfitrión que parece pechado ata que alguén le a orde das cadeas.

O único porto que non se pode pechar

O oínte da VPN debe aceptar conexións desde enderezos que non pode predicir, así que é un servizo público por definición. Esa é a única excepción sobre a que se constrúe o deseño: un porto UDP para OpenVPN, un porto UDP para WireGuard, un porto TCP para unha VPN SSL. Todo o demais pertence detrás do túnel, o que significa que os servizos de aplicación deben ligarse ao enderezo do túnel ou a loopback, non a todas as interfaces.

Ligar, con todo, non é aplicar. Un proceso ligado a 0.0.0.0 só é alcanzable se unha regra o admite, e a política por defecto é o recurso para o tráfico que non coincidiu con ningunha regra, non a regra que goberna o porto. Unha admisión colocada por riba da súa denegación segue sendo unha admisión, e mover un servizo fóra do enderezo público é unha mellora independente, non un substituto da cadea.

Entrada, reenvío e NAT responden preguntas distintas

O tráfico de entrada vai destinado ao propio anfitrión, así que alí viven o oínte da VPN e o camiño administrativo. O tráfico de reenvío atravesa o anfitrión, e os clientes do túnel necesítano ademais de net.ipv4.ip_forward=1. A configuración clásica medio rota permite o fluxo de saída e esquece a dirección de volta, así que o cliente completa a súa negociación e despois non se carga nada; unha regra de conntrack para tráfico establecido e relacionado cobre esa dirección.

NAT é a terceira pregunta. Sen unha reescritura en postrouting, os paquetes reenviados saen coa orixe privada do túnel e descártanse máis arriba, porque ningunha rede máis alá do anfitrión sabe encamiñar o grupo de volta. O prefixo de orixe desa regra debe coincidir co grupo da VPN, non co enderezo propio do anfitrión, e o mesmo vale para a regra de reenvío que nomea a subrede dos clientes.

IPv6 é unha segunda política, non unha idea posterior. Un anfitrión cunha cadea IPv4 estrita e unha política aberta en ip6tables non pechou nada; os servizos seguen sendo alcanzables pola outra familia. Ou reflicte o conxunto de regras con ip6tables ou desactive IPv6 a propósito na interface pública, e anote cal escolleu.

Unha base que se le nunha pasada

Empece pola denegación e logo engada só o que o anfitrión necesita. Primeiro loopback e as respostas, despois o camiño administrativo, despois o oínte do túnel, despois a política de reenvío para os clientes:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Os nomes de interface, o porto e o grupo son marcadores de posición; léaos do servidor en lugar de copialos. Gardar o resultado importa tanto como escribilo, porque un conxunto de regras que vive só en memoria desaparece no seguinte reinicio e reabre o anfitrión sen facer ruído. Fágao persistente co mecanismo da distribución e garde unha copia fóra da máquina para o día en que a máquina non arrinque.

Pechar o último porto sen perder o anfitrión

Hai unha trampa no deseño. Se SSH só existe a través do túnel, un servizo VPN fallido leva SSH consigo, e a única forma de volver pode ser unha consola que nunca abriu. Antes de pechar o último porto público, confirme que esa consola existe e que realmente pode usala, ou manteña un camiño administrativo estreito que non dependa do túnel: SSH desde un enderezo fixo, só chaves, autenticación por contrasinal desactivada.

Aplique o cambio desde unha sesión xa establecida, non a través da conexión que está a piques de filtrar. Programe unha reversión para que un erro caduque en lugar de facerse permanente, por exemplo unha tarefa systemd-run --on-active=10min que restaura o conxunto de regras anterior, e manteña aberta unha segunda sesión SSH mentres proba a primeira. Logo verifique que a tarefa de reversión se executa de verdade, porque unha recuperación non probada é o mesmo que ningunha recuperación.

Verifique o camiño, non o script

Lea as regras cargadas, non o ficheiro que se supuña que as cargaba. Desde un anfitrión externo autorizado, confirme que só responden os portos previstos; desde dentro do túnel, confirme que os servizos que quería publicar son alcanzables. Unha política de denegación por defecto que tamén bloquea o tráfico do túnel parece idéntica a un peche que funciona ata que alguén intenta usalo.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Anote o porto permitido, o grupo de clientes, a interface do túnel, a orixe administrativa e o procedemento de consola xunto á configuración. O seguinte cambio no grupo ou no nome da interface debe reflectirse tanto no filtro como na regra NAT, ou o anfitrión volve a un estado medio aberto sen que ninguén o note.

Un hábito vale máis que o conxunto de regras: despois de cada cambio, demostre o camiño de reenvío cunha petición de cliente e o camiño de recuperación cunha segunda sesión. Un peche que non usou é unha hipótese.