Com un proxy públic arriba a un origen privat a través d’una VPN

Publicar un lloc web a través d’un túnel i donar accés VPN als usuaris són dos arranjaments diferents que comparteixen un cable. En el primer, un proxy invers públic accepta la petició del visitant i la reenvia pel túnel fins a un origen que ningú pot assolir directament. En el segon, l’usuari ha d’unir-se a la VPN abans que l’aplicació sigui accessible. Barrejar les dues descripcions és com un backend privat acaba exposat públicament.

Dos models que semblen iguals en un diagrama

Dibuixeu les fletxes abans de triar res. Un model de publicació pública va del navegador al proxy per HTTPS, després del proxy a l’origen pel túnel, i l’origen mai accepta una connexió d’Internet. Un model només VPN va del client a la passarel·la, i l’aplicació només és accessible des de dins d’aquest camí. L’ordinador portàtil de l’usuari és a la mateixa xarxa que l’aplicació, i aquest és tot el sentit d’aquest model.

Els models difereixen en qui autentica i on. En el primer, el proxy és l’entrada pública i reenvia qualsevol petició que arribi, inclosa una d’hostil, subjecta a la política que s’hi hagi configurat. En el segon, l’accessibilitat mateixa és la porta, que és una admissió grollera però real.

On s’atura TLS i què demostra realment

TLS entre el navegador i el proxy protegeix aquest salt i permet al navegador verificar el lloc que volia visitar. Si el proxy acaba TLS, la petició existeix en forma llegible dins d’aquest procés abans de reenviar-se. Una segona sessió TLS fins a l’origen pot protegir el salt següent i verificar per separat el punt final de l’aplicació. Cap de les dues sessions decideix quina persona pot usar l’aplicació. Un certificat comodí al proxy tampoc no s’estén a aquest segon salt.

Aquesta és la part que la gent redueix a la paraula xifrat. La confidencialitat, la integritat i la identitat del servidor són propietats de transport; l’autorització és una decisió de l’aplicació. Una adreça privada darrere d’un túnel canvia qui pot arribar al sòcol, no qui pot iniciar sessió un cop hi arriba.

Confieu en les capçaleres reenviades només des del proxy

Les aplicacions que registren o autoritzen per l’adreça del client normalment llegeixen una capçalera que afegeix el proxy. Aquesta capçalera és només text, així que qualsevol cosa que pugui arribar directament a l’origen pot reclamar qualsevol adreça que vulgui. Restringiu l’origen perquè només l’adreça del túnel del proxy s’hi pugui connectar, i configureu l’aplicació perquè accepti la capçalera només des d’aquesta adreça.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Si aquesta petició té èxit des d’un amfitrió que no és el proxy, l’origen confia en una capçalera que hauria d’ignorar. Arregleu l’oient abans de tocar l’aplicació. Una denegació és un resultat molt millor que una línia de registre amb una adreça falsificada.

Mantingueu l’origen accessible des d’exactament un lloc

Lligueu l’oient de l’origen a l’adreça del túnel o tanqueu-lo amb un tallafoc cap al proxy, i després confirmeu què escolta realment. Un servei iniciat amb una vinculació comodí accepta connexions a totes les interfícies que té l’amfitrió, inclosa una que havíeu oblidat que era encaminable. La taula d’escolta és la veritat bàsica, no el fitxer de configuració que pensàveu aplicar. Si la vinculació comodí és intencionada, el tallafoc encara ha de ser el component que la restringeixi.

ss -ltnp | grep -E ':(80|443)'

Feu la mateixa revisió per a les interfícies de gestió, que són l’exposició accidental habitual. Després escriviu els dos models per separat: el lloc públic a través del proxy i la interfície d’administració accessible només pel túnel. La frase que el servidor és darrere d’una VPN no diu res de tot això.