Indirizzo peer PPP o endpoint VPN: quale va in via

Una sola riga su un’interfaccia PPP risolve gran parte della discussione di routing su una macchina VPN: l’indirizzo interno e il peer stampato accanto. Leggi quella coppia come una sottorete minuscola e cercherai un gateway che non esiste. Leggila come i due estremi di un unico collegamento e il next hop diventa ovvio. Il confronto qui è tra quelle due letture, perché ogni tabella che costruirai dopo eredita quella che hai scelto. Nulla dell’endpoint VPN esterno è deciso da nessuna delle due.

Due letture di una stessa riga di interfaccia

Prendi una sessione in cui l’interfaccia riporta inet 10.64.3.9 peer 10.64.3.1/32. La lettura a sottorete tratta 10.64.3.9 come un host solitario su un’isola /32 e poi cerca un router per raggiungere qualcosa oltre. Poiché l’unico altro indirizzo sul collegamento è il peer, quella lettura finisce per proporre 10.64.3.9 stesso come gateway, il che è circolare.

La lettura a endpoint è quella documentata. Su un’interfaccia punto a punto, peer nomina l’estremo remoto di quell’unico collegamento, quindi 10.64.3.1 è il next hop utilizzabile e 10.64.3.9 è sempre solo un indirizzo di origine.

Quella differenza governa ciò che può comparire in via. Scrivere lì l’indirizzo locale produce una rotta che il kernel non riesce a risolvere verso un vicino, quindi la voce fallisce la validazione oppure inghiotte traffico mentre in un elenco appare perfettamente sana. Il peer funziona perché è una destinazione reale sul collegamento. Entrambe le letture concordano sull’endpoint VPN esterno, che è un’identità del tutto separata: lo si raggiunge tramite l’underlay, non tramite il tunnel che termina.

Cosa ha già installato la sessione

Prima di scrivere una tabella propria, stampa ciò che è arrivato con il collegamento. Un’integrazione PPP supportata di solito installa una rotta di dispositivo e una rotta del peer durante l’impostazione della sessione, e quelle due voci codificano già la lettura corretta.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Una rotta di dispositivo come 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 non porta alcun gateway perché l’interfaccia stessa è il percorso. Una rotta che nomina il peer con via è un altro oggetto con un’altra durata, e scompare quando la sessione cade. Copiare una delle due forme in una tabella persistente senza controllare come viene reinstallata è il motivo abituale per cui un tunnel che funzionava perde la rotta dopo una riconnessione.

Confronta i due elenchi invece di fidarti della memoria. Se la rotta del peer esiste in main ma la tua tabella aggiuntiva è vuota, hai imparato qualcosa che la riga dell’indirizzo non ti aveva mai detto.

Una regola e una tabella sono decisioni separate

Selezionare una tabella e riempirla sono passaggi indipendenti, e il confronto conta qui perché i due vengono spesso confusi durante il debug. Una regola che manda il traffico marcato alla tabella 100 non fa nulla se la tabella 100 non ha una rotta corrispondente, e una tabella ben popolata è irraggiungibile se nessuna regola la indica.

Mezza rotta predefinita non è una rotta predefinita. Una singola 0.0.0.0/1 copre la metà inferiore dello spazio IPv4, quindi una policy che intende catturare tutto ha bisogno anche della 128.0.0.0/1 corrispondente, o di una default autentica. Leggere una configurazione funzionante e copiare una delle due metà è il modo in cui le persone finiscono con un loop di routing che si rompe solo su certe destinazioni.

Lascia eccezioni deliberate per gli indirizzi che devono restare sulla LAN, e decidi cosa succede quando la ricerca non trova nulla nella tabella selezionata. Una rotta di fallback esplicita è più facile da ragionare di una tabella vuota, che restituisce un risultato irraggiungibile e fa sembrare l’applicazione rotta invece che instradata male.

Poni alla ricerca la domanda che pone la tua applicazione

ip route get risolve un percorso; ip route show elenca le voci memorizzate, e le due possono discordare senza che nessuna sia sbagliata. Includi il contesto di origine, perché le regole basate sull’origine corrispondono solo quando la ricerca porta con sé un’origine.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Il primo comando pone la domanda dall’host. Il secondo aggiunge un’interfaccia di ingresso, che è più vicina a ciò che sperimenta il traffico inoltrato, e la risposta spesso indica un’altra tabella. Nessuna delle destinazioni è un servizio di test dal vivo; 198.51.100.23 è un indirizzo di documentazione, quindi sostituiscilo con un host che ti è permesso sondare.

Anche una ricerca corretta dimostra solo che è stato scelto un percorso. Non dice nulla sul fatto che l’altro lato accetti il traffico o che la risposta possa tornare attraverso lo stesso ragionamento.

Dove il confronto si ribalta

Il traffico dell’host e il traffico inoltrato non prendono solo ricerche diverse; incontrano filtri diversi al ritorno. Linux applica la validazione del percorso inverso usando il più severo tra le impostazioni di tutte le interfacce e dell’interfaccia ricevente, quindi cambiare il valore di un’interfaccia può non avere alcun effetto visibile. Il routing basato sul mark aggiunge la relazione src_valid_mark, in cui il mark deve corrispondere perché un’origine sia considerata valida.

Se le risposte svaniscono mentre il routing in uscita sembra corretto, leggi i valori effettivi prima di toccarli, e cambiali solo con una ragione di policy dichiarata.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Scegli tra i due progetti sulla base di prove: se l’applicazione si lega all’indirizzo PPP, bastano una regola di origine più una tabella che contenga la rotta del peer. Se la macchina inoltra per una LAN dietro di sé, hai bisogno anche che il contesto di ingresso e il percorso di ritorno concordino. Quando non concordano, correggi la proprietà della rotta invece di allentare la validazione per l’intera macchina.