Un client VPN sul tuo server web rompe le sue risposte?

Il sito si carica da un portatile sulla stessa rete e va in timeout da ogni altra parte, e l'host esegue anche un client VPN per il proprio traffico in uscita. Questa combinazione produce un guasto preciso: la connessione in entrata arriva, la risposta esce dal percorso sbagliato e il client all'esterno non vede mai una risposta. Entrambe le metà compaiono nella stessa cattura di pacchetti, quindi l'ordine degli eventi è la parte che vale la pena leggere.

Una regola di routing basata sull'origine spesso corregge il sintomo. Di solito esenta anche più traffico del sito che l'ha motivata, ed è questa la parte che vale la pena capire prima di salvare la regola.

Il sintomo: risponde localmente e non dall'esterno

All'interno della rete la risposta non deve attraversare il tunnel, quindi la pagina si carica e il servizio sembra sano. Dall'esterno la richiesta raggiunge l'host e la risposta viene instradata nella VPN, dove l'estremità remota non ha motivo di accettarla. Il browser vede un timeout invece di un rifiuto, che è la firma di un percorso a senso unico e non di una porta chiusa.

Conferma la forma prima di cambiare il routing: l'ascoltatore è attivo, la richiesta locale riesce e la richiesta esterna non produce alcuna risposta. Queste tre osservazioni insieme indicano il percorso di ritorno e non la configurazione del server web. Un'asimmetria così pulita è più utile di qualsiasi riga di log, perché esclude l'ascoltatore prima che tu legga un solo messaggio di errore.

Mantieni aperto un percorso di amministrazione indipendente mentre lavori. Una regola che rompe la tua stessa sessione SSH trasforma una correzione di dieci minuti in una visita fisica.

Cosa fa corrispondere davvero un selettore di origine

Nel routing delle policy di Linux, una regola come from 192.168.50.2 fa corrispondere i pacchetti la cui origine è quell'indirizzo. Non codifica il fatto che il pacchetto continua una conversazione entrata dal router domestico, e non sa quale processo l'ha creata. L'indirizzo di quell'esempio è illustrativo; sostituiscilo con l'indirizzo che il tuo host usa davvero. Tratta la riga come un'affermazione sugli indirizzi e nulla più.

Se la tabella selezionata fornisce una normale rotta predefinita, ogni pacchetto che porta quell'origine può prendere la stessa eccezione. Un altro servizio legato allo stesso indirizzo la eredita, e un'applicazione che si lega deliberatamente a quell'indirizzo la eredita anch'essa. Il riferimento delle regole di policy elenca origine, destinazione, protocollo, porta, marca e priorità come selettori separati, il che ricorda che l'origine da sola è la più grossolana disponibile.

La priorità decide l'esito. Le ricerche procedono in ordine e la prima tabella che produce un risultato può concludere la ricerca, quindi una regola collocata troppo presto può nascondere una rotta più specifica che una tabella successiva avrebbe fornito. Leggi l'intero elenco ordinato invece della sola riga che hai aggiunto. Una regola che non corrisponde mai non costa nulla, mentre una che corrisponde troppo presto cambia silenziosamente tutto ciò che sta dietro.

Controlla il percorso di ritorno e il traffico che non avevi previsto

Leggi le regole e le tabelle, poi chiedi al kernel quale percorso prenderebbe una specifica coppia di origine e destinazione. Testare dall'host stesso non è come testare dall'esterno, quindi fai entrambe le cose.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Poi accetta una nuova connessione esterna e, separatamente, una richiesta che deve ancora uscire tramite la VPN. Se la seconda ora esce direttamente, l'eccezione è più ampia del problema che stavi risolvendo, e il test che conta è quello che non intendevi modificare.

Un controllo dell'indirizzo pubblico in un browser riporta solo le richieste effettuate da quel browser. Non dice nulla sulle risposte del server web, sulla selezione dell'origine di un'altra applicazione locale, né su cosa succede al traffico di gestione dopo la prossima riconnessione VPN.

Decidi quanto può essere stretta l'eccezione

Due progetti sono difendibili e vanno scelti deliberatamente. Se l'host esiste per pubblicare questo servizio e il suo traffico in uscita non è importante, un indirizzo locale dedicato con una policy solo per la WAN è un compromesso ragionevole purché tu accetti l'intera portata. Se solo determinate connessioni in entrata devono essere ammesse, la selezione dell'indirizzo è troppo grossolana e davanti ad essa serve un progetto consapevole delle connessioni.

Registra il contratto su cui fai affidamento: la mappatura pubblica, l'indirizzo dell'host a cui viene consegnata la richiesta e il percorso che la risposta dovrebbe prendere. Un servizio in entrata pubblicato tramite un fornitore VPN è un contratto diverso da uno pubblicato tramite un router domestico, e un'eccezione copiata da un esempio è spesso sbagliata per l'altro.

Mantieni la policy nel componente che possiede il routing invece di incollare un comando in un file di avvio. L'ordine delle regole, la pulizia dopo un cambio di rete e la ripetizione dopo un riavvio devono tutti sopravvivere, e un file di avvio non testato di solito fallisce nel momento in cui non stai guardando. Chiudi con il risultato di accettazione che puoi difendere: un sito pubblicato ripristinato e un flusso non correlato invariato.