Route wegen Host-Bits abgelehnt? Finden Sie das beabsichtigte Präfix

Ihre Routenzeile kommt abgelehnt zurück, und der Rat, den Sie finden, sagt, Sie sollen IP-Weiterleitung aktivieren. Diese beiden Dinge liegen auf verschiedenen Stufen des Problems. Weiterleitung entscheidet, ob ein Host Pakete zwischen Schnittstellen bewegen darf; sie hat keine Meinung dazu, ob das eingegebene Ziel ein gültiges Netz ist. Korrigieren Sie zuerst das Präfix, denn Weiterleitung rettet keine Adresse und Maske, die nicht zusammenpassen.

Worüber sich der Parser tatsächlich beschwert

Ein Ziel, das als Adresse plus Maske geschrieben wird, muss ein Netz beschreiben, und ein Netz beginnt mit genullten Host-Bits. Wenn die angegebene Adresse noch einen Wert im Hostteil trägt, ist das Paar innerlich widersprüchlich: 172.20.130.0 sieht ordentlich aus, weil es auf null endet, aber die Null im vierten Oktett ist nicht das Einzige, worauf es ankommt. Das dritte Oktett ist hier dasjenige mit den verirrten Bits.

Werkzeuge gehen mit dieser Widersprüchlichkeit unterschiedlich um. Strikte Parser lehnen die Zeile ab und benennen Host-Bits. Nachsichtige Parser maskieren die Adresse herunter und installieren etwas, das Sie nicht verlangt haben, was schlimmer ist, weil die Konfiguration nun einen Bereich routet, den Sie nie beabsichtigt haben. Pythons ipaddress-Modul bietet die Wahl direkt: striktes Netzwerk-Parsing löst einen Fehler aus, und strict=False maskiert die Host-Bits aus. Ihr Client kann strikt, nachsichtig oder zwischen Versionen inkonsistent sein, also lesen Sie die Meldung, statt sich auf eine Gewohnheit zu verlassen.

Rechnen Sie das Beispiel von Hand durch

Nehmen Sie einen Tunnel, der 172.20.130.0 mit einer /20-Maske erreichen muss. Eine /20 leiht sich vier Bits aus dem dritten Oktett, also zählt dieses Oktett nur in Schritten von 16: 0, 16, 32 und weiter bis 240. Der Wert 130 fällt zwischen 128 und 143, was bedeutet, dass das umschließende Netz bei 172.20.128.0 beginnt, nicht bei 172.20.130.0 mit gelöschtem letzten Oktett.

Ausgeschrieben reicht der Block von 172.20.128.0 bis 172.20.143.255 und umfasst 4,096 Adressen. Werden dieselben Werte einem nicht-strikten Parser gegeben, zeigt sich die Ersetzung, die er in Ihrem Namen vorgenommen hätte:

$ 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

Entscheiden Sie, welches Ziel Sie eigentlich meinten

Die abgelehnte Zeile verbirgt meist eine von drei Absichten, und nur Sie können wählen. Braucht der Tunnel den ganzen Block, schreiben Sie 172.20.128.0/20, die kanonische Netzwerkadresse. Braucht der Tunnel nur das 130er-Segment, war die Maske falsch, und 172.20.130.0/24 ist die ehrliche Form. Ist ein einzelner Rechner das Ziel, ist eine IPv4-Host-Route /32 und es ist keine Maskenarithmetik im Spiel.

Jede davon erlaubt eine andere Menge Verkehr, und das ist der eigentliche Grund, die Maske nicht zu erweitern, bis die Beschwerde aufhört. Eine /16 akzeptiert die Zeile fast überall und schickt Verkehr zu Zielen, die Sie nie durch den Tunnel routen wollten. Schreiben Sie das engste Präfix, das der Absicht entspricht, und bestätigen Sie es dann gegen den erwarteten nächsten Hop, nicht gegen das Schweigen des Parsers.

Warum Weiterleitung nie die Lösung war

Eine abgelehnte Route erreicht den Weiterleitungspfad nie, daher kann das Umschalten von net.ipv4.ip_forward das Ergebnis nicht ändern. Diese Einstellung zählt später, wenn der Host Pakete zwischen Schnittstellen weitergeben muss, und sie vor der korrekten Tabelle einzuschalten ändert nur, welche Stufe als Nächstes scheitert.

Zwei andere Dinge werden oft an derselben Stelle beschuldigt. Die Route kann akzeptiert werden und trotzdem gegen eine spezifischere Route verlieren, und eine Firewall-Regel kann Verkehr nach einem korrekten Lookup verwerfen. Halten Sie die Stufen getrennt: Syntax, Installation, Auswahl, Filterung. An der falschen Stufe zu arbeiten fühlt sich produktiv an, weil jede Änderung etwas neu startet.

Prüfen Sie die installierte Route und den Pfad, den sie gewinnt

Sobald der Client die Zeile akzeptiert, sehen Sie nach, was er installiert hat und welche Route der Kernel für eine repräsentative Adresse im Block wählt. Weicht das installierte Präfix von dem Geschriebenen ab, hat ein Normalisierer in Ihrem Namen gehandelt.

Fragen Sie eine Mitgliedsadresse sowie eine außerhalb des Blocks ab, damit der Vergleich aussagekräftig ist und nicht nur eine beruhigende Zeile:

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

Die dritte Abfrage sollte außerhalb des Tunnels landen, wenn Ihr Präfix richtig ist, und wenn nicht, ist die gebaute Route breiter, als Sie denken. Notieren Sie, was das Präfix abdecken sollte, bevor Sie die nächste Einstellung anfassen, denn eine Route, die parst, und ein Pfad, der funktioniert, bleiben getrennte Beobachtungen.