Unha soa URL para a oficina e a VPN? Por que falla o mito da lista de permitidos

Conecte o túnel, abra o mesmo marcador e o sitio permitido responde exactamente como o facía desde a oficina. Esa é a suposición sobre a que descansan en silencio a maioría dos plans de acceso remoto, e só se sostén mentres tres cousas separadas seguen sendo certas á vez. Ningunha delas é unha función do cliente VPN, e ningún rexistro DNS pode fornecer ningunha. Cando o marcador falla na casa, o navegador dálle un erro xenérico, xa sexa a causa unha ruta ausente, un enderezo de saída non aprobado ou un proxy que substituíu a orixe que informa. Tratar esas tres como un só problema é como unha pequena corrección de política se converte nunha semana de ampliar listas de permitidos.

O deseño que sobrevive ao contacto cunha rede de oficina real é máis estreito que a suposición: unha táboa de decisión explícita de tres filas, un punto de aplicación que non se pode evitar e unha proba de denegación que demostra algo. Desmontar a suposición vai primeiro, porque todo o que segue depende de saber que capa representa mal a orixe.

O mito: conectar non é encamiñar

Establécese un túnel e o cliente instala rutas para certo conxunto de prefixos. Iso é todo o que fai conectar. Se unha petición HTTPS allea viaxa polo túnel, e de que enderezo público parece vir ao chegar, son decisións que toman despois outros compoñentes: a táboa de rutas elixe o camiño e a saída elixe a orixe.

Por iso a oficina e a mesa da cociña diverxen co mesmo portátil, o mesmo perfil de navegador e o mesmo marcador. Na oficina a petición sae por un enderezo público mantido co que o operador do sitio aceptou. Por un túnel completo pode saír pola saída VPN, que é outro enderezo e, ata que alguén o engada, non aprobado. Por un túnel dividido pode que nunca entre no túnel. Só dous deses tres camiños formaron parte algunha vez do acordo co propietario do sitio, e o terceiro non é un defecto que haxa que parchear cunha entrada allow extra.

Tres estados de petición, dúas saídas aprobadas

Escriba a matriz antes de tocar unha devasa, porque a táboa é o deseño e a regra só unha implementación súa. Os enderezos de abaixo son rangos de documentación; substitúxaos polos seus propios valores mantidos e gárdeos onde o propietario do sitio poida auditalos.

A fila central é onde se rompen a maioría destes plans. O que conta é o enderezo que observa o dispositivo de aplicación, non o enderezo privado que o portátil ten dentro do túnel nin o seu enderezo LAN. Un valor como 10.8.0.6 non significa nada para un sitio público, e 192.168.1.44 tampouco. O enderezo do túnel é un detalle de direccionamento do túnel, non unha credencial que o sitio poida comprobar.

Se a súa VPN non pode ofrecer unha saída estable e documentada, a matriz non ten fila central válida e ningunha cantidade de listas de permitidos inventará unha. As opcións honestas nese punto son un sitio privado alcanzado por rutas privadas explícitas ou unha pasarela de acceso consciente da identidade diante da aplicación. Ambas teñen un contrato distinto do dunha lista pública de permitidos, e ambas son máis fáciles de explicar a un auditor que unha lista que medrou ata que ocorreu funcionar.

Lea a orixe onde se toma a decisión

Ponxa a restrición no dispositivo que remata a petición e confirme que ningún camiño de orixe alternativo a salta. O módulo de acceso de Nginx avalía as directivas allow e deny por orde, gaña a primeira coincidencia, e as regras herdadas dun bloque envolvente seguen aplicándose dentro de location. Un allow estreito xunto a un allow amplo no mesmo sitio adoita significar que decide o amplo. Lea toda a configuración efectiva dese location antes de editar unha soa das súas liñas.

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;
    }
}

Detrás dun balanceador de carga ou dun proxy inverso, esa regra ve o proxy salvo que lle diga o contrario. Restaure o enderezo do chamante só mediante o mecanismo de proxy de confianza admitido, cunha lista explícita de enderezos de proxy. Unha cabeceira de petición que afirma un enderezo aprobado non é proba de que o chamante o posúa, e nun oínte público unha cabeceira reenviada sen validar converte a lista de permitidos en adorno.

Logo revise a outra familia de enderezos. Un conxunto de regras que só cobre IPv4 é unha decisión incompleta para un nome de host que tamén responde en AAAA, e un cliente con IPv6 operativo chegará á mesma aplicación por un camiño que vostede nunca revisou.

Túnel dividido: a petición que nunca entra

Un túnel dividido só transporta os prefixos da súa lista. As subredes internas da oficina adoitan estar nesa lista; un sitio web público non. O navegador resolve o nome, compara o enderezo elixido coa táboa de rutas e aínda así atopa a pasarela local por defecto diante.

Así a petición chega desde a conexión doméstica do usuario, rexéitase, e o informe di que a VPN está rota mentres o túnel fai exactamente aquilo para o que se configurou. Hai dúas correccións lexítimas: encamiñe ese destino polo túnel e deixe que a saída aprobada o transporte, ou acepte que o sitio se alcanza directamente e dea aos usuarios remotos outra ruta aprobada, como a pasarela de acceso. Ampliar a lista pública de permitidos do sitio ata que por casualidade se inclúa un enderezo doméstico non é ningunha das dúas, e elimina a fronteira que o deseño debía impoñer. As dúas primeiras manteñen a matriz honesta; a terceira borra en silencio unha fila.

Demostre a denegación e logo a recuperación

Probe cunha petición que exerza a decisión real, desde un cliente situado en cada fila da táboa. Unha comprobación de accesibilidade contra algunha páxina allea que informe do enderezo non demostra nada, porque ese destino pode seguir un camiño distinto do da aplicación.

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/'

Compare o rexistro de acceso da fronteira co que a táboa predixo. Logo baixe o túnel e faga unha petición nova que debería ser rexeitada; unha páxina xa cargada ou unha conexión xa aberta non proba absolutamente nada. Se non aparece ningunha denegación, o punto de aplicación non está onde vostede cre.

Manteña a autenticación da aplicación tras a admisión na rede, porque unha saída de oficina e unha saída VPN representan cada unha moitas persoas e ningunha identifica a un individuo. A instrución para os usuarios segue sendo curta: levante o túnel aprobado e volva tentalo. Iso é o que mantén unha URL cómoda mentres a regra de orixe segue a ser unha decisión e non unha conxectura.