Il client VPN elimina la route che hai aggiunto? Usa una tabella di policy

Una /24 per una stampante di laboratorio sparisce tra due chiamate a ip route show, e il log del client dice solo che la rete è cambiata. Non c’era niente di sbagliato nel comando, nel prefisso o nei tuoi privilegi. Un client aziendale che possiede il modello di routing dell’host riafferma quel modello ogni volta che qualcun altro lo modifica, quindi la voce che hai aggiunto viene rimossa come intruso. Combatterlo nella stessa tabella è una posizione perdente. La soluzione è smettere del tutto di competere per quella tabella e mettere l’eccezione dove il monitor non guarda mai.

Il monitor spiega la route sparita

Dimostralo prima di riprogettare qualsiasi cosa: leggi la tabella, aggiungi il prefisso, aspetta qualche secondo, rileggi. Se la voce è assente e non hai digitato nulla per rimuoverla, un agente sta osservando. Trova il processo che possiede quel comportamento e leggi il suo journal intorno al momento in cui la route svanisce, perché lo stesso servizio di solito mantiene il tunnel, i filtri dei pacchetti e la configurazione del resolver. Ucciderlo per far restare la tua route è uno scambio che rimpiangerai alla prossima riconnessione.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

Il prefisso e l’interfaccia qui sopra sono segnaposto. Copiare un nome di interfaccia da un esempio funzionante su un’altra macchina è il motivo più comune per cui questa dimostrazione non produce assolutamente nulla.

Una seconda tabella è invisibile al monitor

L’agente ricostruisce solo la tabella che possiede. Dai all’eccezione una tabella propria più una regola che manda lì le destinazioni corrispondenti, e la tabella principale non cambia mai, quindi l’agente non ha nulla da correggere. È tutta qui l’idea: uno spazio dei nomi di route che qualcun altro mantiene, e uno che tocchi solo tu.

Lo scambio è la manutenzione. Due oggetti possono divergere, e la posizione della regola nell’elenco conta quanto la route dentro la tabella che seleziona.

Costruisci l’eccezione, poi falla vincere

Crea la tabella, installa la route e aggiungi una regola che seleziona la tabella per quella destinazione. La preferenza decide se la tua regola viene consultata prima o dopo quelle inserite dal client, e una regola ordinata più tardi non viene mai raggiunta, quindi il numero fa parte del progetto e non è decorazione. Poi chiedi al kernel cosa farebbe davvero, che è una domanda diversa da ciò che hai configurato.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get risolve la route che il kernel userebbe, inclusi dispositivo e indirizzo sorgente. Non stampa l’identificatore della tabella, quindi abbinalo a ip rule show quando devi confermare quale tabella ha vinto. Insieme rispondono all’unica domanda che conta: il traffico verso quell’indirizzo esce dove intendevi?

Altre forme della stessa idea

Lo schema si generalizza appena smetti di pensare per destinazioni. Una sottorete locale può restare raggiungibile mentre il tunnel conserva la route predefinita. Le risposte di un server SSH collegato alla LAN possono uscire dall’interfaccia da cui sono arrivate invece di sparire nel tunnel. E una regola basata sull’interfaccia può spingere nel tunnel tutto ciò che arriva su un’interfaccia wireless, mentre il traffico che l’host genera da sé resta su Ethernet:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Quest’ultimo caso corrisponde all’interfaccia in ingresso anziché alla destinazione, che è un altro tipo di regola e un altro modello mentale. Il traffico inoltrato richiede anche net.ipv4.ip_forward abilitato, e l’estremità remota deve instradare indietro l’intervallo sorgente o tradurlo; una regola su una macchina non crea mai l’altra metà del percorso.

Tratta la regola come usa e getta

Le regole e le route di tabella vivono in memoria. Dopo una riconnessione il dispositivo del tunnel può essere rinominato, l’indirizzo assegnato può spostarsi, e una regola che conserva il vecchio valore smette silenziosamente di corrispondere. Riapplica l’intera modifica da un unico script che la possiede, poi ricontrolla ip rule show, il nome attuale del dispositivo e un ip route get nuovo contro una destinazione reale prima di fidarti dell’eccezione.

Due confini sopravvivono a ogni cura. Il client controlla ancora le proprie regole di filtraggio e la configurazione del resolver, e un’eccezione di routing non ne sovrascrive nessuna delle due. Se il client cancella anche la tua regola di policy, le vie supportate sono la sua politica di tunnel diviso o un client che ti lascia gestire le route, come OpenConnect; patchare un binario del fornitore per zittire il suo monitor è un impegno di manutenzione con un controllo di integrità allegato.

Scrivi il numero di tabella, la preferenza e la destinazione in una nota accanto allo script. Altrimenti la persona successiva trova una regola che sovrasta il tunnel e non ha modo di sapere perché.