Publicació de ports de Docker i orígens VPN: dues coincidències que es perden

La regla diu que permeteu l’adreça del servidor VPN cap al servei publicat, i tot i així la connexió cau. Aquest resultat és habitual i no és un error de Docker. Dues coincidències separades estan malament: l’origen que heu escrit pot no ser l’origen que rep l’amfitrió, i el port que heu escrit pot no ser el port que veu el filtre. Arreglar les dues coses exigeix mirar el camí del paquet en lloc del diagrama del servei.

El mite: permeteu el servidor VPN i ja està

Una VPN encaminada pot conservar l’adreça del túnel del client fins a l’amfitrió de Docker. Una passarel·la que fa traducció d’origen pot substituir aquesta adreça per la seva. Tots dos dissenys són legítims i produeixen orígens diferents per a la mateixa acció de l’usuari.

Per tant, la frase IP del servidor VPN descriu una suposició, no una observació. Fins que no sapigueu quin dels dos dissenys teniu al davant, la regla és una conjectura.

Origen: pool de clients o passarel·la traduïda

Comproveu quatre coses en ordre. Primera, el pool d’adreces de clients, per exemple 10.90.0.0/24. Segona, si la passarel·la tradueix aquest pool abans que arribi a l’amfitrió. Tercera, l’origen que l’amfitrió observa realment per a una connexió nova. Quarta, si l’autenticació de l’aplicació distingeix usuaris individuals, perquè una adreça traduïda compartida no pot fer-ho.

Si el pool es conserva, una regla que només coincideix amb l’adreça pública de la passarel·la deixa fora tots els clients. Si la passarel·la tradueix deliberadament, permetre l’adreça traduïda admet tots els usuaris que hi ha darrere, cosa que pot ser acceptable per a un servei amb el seu propi inici de sessió i inacceptable per a qualsevol altra cosa.

Port: el DNAT canvia el número que coincideixes

En la publicació habitual amb pont de Linux i iptables de Docker, una assignació de l’amfitrió de 8443 al port 443 del contenidor es tradueix abans que s’executi el filtre de reenviament. El paquet arriba al filtre amb port de destinació 443. Una regla que coincideix amb 8443 en aquell moment no s’activa mai, tot i que 8443 és el que va escriure el client.

El port publicat encara existeix en el seguiment de connexions, i per això la destinació original s’hi pot fer coincidir quan realment cal.

Decidiu quin número expressa la intenció. Coincidiu amb el port del contenidor posterior al DNAT quan la regla protegeix el servei dins del contenidor. Coincidiu amb la destinació original amb l’opció conntrack quan la regla ha de descriure què va demanar el client, i accepteu el cost extra de coincidència i la cura amb l’ordre de les regles que això comporta.

Cadena: DOCKER-USER, no INPUT

La guia d’iptables de Docker situa la política de reenviament d’usuari a la cadena DOCKER-USER, que s’avalua abans de les regles de reenviament del propi Docker. Una regla copiada d’un servei de l’amfitrió a la cadena INPUT filtra el trànsit adreçat a l’amfitrió, no el trànsit reenviat a un contenidor. Aquest error produeix una regla que sembla correcta i no té cap efecte en el camí del contenidor.

Manteniu el rang d’origen, el port de destinació efectiu, el protocol i la interfície d’entrada junts a la mateixa regla. Una acceptació només per origen per a cada destinació reenviada és més àmplia que permetre un sol servei publicat.

Verifiqueu amb connexions noves

Proveu les dues direccions amb connexions noves: un client VPN permès i un origen que ha de romandre denegat. L’estat de connexió existent pot mantenir viva una sessió després de canviar la política, així que una connexió antiga no demostra res sobre la regla nova. Després comproveu el camí de resposta, perquè el contenidor encara ha d’encaminar de tornada a l’origen que veu.

La guia d’iptables de Docker documenta l’ordre de les cadenes i el comportament de traducció de ports darrere d’aquestes comprovacions. Llegiu-la abans de copiar una recepta i confirmeu quin rerefons fa servir el Docker instal·lat, perquè el rerefons nftables integra la política de manera diferent.