Un sol URL per a l’oficina i la VPN? Per què falla el mite de la llista d’autoritzats

Connecteu el túnel, obriu el mateix marcador i el lloc autoritzat respon exactament com ho feia des de l’oficina. Aquesta és la suposició sobre la qual descansen en silenci la majoria de plans d’accés remot, i només es manté mentre tres coses separades segueixen sent certes alhora. Cap d’elles no és una funció del client VPN, i cap registre DNS no en pot proporcionar cap. Quan el marcador falla a casa, el navegador us dóna un error genèric, tant si la causa és una ruta absent, una adreça de sortida no aprovada com un proxy que ha substituït l’origen que informa. Tractar aquestes tres com un sol problema és com una petita correcció de política es converteix en una setmana d’ampliar llistes d’autoritzats.

El disseny que sobreviu al contacte amb una xarxa d’oficina real és més estret que la suposició: una taula de decisió explícita de tres files, un punt d’aplicació que no es pot evitar i una prova de denegació que demostra alguna cosa. Desmuntar la suposició va primer, perquè tot el que ve després depèn de saber quina capa representa malament l’origen.

El mite: connectar no és encaminar

S’estableix un túnel i el client instal·la rutes per a un conjunt de prefixos. Això és tot el que fa connectar. Si una petició HTTPS no relacionada viatja pel túnel, i de quina adreça pública sembla venir quan arriba, són decisions que prenen després altres components: la taula d’encaminament tria el camí i la sortida tria l’origen.

Per això l’oficina i la taula de la cuina divergeixen amb el mateix portàtil, el mateix perfil de navegador i el mateix marcador. A l’oficina la petició surt per una adreça pública mantinguda amb què l’operador del lloc ha acceptat. Per un túnel complet pot sortir per la sortida VPN, que és una adreça diferent i, fins que algú l’afegeixi, no aprovada. Per un túnel dividit potser no entra mai al túnel. Només dos d’aquests tres camins van formar mai part de l’acord amb el propietari del lloc, i el tercer no és cap defecte que s’hagi de pedaçar amb una entrada allow extra.

Tres estats de petició, dues sortides aprovades

Escriviu la matriu abans de tocar cap tallafoc, perquè la taula és el disseny i la regla només n’és una implementació. Les adreces de sota són rangs de documentació; substituïu-les pels vostres valors mantinguts i guardeu-les on el propietari del lloc les pugui auditar.

La fila del mig és on es trenquen la majoria d’aquests plans. El que compta és l’adreça que observa el dispositiu d’aplicació, no l’adreça privada que el portàtil té dins del túnel ni la seva adreça LAN. Un valor com 10.8.0.6 no significa res per a un lloc públic, i 192.168.1.44 tampoc. L’adreça del túnel és un detall d’adreçament del túnel, no una credencial que el lloc pugui comprovar.

Si la vostra VPN no pot oferir una sortida estable i documentada, la matriu no té cap fila del mig vàlida i cap quantitat de llistes d’autoritzats no n’inventarà una. Les opcions honestes en aquest punt són un lloc privat abastat per rutes privades explícites o una passarel·la d’accés conscient de la identitat davant de l’aplicació. Totes dues tenen un contracte diferent del d’una llista pública d’autoritzats, i totes dues són més fàcils d’explicar a un auditor que una llista que va créixer fins que va passar a funcionar.

Llegiu l’origen on es pren la decisió

Poseu la restricció al dispositiu que acaba la petició i confirmeu que cap camí d’origen alternatiu no la salta. El Mòdul d’accés de Nginx avalua les directives allow i deny per ordre, guanya la primera coincidència, i les regles heretades d’un bloc englobant encara s’apliquen dins del location. Un allow estret al costat d’un allow ampli al mateix lloc normalment vol dir que decideix l’ampli. Llegiu tota la configuració efectiva d’aquell location abans d’editar-ne una sola línia.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Darrere d’un balancejador de càrrega o d’un proxy invers, aquesta regla veu el proxy tret que li digueu el contrari. Restaureu l’adreça del sol·licitant només pel mecanisme de proxy de confiança admès, amb una llista explícita d’adreces de proxy. Una capçalera de petició que afirma una adreça aprovada no és prova que el sol·licitant la posseeixi, i en un oient públic una capçalera reenviada no validada converteix la llista d’autoritzats en decoració.

Després comproveu l’altra família d’adreces. Un conjunt de regles que només cobreix IPv4 és una decisió incompleta per a un nom d’amfitrió que també respon a AAAA, i un client amb IPv6 funcional arribarà a la mateixa aplicació per un camí que mai no heu revisat.

Túnel dividit: la petició que no entra mai

Un túnel dividit només porta els prefixos de la seva llista. Les subxarxes internes de l’oficina solen entrar en aquesta llista; un lloc web públic no. El navegador resol el nom, compara l’adreça triada amb la taula d’encaminament i tot i així troba la passarel·la local per defecte al davant.

Així la petició arriba des de la connexió de casa de l’usuari, és refusada, i l’informe diu que la VPN està espatllada mentre el túnel fa exactament allò per a què va ser configurat. Hi ha dues correccions legítimes: encamineu aquella destinació pel túnel i deixeu que la sortida aprovada la porti, o accepteu que el lloc s’assoleix directament i doneu als usuaris remots un altre camí aprovat, com la passarel·la d’accés. Ampliar la llista pública d’autoritzats del lloc fins que hi caigui per casualitat una adreça de casa no és cap de les dues, i elimina la frontera que el disseny havia de fer complir. Les dues primeres mantenen la matriu honesta; la tercera esborra en silenci una fila.

Demostreu la denegació, després la recuperació

Proveu amb una petició que exerceixi la decisió real, des d’un client situat a cada fila de la taula. Una comprovació d’abastabilitat contra una pàgina qualsevol que informi de l’adreça no demostra res, perquè aquella destinació pot seguir un camí diferent del de l’aplicació.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Compareu el registre d’accés de la frontera amb el que la taula havia predit. Després baixeu el túnel i feu una petició nova que hauria de ser refusada; una pàgina ja carregada, o una connexió ja oberta, no prova res de res. Si no apareix cap denegació, el punt d’aplicació no és on creieu.

Manteniu l’autenticació de l’aplicació després de l’admissió a la xarxa, perquè una sortida d’oficina i una sortida VPN representen cadascuna moltes persones i cap no identifica un individu. La instrucció per als usuaris segueix sent curta: poseu el túnel aprovat, després torneu-ho a provar. Això és el que manté un sol URL convenient mentre la regla d’origen continua sent una decisió i no una endevinalla.