ufw allow 443 non fixo nada por un servizo detrás da VPN

O ping funciona desde un cliente VPN, o servizo TCP caduca e ufw allow 443/tcp non cambia absolutamente nada. Cando a aplicación se executa nun servidor detrás da pasarela e non na pasarela mesma, ese permiso escribiuse para unha ruta de tráfico incorrecta. O paquete non está dirixido ao cortalumes e non se entrega a ningún proceso local, así que as regras de entrada nunca o ven. A corrección é unha regra de ruta dirixida ao fluxo reenviado, e a proba xa está no rexistro.

Decide se o destino é local ou reenviado

Le o paquete tal como o ve o núcleo. O tráfico entregado a un servizo na pasarela é entrada local. O tráfico que a pasarela encamiña cara a outro servidor é reenviado, e UFW mantén conxuntos de regras separados para as dúas rutas. A distinción decídena o enderezo de destino e a consulta de encamiñamento, non a interface pola que chegou o paquete.

Unha liña de rexistro que mostra a mesma interface nos campos IN e OUT pode describir igualmente un paquete encamiñado, porque un túnel que leva clientes dentro e fóra dun só dispositivo vese exactamente así. O enderezo de destino resolve a pregunta máis rápido que os nomes das interfaces. Ver o mesmo nome dúas veces non demostra unha entrega local, e inventar unha interface de túnel que o despregamento nunca creou tampouco axuda.

Le o bloque antes de engadir calquera regra

Reproduce un intento de conexión autorizado e captura a súa orixe, destino, protocolo e porto de destino tal como os rexistrou a pasarela. Compara eses catro valores coa entrada do rexistro e coa localización real do servizo. Un ping correcto anterior só demostra que o seu propio intercambio estaba permitido, e un cortalumes pode tratar un TCP SYN cara a unha aplicación de xeito moi distinto.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

O primeiro comando devolve o veredicto cos seus campos, e o segundo mostra o que xa está cargado e en que orde. Le ambos antes de editar nada, porque unha denegación anterior por riba da túa regra explica o mesmo síntoma sen que falte ningunha regra.

Escribe a regra de ruta máis estreita que encaixe

Neste exemplo, os clientes chegan por tun0 desde 172.20.8.0/24, o servizo escoita en 10.30.0.15 no porto 8443, e a pasarela sae por ens5. Eses valores escolléronse para non parecerse en nada a un valor predeterminado de VPC na nube de 10.0.0.0/16 nin a unha rede doméstica de 192.168.0.0/16, e 8443 mantén o exemplo lonxe do propio escoitador 443 da pasarela.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

A execución en seco imprime o conxunto de regras que resultaría, que é o xeito máis barato de ver se a túa regra cae antes ou despois dunha denegación existente. Confirma os nomes de interface e os enderezos internos contra o despregamento e non contra o exemplo, e lembra que cando a NAT de destino se executa primeiro, o filtro ve o destino traducido.

Mantén a ruta de retorno con estado

UFW rastrexa as conexións permitidas, así que as respostas a un fluxo reenviado permitido admítense sen unha regra inversa explícita. Engadir unha regra sen restricións na dirección oposta para que as cousas funcionen amplía a política moi máis aló do único servizo e non é necesario para un intercambio normal de petición e resposta. Mantén a ruta de retorno implícita e o conxunto de regras lexible.

Aplica a regra só cando a execución en seco coincida coa túa intención, e despois confirma que a lista ordenada a mostra na posición esperada. Conserva o escoitador da VPN e as regras de xestión como asuntos separados, xa que cambialos é unha decisión distinta de admitir unha aplicación. Anota o cambio onde está escrita a topoloxía, para que o seguinte enxeñeiro non teña que redescubrilo a partir dunha captura de paquetes.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Comproba o que UFW non pode aplicar por ti

Unha regra correcta segue necesitando o reenvío do núcleo e unha ruta que chegue ao servizo. Confirma ambas as dúas cousas antes de culpar o cortalumes por segunda vez.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Despois mira fóra do servidor. Nunha instancia na nube, a política de UFW do convidado non substitúe os grupos de seguridade, as ACL de subrede nin a configuración de reenvío do provedor, así que un bloqueo local é unha proba sobre unha capa e non a proba de que todas as demais capas permitan o servizo.

Remata probando unha conexión nova co cortalumes activo, desde unha fonte permitida e desde outra non relacionada. Desactivar UFW elimina o síntoma e destrúe a proba no mesmo comando, por iso debería ser o último experimento e non o primeiro.