La passarel·la allotja la seva pròpia pàgina d'administració: adreça interna o pública

Una pàgina d'administració respon des d'un telèfon amb dades mòbils i expira des d'un portàtil connectat a la VPN. No hi ha res trencat al túnel, perquè la petició no hi entra mai. El nom d'amfitrió es resol a l'adreça pública de la passarel·la, i aquesta adreça només és abastable des de fora del túnel que ella acaba. Arreglar-ho vol dir donar al servei una entrada privada en lloc de moure el punt final exterior.

La pàgina es carrega des de fora i no a través del túnel

S'estan comparant dues peticions diferents. Amb dades mòbils, el navegador arriba directament a l'adreça pública. Des de dins del túnel, el mateix nom es resol a la mateixa adreça pública, i el paquet ara ha de sortir pel túnel per arribar a una adreça a la banda oposada del mateix túnel. Mateix nom, mateixa adreça, dues posicions molt diferents.

Una ruta de destinació tria una adreça, no un port. Res a la taula d'encaminament no sap que el port 443 és per a administració i el port 1194 és el transport, així que tots dos es tracten com la mateixa destinació.

És per això que la pàgina de vegades funciona i de vegades no, segons quin nom i quina xarxa va fer servir el client. És un problema de camí i no un problema d'autenticació. Tots dos clients s'autentiquen perfectament.

Manteniu el punt final exterior abastable

Els perfils de túnel complet necessiten una ruta d'excepció per al punt final de la VPN, i l'opció redirect-gateway d'OpenVPN documenta exactament això: el punt final remot conserva una ruta a través de la passarel·la preexistent perquè el túnel no encamini cap a si mateix. Traieu aquesta excepció i el transport xifrat segueix el túnel, cosa que acaba la sessió en un bucle. Aquesta excepció és la raó per la qual l'adreça del punt final continua essent abastable des de dins del túnel.

La conseqüència és que l'adreça pública continua essent abastable des del client, i per això una petició del navegador a aquesta adreça pot seguir la mateixa excepció i sortir sense entrar al túnel. L'excepció fa la seva feina, i el nom fa el mal.

Llegiu la decisió de la ruta i no la llista d'interfícies abans de canviar res. Les ordres de sota imprimeixen la decisió i no l'inventari. Executeu-les des del client que ha fallat.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Si la consulta mostra la ruta del punt final a través de la passarel·la física, el comportament és correcte i la pàgina d'administració simplement s'envia pel camí equivocat. Aquest és el punt on la resolució de noms es converteix en la solució.

Doneu al servei un nom privat

El servei necessita un nom que es resolgui a l'adreça de la passarel·la dins del túnel, tot mantenint la semàntica de certificat i de nom d'amfitrió que l'aplicació espera. Un registre de zona privat per al nom d'administració és la resposta habitual, i deixa el nom de transport intacte.

No reassigneu el nom de transport a l'adreça interna, perquè el proper establiment del túnel intentaria arribar a una adreça que només existeix dins d'un túnel. Aquest error produeix una VPN que funciona exactament una vegada.

Comproveu també les dues famílies d'adreces, ja que un registre AAAA que es queda enrere pot enviar el navegador enlloc que el pla privat no va cobrir mai.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Adapteu la política a on s'executa el procés

S'arriba a un procés natiu que escolta a la passarel·la pel camí d'entrada local, així que la cadena d'entrada i l'enllaç del sòcol decideixen si la petició s'accepta. Les regles de reenviament i el reenviament IP no fan que un oient local respongui. Permeteu les fonts del túnel a la política d'entrada i confirmeu que el procés està enllaçat a una adreça que el túnel pot assolir.

Un contenidor publicat en un port de l'amfitrió segueix un camí diferent, perquè el paquet es tradueix per destinació i es reenvia. Aquesta petició troba la política de reenviament de l'amfitrió i les regles pròpies de Docker, i per això un oient natiu que funciona pot conviure amb un contenidor que rebutja el mateix port.

L'ordre d'arrencada importa en tots dos casos, perquè un enllaç a una adreça que només apareix després que el túnel pugi falla en silenci a l'arrencada.

Comproveu l'accés privat i un camí públic denegat

Feu una petició nova i anomenada des d'un client autoritzat amb les comprovacions d'identitat pròpies de l'aplicació intactes. Després proveu el mateix servei des de fora del túnel i confirmeu que no respon. Un nom privat és una comoditat i no una restricció, i un oient encara enllaçat a l'adreça pública encara està exposat. Aquesta darrera comprovació és la que més revisions s'estalvien.

Llegiu els enllaços i l'estat del filtre i no el nom d'amfitrió que es va donar als usuaris. L'exposició és una propietat del sòcol i no del nom. Aquesta distinció sobreviu a cada canvi de DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Quan la petició interna retorna la pàgina i la petició externa expira, el servei té un camí privat deliberat i el transport continua essent abastable. Quan la petició externa encara respon, cal estrènyer l'oient o una entrada de contenidor publicada abans que algú descrigui el servei com a només intern.