Sottorete a valle vs VPN desktop: escludere il transito, non le applicazioni

Una macchina, due lavori, un firewall: un uplink Wi-Fi, una piccola sottorete Ethernet dietro e un client VPN desktop che presume che tutto ciò che esce dalla macchina sia locale. Le applicazioni avviate localmente escono dal percorso di uscita locale. I dispositivi dietro la workstation arrivano sulla porta Ethernet e hanno bisogno di una decisione di inoltro. Un'esclusione scritta per il primo percorso non vede mai il secondo, ed è per questo che un browser aggira il tunnel mentre i dispositivi no.

Due percorsi dei pacchetti, una politica

La prima riga è ciò che descrivono la maggior parte delle guide allo split tunneling. La seconda è una configurazione di router che vive per caso sulla stessa macchina. Fonderle in un unico modello mentale è l'errore; condividono un kernel, non una politica. Disegnate entrambi i percorsi prima di modificare qualsiasi regola, e il resto del progetto deriva da quale percorso manca.

La tabella spiega anche perché una macchina può superare un test e fallirne un altro. Il browser sulla workstation dimostra il percorso locale; un portatile collegato alla porta Ethernet dimostra il percorso di inoltro. Validate ogni modifica con entrambi, altrimenti il secondo resta non testato per quante volte ricarichiate il browser.

Che cosa classifica davvero un'esclusione applicativa

Un'esclusione per applicazione di solito funziona marcando i pacchetti di un processo o di un utente e poi instradando il traffico marcato fuori dal tunnel. È una costruzione di uscita locale. Un pacchetto di un dispositivo a valle non ha alcun processo locale, quindi non corrisponde mai al selettore, qualunque sia il selettore.

Qualunque sia il selettore, i due elenchi non sono lo stesso elenco, e questo è il punto. La guida Mullvad per Linux descrive marcature consumate dal suo firewall e dalla sua politica di instradamento, e i suoi esempi puntano all'uscita locale; non sono una descrizione supportata di un router a valle. Copiarli produce una macchina che crede di avere un'esclusione mentre inoltra tutto nel tunnel.

Scrivete il contratto di transito

Nominate insieme il prefisso di origine a valle e l'interfaccia di ingresso, poi limitate quel prefisso all'ingresso. Senza la restrizione, qualsiasi dispositivo che raggiunga la porta può rivendicare un indirizzo escluso e uscire dal bypass. Trattatelo come due domande: questi host possono usare questo uplink, e possono raggiungere la workstation o gli intervalli privati del tunnel? Sono permessi aggiuntivi, non effetti collaterali della scelta dell'uplink.

Consentite l'inoltro, poi filtratelo. Il gateway Linux ha bisogno dell'inoltro abilitato, di regole che permettano il traffico previsto in entrambe le direzioni e, o di una rotta di ritorno a monte, o di una traduzione di origine deliberatamente limitata. NAT da solo non seleziona l'uplink e non concede il passaggio attraverso un filtro; riscrive un indirizzo solo dopo quelle decisioni.

La classificazione per il transito deve avvenire prima della decisione di rotta di inoltro, cioè nella fase di prerouting e non di output. Una regola collocata dopo la decisione può ancora cambiare il pacchetto, ma non può cambiare dove è già stato inviato.

Le marcature appartengono all'applicazione che le possiede

I valori di marcatura, i numeri di tabella e le priorità delle catene fanno parte della politica dell'applicazione VPN, non sono costanti eterne. Una rete duratura che dipende dall'inserimento di una regola in una tabella che un altro programma rigenera si romperà al prossimo aggiornamento, di solito durante una riconnessione e non in un momento opportuno.

Aggiungere una seconda catena di base con un verdetto accept non necessariamente prevale sul drop di una catena successiva. Le catene di base hanno hook e priorità, e vince il primo verdetto nell'ordine; un accept in una catena non annulla un drop che un'altra catena raggiunge prima. Guardate l'insieme completo delle regole e l'ordine della politica di instradamento, non l'unico contatore che è aumentato. Un contatore prova che una regola è stata eseguita, mai che il suo verdetto sia stato quello applicato.

Integrate, o spostate la sottorete

I due progetti differiscono per chi possiede il bypass. Un progetto integrato mantiene una macchina e una politica, al costo di dipendere dal ciclo di vita delle tabelle dell'applicazione VPN e da un insieme di marcature che la sua documentazione può cambiare. Un router dedicato per la rete a valle elimina del tutto quella dipendenza: la sottorete ha il proprio uplink e la workstation resta un client senza ruolo di inoltro.

Scegliete il secondo quando la rete a valle deve continuare a funzionare attraverso gli aggiornamenti del VPN, o quando nessuno può testare la politica integrata dopo ogni rilascio. Scegliete il primo solo quando l'integrazione è documentata e qualcuno se ne occupa.

Verificate il confine in quattro stati: connesso, riconnessione, bloccato deliberatamente e fermo. Controllate la risoluzione dei nomi ed entrambe le famiglie di indirizzi in ciascuno, perché un bypass che perde DNS non è l'esclusione che avete progettato. Il test deve provare il confine preciso, non solo che una pagina si è caricata.