Grupo de seguridade na nube para unha VPN: abra o oínte, non todo

O servidor VPN está a funcionar, o cliente esgota o tempo de espera e o primeiro impulso é engadir unha regra que permita todo ao grupo de seguridade. Ás veces iso fai que funcione, e é o peor resultado, porque agora ninguén sabe que fronteira se pechou de verdade. Catro filtros separados están entre o cliente e o daemon, e só un deles é o grupo de seguridade.

Nomea o protocolo antes ca regra

Unha regra é un protocolo, un rango de portos e unha orixe. WireGuard escoita en UDP, normalmente 51820. OpenVPN adoita ser UDP ou TCP 1194 segundo como se configurase. IPsec necesita o seu intercambio IKE en UDP 500 e 4500 ademais do propio protocolo ESP, que é un número de protocolo e non un porto. Supoñer TCP porque as outras regras son TCP é como se acaba cunha regra que parece correcta e non coincide con nada.

Le o oínte do servizo en execución, non dun titorial. Un daemon ligado a un enderezo non aceptará tráfico que chegue a outro.

Restrinxe a orixe ao rango de clientes que permite o deseño, en lugar de a todo internet.

Os grupos de seguridade teñen estado; as ACL de subrede non

Os grupos de seguridade teñen estado e só permiten: un fluxo entrante permitido recibe as súas respostas automaticamente, e non hai ningunha regra de denegación sobre a que razoar. As ACL de subrede non teñen estado e avalíanse en ambos sentidos, así que un permiso entrante sen o rango efémero de saída correspondente segue fallando. Esa diferenza explica moitas regras que parecen correctas na consola.

Confirma tamén que política está asociada ao punto final en execución, xa que unha instancia pode ter máis dun grupo e unha regra nun grupo non asociado non cambia nada.

A política efectiva é a unión do asociado, non o ficheiro que editaches.

A devasa do servidor é unha fronteira aparte

A política da nube admite o tráfico cara á interface de rede, e despois o sistema operativo decide se o daemon o ve. Unha devasa do servidor con política de denegación por defecto descartará un paquete que o grupo de seguridade permitiu, e a consola da nube non mostrará ningunha denegación porque nunca tivo opinión. Comproba ambos, na orde en que o paquete os atopa.

Se o servidor usa unha interface de devasa da distribución, confirma as regras subxacentes en lugar do nome do perfil, porque un perfil pode estar activo mentres o porto está pechado.

Unha captura na interface dinte que fronteira descartou o paquete.

Admitir o oínte non é encamiñar os clientes

Unha pasarela VPN que reenvía tráfico de clientes necesita máis ca un porto aberto. Necesita reenvío IP, unha política que permita o fluxo desde a interface do túnel á rede de destino e, a miúdo, a comprobación de orixe e destino desactivada na interface para que a plataforma non descarte tráfico que non vai dirixido a ela. Nada diso o crea a regra do oínte.

Aquí é onde se separan un handshake que funciona e un camiño de datos roto, e por iso o estado do túnel pode parecer san mentres non carga nada.

Corrixe o encamiñamento como un cambio aparte coa súa propia verificación, e ten en conta que unha pasarela que reenvía tamén necesita unha política de saída que permita o destino.

Mantén unha vía de retorno e despois estreita a regra

Antes de cambiar a política da devasa remota, confirma que existe unha vía de xestión independente, como un xestor de sesións, unha consola serie ou unha rede fóra de banda. Se a única vía de xestión pasa pola regra que estás editando, non tes recuperación. Despois aplica a regra estreita, proba desde un cliente real e correlaciona o intento con probas do lado do servidor. Unha resposta doutro servizo na mesma máquina non é proba de que se alcanzase o oínte.

Elimina calquera permiso amplo experimental en canto funcione o estreito, e anota por que existe a regra. AWS documenta o comportamento con estado dos grupos de seguridade, e ese é o documento que hai que citar cando alguén propón un rango amplo como atallo.

Documenta tamén a asociación, ou unha interface de substitución perderá a política en silencio.