Publicación de portos de Docker e orixes VPN: dúas coincidencias que se perden

A regra di permitir o enderezo do servidor VPN cara ao servizo publicado, e aínda así a conexión cae. Ese resultado é habitual e non é un fallo de Docker. Dúas coincidencias separadas están mal: a orixe que escribiches pode non ser a orixe que recibe o host, e o porto que escribiches pode non ser o porto que ve o filtro. Corrixir ambas as dúas esixe mirar a ruta do paquete en lugar do diagrama do servizo.

O mito: permite o servidor VPN e xa está

Unha VPN encamiñada pode conservar o enderezo do túnel do cliente ata o host de Docker. Unha pasarela que fai tradución de orixe pode substituír ese enderezo polo seu. Ambos os deseños son lexítimos e producen orixes distintas para a mesma acción do usuario.

Así que a frase IP do servidor VPN describe unha suposición, non unha observación. Ata que saibas cal dos dous deseños tes diante, a regra é unha conxectura.

Orixe: grupo de clientes ou pasarela traducida

Comproba catro cousas en orde. Primeira, o grupo de enderezos de clientes, por exemplo 10.90.0.0/24. Segunda, se a pasarela traduce ese grupo antes de que chegue ao host. Terceira, a orixe que o host observa realmente para unha conexión nova. Cuarta, se a autenticación da aplicación distingue usuarios individuais, porque un enderezo traducido compartido non pode.

Se o grupo se conserva, unha regra que só coincide co enderezo público da pasarela deixa fóra todos os clientes. Se a pasarela traduce a propósito, permitir o enderezo traducido admite todos os usuarios que hai detrás, o que pode ser aceptable para un servizo co seu propio inicio de sesión e inaceptable para calquera outra cousa.

Porto: o DNAT cambia o número que coincide

Na publicación habitual con ponte de Linux e iptables de Docker, unha asignación do host de 8443 ao porto 443 do contedor tradúcese antes de que se execute o filtro de reenvío. O paquete chega ao filtro con porto de destino 443. Unha regra que coincide con 8443 nese punto nunca se activa, aínda que 8443 é o que escribiu o cliente.

O porto publicado segue existindo no seguimento de conexións, por iso o destino orixinal se pode facer coincidir alí cando de verdade o necesitas.

Decide que número expresa a intención. Coincide co porto do contedor posterior ao DNAT cando a regra protexe o servizo dentro do contedor. Coincide co destino orixinal coa opción conntrack cando a regra debe describir que pediu o cliente, e acepta o custo extra de coincidencia e o coidado coa orde das regras que iso conleva.

Cadea: DOCKER-USER, non INPUT

A guía de iptables de Docker sitúa a política de reenvío de usuario na cadea DOCKER-USER, que se avalía antes das regras de reenvío do propio Docker. Unha regra copiada dun servizo do host á cadea INPUT filtra o tráfico dirixido ao host, non o tráfico reenviado a un contedor. Ese erro produce unha regra que parece correcta e non ten efecto na ruta do contedor.

Mantén o rango de orixe, o porto de destino efectivo, o protocolo e a interface de entrada xuntos na mesma regra. Unha aceptación só por orixe para cada destino reenviado é máis ampla que permitir un só servizo publicado.

Verifica con conexións novas

Proba ambas as direccións con conexións novas: un cliente VPN permitido e unha orixe que debe seguir denegada. O estado de conexión existente pode manter viva unha sesión despois de cambiar a política, así que unha conexión antiga non demostra nada sobre a regra nova. Despois comproba a ruta de resposta, porque o contedor aínda ten que encamiñar de volta á orixe que ve.

A guía de iptables de Docker documenta a orde das cadeas e o comportamento de tradución de portos detrás destas comprobacións. Léaa antes de copiar unha receita e confirma que backend usa o Docker instalado, porque o backend nftables integra a política de forma distinta.