Perché una VPN che funziona scade comunque sulla risposta
Che una richiesta raggiunga un server privato è solo metà dello scambio. La sua risposta deve ritrovare il client del tunnel attraverso il gateway, la rotta o la traduzione previsti.
La richiesta arriva, il server la registra e il client segnala ancora un timeout. Questa combinazione significa che la risposta non ha ritrovato la via del ritorno, ed è uno dei pochi guasti che puoi confermare da entrambe le estremità insieme. Esegui i controlli in ordine e fermati quando uno di essi fallisce.
Parti da dove è arrivata la richiesta
Conferma che il pacchetto ha raggiunto il servizio prima di ispezionare qualsiasi altra cosa. Una voce di log lato server, un contatore di connessioni o una cattura consentita all'estremità remota rispondono tutti alla stessa domanda, e la loro assenza ti riporta al tunnel invece di spingerti verso la risposta. Questo è il controllo che separa un problema di inoltro da un problema di percorso di ritorno.
Se la richiesta non è mai arrivata, fermati qui. Il tunnel, l'instradamento verso il prefisso privato o la regola di accesso sono l'argomento, e il percorso della risposta non è ancora rilevante. Annota anche l'indirizzo di origine che il server ha visto. È o l'indirizzo del pool assegnato al client o un indirizzo tradotto, e questa differenza determina quale dei controlli successivi si applica.
La risposta ha bisogno di una rotta verso il pool
Un client ad accesso remoto riceve di solito un indirizzo da un pool, e la rete privata ha bisogno di una rotta di ritorno verso quel pool. Un server la cui rotta predefinita punta al proprio gateway consegna il pacchetto a quel gateway, che non ha idea di dove si trovi il pool, e la risposta muore lì. Il client vede un timeout perché non è tornato nulla, cosa indistinguibile da una richiesta che non è mai partita.
Controlla la rotta che il server sceglie per l'indirizzo del client, non quella che usa per la propria sottorete. Quelle due ricerche possono dare risposte diverse, e la seconda è quella che conta qui. La traduzione è la progettazione alternativa e cambia ciò che il server vede. Può semplificare un percorso di ritorno, e rimuove anche l'indirizzo originale del client dai log del server, il che influisce su ogni regola o rapporto costruito su quel campo.
Confronta la cattura sul server con la cattura sul gateway
Confronta ciò che esce dal server con ciò che arriva al gateway. Una cattura sull'interfaccia in uscita del server e una cattura sul gateway del tunnel rispondono a due metà diverse della domanda, e lo scarto tra loro localizza la perdita.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Una richiesta generata dal gateway stesso è un pessimo sostituto di un test dal client, perché proviene da un altro indirizzo e incontra altre regole. Per questo un ping riuscito dal gateway e una richiesta fallita dal client possono essere entrambi veri.
Quando sul percorso ci sono più router, controlla ognuno di quelli che ha bisogno di una rotta verso il pool. Una progettazione sito a sito richiede spesso che il prefisso remoto sia noto su più di un dispositivo, e il gateway stesso deve inoltrare tra il tunnel e la LAN; le note di inoltro di strongSwan coprono il lato sysctl e firewall della faccenda.
Annota il pool, il prefisso e il responsabile
Quattro fatti appartengono alla nota: il pool ricevuto dal client, il prefisso privato che gli serviva, il router responsabile della risposta e la regola di traduzione se esiste. Con questi, un cambio di gateway successivo è un confronto e non un'indagine.
Poi ripeti il test con un client ordinario e il vero account dell'applicazione. Ampliare i privilegi dell'applicazione non può riparare il percorso di ritorno di un pacchetto, e una modifica dell'account fatta durante questa diagnosi confonderà il confronto successivo. Se la progettazione si basa sulla traduzione, documentala dove si leggono i log del server. Chi vede un indirizzo di origine sconosciuto in una traccia di controllo non dovrebbe dover riscoprire la mappatura da un ticket.