Il gateway ospita la propria pagina di amministrazione: indirizzo interno o pubblico

Una pagina di amministrazione risponde da un telefono in dati mobili e va in timeout da un portatile unito alla VPN. Nulla del tunnel è rotto, perché la richiesta non vi entra mai. Il nome host si risolve nell'indirizzo pubblico del gateway, e quell'indirizzo è raggiungibile solo dall'esterno del tunnel che termina. Sistemarlo significa dare al servizio un ingresso privato invece di spostare l'endpoint esterno.

La pagina si carica da fuori e non attraverso il tunnel

Si confrontano due richieste diverse. Dai dati mobili il browser raggiunge direttamente l'indirizzo pubblico. Dall'interno del tunnel lo stesso nome si risolve nello stesso indirizzo pubblico, e il pacchetto ora deve uscire attraverso il tunnel per raggiungere un indirizzo sul lato opposto del tunnel stesso. Stesso nome, stesso indirizzo, due posizioni molto diverse.

Una rotta di destinazione sceglie un indirizzo, non una porta. Nulla nella tabella di routing sa che la porta 443 è per l'amministrazione e la porta 1194 è il trasporto, quindi entrambe sono trattate come la stessa destinazione.

Ecco perché la pagina a volte funziona e a volte no, a seconda del nome e della rete usati dal client. È un problema di percorso e non un problema di autenticazione. Entrambi i client si autenticano perfettamente.

Mantieni raggiungibile l'endpoint esterno

I profili a tunnel completo hanno bisogno di una rotta di eccezione per l'endpoint VPN, e l'opzione redirect-gateway di OpenVPN documenta esattamente questo: l'endpoint remoto mantiene una rotta attraverso il gateway preesistente così il tunnel non instrada verso se stesso. Rimuovi quell'eccezione e il trasporto cifrato segue il tunnel, il che termina la sessione in un ciclo. Quell'eccezione è il motivo per cui l'indirizzo dell'endpoint resta raggiungibile dall'interno del tunnel.

La conseguenza è che l'indirizzo pubblico resta raggiungibile dal client, ed è anche per questo che una richiesta del browser a quell'indirizzo può seguire la stessa eccezione e uscire senza entrare nel tunnel. L'eccezione fa il suo lavoro, e il nome fa il danno.

Leggi la decisione di routing invece dell'elenco delle interfacce prima di cambiare qualcosa. I comandi sotto stampano la decisione invece dell'inventario. Eseguili dal client che ha fallito.

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

Se la ricerca mostra la rotta dell'endpoint attraverso il gateway fisico, il comportamento è corretto e la pagina di amministrazione viene semplicemente inviata sul percorso sbagliato. È il punto in cui la risoluzione dei nomi diventa la correzione.

Dai al servizio un nome privato

Il servizio ha bisogno di un nome che si risolva nell'indirizzo del gateway dentro il tunnel, mantenendo la semantica di certificato e di nome host che l'applicazione si aspetta. Un record di zona privato per il nome di amministrazione è la risposta abituale, e lascia intatto il nome del trasporto.

Non ripuntare il nome del trasporto all'indirizzo interno, perché il prossimo stabilimento del tunnel cercherebbe allora di raggiungere un indirizzo che esiste solo dentro un tunnel. Quell'errore produce una VPN che funziona esattamente una volta.

Controlla anche entrambe le famiglie di indirizzi, perché un record AAAA lasciato indietro può mandare il browser dove il piano privato non ha mai coperto.

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/

Adatta la politica a dove gira il processo

Un processo nativo in ascolto sul gateway è raggiunto dal percorso di ingresso locale, quindi la catena di ingresso e il binding del socket decidono se la richiesta è accettata. Le regole di inoltro e l'inoltro IP non fanno rispondere un ascoltatore locale. Consenti le sorgenti del tunnel nella politica di ingresso e conferma che il processo è legato a un indirizzo che il tunnel può raggiungere.

Un container pubblicato su una porta dell'host segue un percorso diverso, perché il pacchetto è tradotto in destinazione e inoltrato. Quella richiesta incontra la politica di inoltro dell'host e le regole proprie di Docker, ed è per questo che un ascoltatore nativo funzionante può convivere con un container che rifiuta la stessa porta.

L'ordine di avvio conta in entrambi i casi, perché un binding a un indirizzo che appare solo dopo che il tunnel sale fallisce in silenzio all'avvio.

Controlla l'accesso privato e un percorso pubblico negato

Fai una nuova richiesta con nome da un client autorizzato con i controlli di identità propri dell'applicazione intatti. Poi prova lo stesso servizio da fuori del tunnel e conferma che non risponde. Un nome privato è una comodità e non una restrizione, e un ascoltatore ancora legato all'indirizzo pubblico è ancora esposto. È quest'ultimo controllo che la maggior parte delle revisioni salta.

Leggi i binding e lo stato del filtro invece del nome host dato agli utenti. L'esposizione è una proprietà del socket e non del nome. Quella distinzione sopravvive a ogni cambio di 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/

Quando la richiesta interna restituisce la pagina e la richiesta esterna va in timeout, il servizio ha un percorso privato deliberato e il trasporto resta raggiungibile. Quando la richiesta esterna risponde ancora, l'ascoltatore o una voce di container pubblicata deve essere ristretta prima che qualcuno descriva il servizio come solo interno.