Cortafuegos na nube fronte ao cortafuegos do hóspede para un servidor VPN

Permita o porto VPN na política da nube e o apretón de mans aínda pode morrer na instancia: o hóspede executa o seu propio filtro e a súa propia vinculación de oínte, e calquera dos dous pode descartar o que a nube aprobou. Tamén ocorre o contrario, cando unha regra do servidor permite o porto e unha política superior o descarta antes. Dous propietarios, dous conxuntos de regras, unha soa ruta de paquetes. Percórraa en orde en lugar de adiviñar na capa máis sospeitosa.

Comece pola beira e avance cara a dentro

A orde é fixa: punto final público, interface do recurso, política da nube asociada, enderezo do hóspede, oínte do proceso e regras locais de entrada. Cada etapa deixa pasar o paquete ou remata a investigación, e por iso comezar polo hóspede é o que máis tempo fai perder.

O tráfico de cliente reenviado é unha etapa aparte, que se inspecciona despois de desencapsular o túnel. A capa da nube só ve o túnel exterior, así que pode aprobar unha conexión e non ter nada que ver cunha petición de servizo interna. Un túnel que conecta pero non chega a un equipo interno adoita apuntar ao reenvío, non a un porto pechado.

Lea a política da nube antes de tocar o hóspede

Confirme a regra de entrada do porto VPN, o seu protocolo e o ámbito de orixe que coincide co seu cliente de proba. Revise tamén a lista de control de acceso da subrede: un segundo filtro coas súas propias regras e valores por defecto. Ambos deben permitir o fluxo antes de que un paquete chegue á instancia. Un permiso nun e unha denegación no outro é a forma habitual deste fallo.

Estreite o ámbito ata que signifique algo. Abrir o porto VPN a todo internet é fácil de demostrar e difícil de defender, mentres que unha regra fixada a un enderezo rompe cando o cliente de proba cambia de rede. Anote o identificador da regra e o propietario da política, para que o seguinte cambio sexa rastrexable ata unha persoa.

Confirme o oínte e despois a cadea de entrada

Na instancia, comprobe que o proceso VPN está vinculado ao enderezo e ao porto que espera, por exemplo con ss -lntp 'sport = :1194'. Un demo vinculado só a 127.0.0.1 acepta clientes locais e nada a través do túnel, o que desde fóra parece exactamente un porto filtrado.

Despois lea as regras locais coa sintaxe que usaría para cambialas, como iptables -S INPUT ou nft list chain inet filter input. Unha regra escrita nun ficheiro pero nunca cargada, ou un descarte por defecto sen ningún permiso que encaixe, descarta paquetes en silencio. Para unha pasarela que reenvía, revise tamén os axustes de reenvío e de ruta inversa. Deciden que ocorre cos paquetes encamiñados a través da instancia e non dirixidos a ela.

Con estado nunha capa, sen estado na seguinte

Os grupos de seguridade lembran os fluxos que permitiron e deixan volver as respostas. As listas de control de acceso de subrede e moitos cortafuegos do servidor non gardan ese estado, así que unha regra que só cobre a dirección de saída deixa pasar a petición e descarta a resposta. Nunca leve unha suposición sobre tráfico de retorno entre capas sen ler a regra da segunda capa (second layer's rule).

Os contadores resólveno máis rápido que ler cada regra da conta. Un contador que sobe significa que o paquete chegou e alí se descartou, mentres que un conxelado en cero significa que nunca chegou tan lonxe; iptables -vnL INPUT e nft list ruleset mostran esas contas cando as regras se cargaron con contadores.

Probe cunha sesión nova, non cunha viva

Deixe intactas a rede de orixe e o perfil de proba mentres compara vistas, e abra unha conexión nova despois de cada cambio. Chegar á consola web no 443 non di nada sobre se o demo VPN está vinculado ao 1194, así que probe o porto que necesita. Unha sesión existente é a peor testemuña aquí. Segue funcionando mentres se rexeita cada inicio de sesión novo.

Antes de editar unha política remota, asegure unha vía de volta que non dependa do camiño que está a cambiar. Despois abra unha segunda sesión de administración xunto á proba VPN: unha establecida antes pode sobrevivir á regra que bloquea as novas. Anote os dous propietarios das políticas para que ningunha reconstrución restaure medio camiño; se as dúas capas coinciden e o túnel segue fallando, capture na interface do hóspede e comprobe o enderezo e o porto que o cliente usa de verdade.