Rotta rifiutata per i bit di host? Trovate il prefisso previsto

La vostra riga di rotta torna rifiutata, e il consiglio che trovate dice di abilitare l’inoltro IP. Queste due cose stanno in fasi diverse del problema. L’inoltro decide se un host può spostare pacchetti tra interfacce; non ha un’opinione sul fatto che la destinazione digitata sia una rete valida. Correggete prima il prefisso, perché l’inoltro non salverà un indirizzo e una maschera che non concordano.

Di cosa si lamenta davvero l’analizzatore

Una destinazione scritta come indirizzo più maschera deve descrivere una rete, e una rete inizia con bit di host azzerati. Quando l’indirizzo fornito porta ancora un valore nella parte host, la coppia è internamente incoerente: 172.20.130.0 sembra ordinato perché finisce con zero, ma lo zero nel quarto ottetto non è l’unica cosa che conta. Il terzo ottetto è quello che qui contiene bit vaganti.

Gli strumenti trattano questa incoerenza in modo diverso. Gli analizzatori severi rifiutano la riga e nominano i bit di host. Gli analizzatori indulgenti mascherano l’indirizzo e installano qualcosa che non avete chiesto, il che è peggio, perché la configurazione ora instrada un intervallo che non avete mai voluto. Il modulo ipaddress di Python espone la scelta direttamente: l’analisi severa della rete genera un errore e strict=False maschera i bit di host. Il vostro client può essere severo, indulgente o incoerente tra versioni, quindi leggete il messaggio invece di fidarvi di un’abitudine.

Svolgete l’esempio a mano

Prendete un tunnel che deve raggiungere 172.20.130.0 con una maschera /20. Una /20 prende in prestito quattro bit dal terzo ottetto, quindi quell’ottetto conta solo a passi di 16: 0, 16, 32 e così via fino a 240. Il valore 130 cade tra 128 e 143, il che significa che la rete che lo racchiude inizia a 172.20.128.0, non a 172.20.130.0 con l’ultimo ottetto azzerato.

Scritto, il blocco va da 172.20.128.0 a 172.20.143.255 e contiene 4,096 indirizzi. Passare gli stessi valori a un analizzatore non severo mostra la sostituzione che avrebbe fatto al posto vostro:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Decidete quale destinazione volevate davvero

La riga rifiutata di solito nasconde una di tre intenzioni, e solo voi potete scegliere. Se il tunnel ha bisogno dell’intero blocco, scrivete 172.20.128.0/20, l’indirizzo di rete canonico. Se il tunnel ha bisogno solo del segmento 130, la maschera era sbagliata e 172.20.130.0/24 è la forma onesta. Se l’obiettivo è una sola macchina, una rotta di host IPv4 è /32 e nessuna aritmetica delle maschere è coinvolta.

Ognuna autorizza una quantità diversa di traffico, ed è la vera ragione per non allargare la maschera finché la lamentela non cessa. Una /16 accetta la riga quasi ovunque e manda il traffico verso destinazioni che non avete mai voluto instradare nel tunnel. Scrivete il prefisso più stretto che corrisponde all’intenzione, poi confermatelo rispetto al prossimo salto che vi aspettate, non rispetto al silenzio dell’analizzatore.

Perché l’inoltro non è mai stata la soluzione

Una rotta rifiutata non raggiunge mai il percorso di inoltro, quindi commutare net.ipv4.ip_forward non può cambiare il risultato. Quell’impostazione conta più avanti, quando l’host deve passare pacchetti tra interfacce, e attivarla prima che la tabella sia corretta cambia solo quale fase fallirà dopo.

Altre due cose vengono spesso incolpate nello stesso punto. La rotta può essere accettata e comunque perdere contro una rotta più specifica, e una regola del firewall può scartare traffico dopo una ricerca corretta. Tenete separate le fasi: sintassi, installazione, selezione, filtraggio. Lavorare sulla fase sbagliata sembra produttivo perché ogni modifica riavvia qualcosa.

Controllate la rotta installata e il percorso che vince

Una volta che il client accetta la riga, guardate cosa ha installato e quale rotta il kernel sceglie per un indirizzo rappresentativo dentro il blocco. Se il prefisso installato differisce da quello scritto, un normalizzatore ha agito al posto vostro.

Interrogate un indirizzo membro e anche uno fuori dal blocco, così il confronto è significativo e non una sola riga rassicurante:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

La terza interrogazione dovrebbe cadere fuori dal tunnel se il prefisso è corretto, e quando non lo fa, la rotta costruita è più ampia di quanto pensiate. Annotate cosa doveva coprire il prefisso prima di toccare l’impostazione successiva, perché una rotta che si analizza e un percorso che funziona restano osservazioni separate.