Due salti VPN su un solo Pi: quale route trasporta quale peer

Due indirizzi di tunnel su una piccola scheda sembrano un errore, e il riflesso è cancellarne uno. Quel riflesso rompe ciò che doveva riordinare. Un host che porta due salti tiene un indirizzo per attacco, e ogni indirizzo è selezionato da una route diversa. La domanda che vale la pena porsi è quale route sceglie quale trasportatore per quale destinazione, non quanti indirizzi esistano.

Tre destinazioni che richiedono trasportatori diversi

Una catena a due salti è tre classi di destinazione impilate, e ciascuna è portata da un attacco diverso. Il peer esterno deve essere raggiunto tramite il collegamento fisico. Il peer interno deve essere raggiunto tramite il tunnel esterno. La destinazione dell’applicazione coperta deve essere raggiunta tramite il tunnel interno, il cui trasporto è portato da quello esterno.

Riempi le righe con gli indirizzi reali del lettore prima di toccare una route, perché la tabella è utile solo quando è concreta. Una catena funzionante soddisfa tutte e quattro le righe contemporaneamente, e una catena a metà di solito ne soddisfa una con il trasportatore sbagliato. È leggere la riga sbagliata come guasto che trasforma un problema di routing in un intero pomeriggio di modifiche.

Gli indirizzi hanno ruoli, non un numero

Linux consente più indirizzi su una interfaccia e più tunnel su un host, quindi un numero non dice nulla sulla correttezza. Conta quale indirizzo appartiene a quale attacco, e se la route per un dato peer seleziona l’attacco che intendevi. Tre viste rispondono da tre direzioni, e vale la pena leggerle nello stesso ordine ogni volta.

L’inventario degli indirizzi mostra cosa esiste e quale attacco lo possiede. La tabella delle route risponde alla domanda del trasportatore per il traffico ordinario verso le destinazioni. La vista delle politiche risponde di nuovo per il traffico selezionato per origine o marchio, che è la disposizione normale quando due client condividono un host.

ip -4 addr show
ip -4 route show table all
ip rule show

Cancellare un indirizzo perché la lista sembra lunga può rimuovere parte del percorso, e cancellare una route perché sembra ridondante fa lo stesso più silenziosamente. Nessuna delle due produce un errore; il peer smette semplicemente di rispondere sul percorso che intendevi mentre resta raggiungibile per un altro. Un’applicazione che riporta l’indirizzo di uscita del peer interno non dimostra che il traffico abbia attraversato il tunnel esterno, poiché l’accesso diretto produce la stessa osservazione. È proprio questo divario tra un’osservazione e una prova a far controllare il trasportatore a livello di routing.

L’ordine di attivazione batte un’attesa fissa

Se il client interno dipende da un indirizzo o da una route forniti dal client esterno, l’attivazione deve attendere quella risorsa invece di un ritardo. Un’attesa funziona fino al giorno in cui il tunnel esterno è lento, e poi fallisce a intermittenza in un modo che nessuno riesce a riprodurre. Un ordinamento basato sulle dipendenze elimina la congettura e non costa nulla oltre a descrivere la dipendenza una volta. Nemmeno i nomi delle interfacce sono un meccanismo di ordinamento.

Il kernel assegna nomi come tun0 e tun1 in ordine di creazione, e tale ordine può cambiare tra riavvii o riconnessioni. Lega la configurazione a un’identità fornita dallo strumento, o a un nome che assegni deliberatamente. Un nome che scegli è un contratto; un nome che sceglie il kernel è un caso.

Tieni il trasporto di ciascun client fuori dalla route applicativa dell’altro, e sii preciso su ciò che le opzioni di routing di OpenVPN 2.6 promettono davvero. Il meccanismo documentato di reindirizzamento predefinito mantiene un client in grado di raggiungere il proprio peer remoto attraverso il gateway che esisteva già, e questo taglia un anello di ricorsione specifico. Non trasforma un client nel trasportatore di un altro, quindi il resto della catena resta il tuo progetto. Dove la catena richiede una politica invece di una route, scrivi una regola esplicita di origine o marchio e provala con il traffico con cui deve corrispondere.

Cosa succede quando il salto esterno muore

Prima che la catena conti come completa, decidi cosa succede quando il salto esterno scompare. Il trasporto del client interno muore con esso, e la mossa successiva è una questione di politica più che tecnica: fallire, riprovare o riconnettersi direttamente tramite il collegamento fisico. È quel terzo esito che vale la pena pensare. Converte in silenzio un progetto a due salti in un progetto a un salto nel momento in cui l’utente crede che la copertura sia ancora intatta.

Se due salti sono obbligatori, il client interno non deve essere in grado di stabilire un percorso diretto quando l’esterno è sparito, e il modo per saperlo è rompere il salto esterno e osservare cosa fa quello interno. Un ripiego approvato è una risposta legittima, ma deve essere scritto, testato e comunicato. Un ripiego che nessuno ha documentato è indistinguibile da una fuga durante la revisione di un incidente.

Il DNS e l’altra famiglia di indirizzi appartengono alla stessa decisione. Una risoluzione generata localmente segue la politica dell’host stesso e non quella di un client inoltrato, quindi il resolver che funziona per il traffico inoltrato potrebbe non essere quello che l’host stesso usa.

Accetta ogni livello nell’ordine in cui l’hai costruito

Testa nell’ordine in cui è stata costruita la catena: prima il tunnel esterno da solo, poi il trasporto del client interno attraverso il tunnel esterno, poi l’applicazione attraverso il tunnel interno. Ogni accettazione deve essere una connessione nuova e non una pagina già aperta. Poi rompi e ripristina ogni livello separatamente e osserva cosa fa il successivo.

Il risultato del ripiego è qui l’osservazione più preziosa, e quella che una pagina di IP pubblico non mostra mai. Salva i percorsi dei peer, gli indirizzi che usano e quel risultato accanto alla configurazione, perché il percorso felice non è la parte che viene messa in discussione dopo.