pfSense come server e client VPN: due percorsi, un solo router

Un solo apparato può guardare in due direzioni insieme: gli utenti in mobilità si collegano verso l’interno, e la stessa scatola si collega verso l’esterno a un fornitore di uscita perché il traffico selezionato esca da un’altra rete. Abilitare entrambi i servizi richiede minuti; farli convivere richiede un progetto, perché il secondo ruolo riscrive la tabella di routing su cui il primo si appoggia. Tre condizioni decidono se la disposizione funziona, cioè se il servizio in ingresso conserva la propria rotta di ritorno, se il tunnel di uscita raggiunge ancora il suo pari e se il traffico che volevate inoltrare viene selezionato per l’uscita. Sbagliatene una e ottenete due tunnel che entrambi riportano connesso mentre nulla di utile passa tra loro. I controlli qui sotto stabiliscono ogni condizione nell’ordine in cui i guasti di solito compaiono.

Nominate i due ruoli prima di toccare un’impostazione

Annotate quattro fatti per ogni istanza: il suo pari remoto, il materiale di autenticazione, il pool di indirizzi che distribuisce e le reti dietro di esso. Le due istanze sono oggetti separati sull’apparato e devono restare separate anche nelle vostre note. Quasi ogni sintomo confuso successivo nasce dal mescolare i loro valori, e due istanze che condividono un solo insieme di note è il modo in cui il pool sbagliato finisce nel campo sbagliato.

Il servizio in ingresso ha bisogno di una rete di tunnel che non si sovrapponga agli indirizzi del tunnel di uscita né a nessuna rete privata che l’apparato instrada. La sovrapposizione è l’unico errore che produce sintomi in entrambi i ruoli insieme, ed è molto più economico coglierlo sulla carta. Confrontate entrambi i pool e ogni rete privata instradata in un solo posto prima di configurare uno dei due servizi.

L’hardware condiviso non implica credenziali condivise, e un certificato client del pool di accesso remoto non dovrebbe essere utilizzabile contro il fornitore di uscita. Il materiale separato trasforma anche la revoca in una decisione locale anziché in un evento per l’intera flotta.

Tenete le risposte del server sul percorso WAN

Le risposte che l’apparato genera da sé sono la prima vittima di una rotta predefinita trascurata. Quando arriva il pacchetto incapsulato di un utente in mobilità, la risposta è traffico di origine locale e deve uscire dall’interfaccia da cui quell’utente è entrato. Se il client di uscita ha installato una rotta predefinita che la cattura, la risposta entra nel tunnel sbagliato e la sessione si blocca mentre il servizio sembra ancora sano.

Non c’è una singola casella che lo risolva, perché la decisione riguarda quale traffico il client di uscita può catturare. O non tirate alcuna rotta e indirizzate solo ciò che selezionate, oppure tirate le rotte e aggiungete le eccezioni che mantengono in funzione i servizi propri dell’apparato. Scrivete la scelta accanto all’istanza, altrimenti la persona successiva presumerà l’altra.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Leggete la tabella di routing per la corrispondenza più lunga e non per l’ordine in cui avete configurato qualcosa. La domanda è quale voce vince per l’indirizzo del pari di uscita e quale voce vince per la risposta del servizio in ingresso, e queste due risposte possono differire.

Non lasciate che il tunnel di uscita mangi il proprio endpoint

Il client di uscita deve raggiungere l’indirizzo pubblico del suo pari per stabilire il tunnel, quantomeno. Se quell’indirizzo è esso stesso instradato nel tunnel, il client si insegue la coda: il trasporto non sale mai, oppure sale e cade nel momento in cui la rotta viene installata. Il registro sembra un timeout di autenticazione e non un guasto di routing, ed è per questo che la rotta merita il primo controllo.

Controllate la rotta prima delle credenziali e di nuovo una volta salito il tunnel, perché una voce può essere corretta all’avvio e sbagliata un minuto dopo. L’indirizzo del pari deve puntare al percorso WAN ordinario, mai al dispositivo di tunnel. Quando il trasporto è stabile, la domanda interessante passa al traffico inoltrato, che è la decisione successiva.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Scegliete quali utenti ricevono l’uscita

La politica di origine appartiene all’ingresso dove il traffico entra nell’apparato, quindi scegliete il pool di accesso remoto, o identità più strette al suo interno. Preservate le destinazioni private e le eccezioni di gestione che non devono mai essere inviate all’uscita, e mettete quelle regole prima di quella ampia. Il percorso di uscita ha poi bisogno della propria traduzione o di una disposizione di ritorno instradata, che per la maggior parte dei progetti significa NAT in uscita sull’interfaccia di uscita che copre il pool. La traduzione non sceglie un’uscita; riscrive solo ciò che è già uscito, quindi una regola NAT su una WAN estranea non cambia nulla nella selezione.

Confermate che l’estremità remota consenta il traffico inoltrato da questo progetto, perché alcuni fornitori lo fanno e altri no. La differenza si vede come un tunnel che si connette e non trasporta nulla, cosa facile da leggere come guasto locale. Provate i tre flussi separatamente, perché falliscono in modo indipendente e due su tre è un progetto a metà.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Il primo comando è la connessione esterna dell’utente in mobilità, e funziona quando il client riporta che la sequenza di inizializzazione è completa. Il secondo, eseguito da quel portatile connesso, dovrebbe riportare l’indirizzo del fornitore di uscita invece del vostro indirizzo WAN. Il terzo gira sull’apparato legato a un indirizzo del pool, e prova la politica di origine per il traffico inoltrato senza coinvolgere alcun utente remoto. Se invece risponde dalla WAN, la politica non ha corrisposto, e nessuna modifica di NAT ripara un problema di selezione.

Decidete cosa succede quando l’uscita fallisce

Scrivete il comportamento in caso di guasto prima che accada: quando il tunnel di uscita cade, gli utenti tornano sulla WAN ordinaria o restano bloccati finché l’uscita non ritorna? Entrambe le risposte sono difendibili, e l’apparato non sceglierà per voi. Una rotta rimossa o una politica che punta a un gateway morto non producono automaticamente un risultato di blocco totale. Se volete il blocco, la politica deve dirlo esplicitamente, e va provato togliendo l’uscita invece di ragionarci sopra. Se volete il ritorno, pubblicatelo agli utenti, perché il traffico che prende silenziosamente il percorso ordinario è esattamente quello che qualcuno credeva coperto.

Disattivate l’istanza client, osservate a cosa può ancora arrivare un utente connesso, poi riavviatela. Una richiesta che scade è il risultato di blocco totale che avete chiesto; quella che risponde con l’indirizzo WAN è il ritorno che non avete documentato. Ripetete il controllo per IPv6 e per DNS, perché una politica scritta per IPv4 non dice nulla sul traffico AAAA e un resolver spinto da uno dei tunnel risponde da dove la query esce davvero.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

La ricetta di Netgate per OpenVPN instradato mostra come politica di origine, assegnazione delle interfacce e traduzione in uscita si incastrano, e la sua portata da sito a sito è la parte da non copiare per intero. Ciò che non vi dirà è quale delle tre condizioni qui sopra il vostro progetto ha già rotto.