Warum route -interface einen Host außerhalb des Links nicht erreicht

route akzeptiert den Wi-Fi-Interface-Namen, beendet sich ohne Beschwerde, und der Host bleibt unerreichbar. Nichts ist beschädigt; die Beziehung in der Route ist einfach falsch: Ein Interface-Flag sagt, an welchem Link ein Ziel liegt, nicht welcher Router Verkehr für ein Ziel empfangen soll, das woanders liegt. Der Befehl gelingt, weil er syntaktisch gültig ist, nicht weil er einen funktionierenden Pfad beschreibt.

Diese Unterscheidung entscheidet, ob eine Routenausnahme neben einem VPN funktioniert oder nur plausibel aussieht.

Das Interface ist der Ausgang, der Next Hop ist die Übergabe

Auf einem Mac mit Adresse 192.168.50.20 und einem Router unter 192.168.50.1 ist ein anderer Rechner am selben Link direkt erreichbar. Das Frame wird an diesen Rechner adressiert und auf den Draht gelegt. Kein Router ist beteiligt, und eine interface-gebundene Route drückt genau das aus. Ändern Sie das ferne Ende zu einem Host in einem anderen Gebäude, und derselbe Befehl ergibt keinen Sinn mehr. Der Mac hat keine Adresse der zweiten Schicht, die er auf den Draht legen könnte, also gibt es nichts, was das Interface-Flag beschreiben könnte.

Ein Ziel außerhalb des Links ist anders. Der Mac kann kein Frame auf den Draht legen, das an einen Host adressiert ist, den er auf der zweiten Schicht nicht erreicht; er übergibt das Paket an einen Router, der das kann. Die Route braucht daher ein Gateway, und das Gateway selbst muss am angeschlossenen Link erreichbar sein.

Das Interface-Flag für ein Ziel außerhalb des Links zu verwenden, teilt macOS mit, das Ziel so zu behandeln, als läge es auf dem Draht. Dann scheitert der Kernel daran, eine Adresse der zweiten Schicht dafür aufzulösen, und das Paket wird verworfen, ohne dass der Fehler etwas Nützliches enthält.

Was das Interface-Flag tatsächlich behauptet

Apples Routenreferenz definiert die Interface-Form für Ziele, die ohne Zwischeninstanz direkt erreichbar sind. Das ist eine Aussage über das Linkmodell, keine Präferenz dafür, welchen Adapter man verwendet. Einen Internethost über Wi-Fi zu erreichen, erfordert weiterhin einen Router an diesem Wi-Fi-Link, und die Route muss ihn benennen.

Interface-Scope ist ein eigenes Attribut. Es ordnet eine Route einem bestimmten Interface für Scope-Entscheidungen zu, etwa welche Quelladresse gilt, schafft aber keine Erreichbarkeit für ein Ziel, das das Interface allein nicht erreicht. Die beiden Attribute beantworten unterschiedliche Fragen.

Deshalb kann ein Befehl akzeptiert werden, in der Tabelle erscheinen und trotzdem fehlschlagen. Der Kernel validiert nicht Ihre Absicht; er protokolliert, was Sie behauptet haben, und die Behauptung war, das Ziel liege on-link. Ein stiller Erfolg, gefolgt von einem stillen Verwerfen, ist das erwartete Ergebnis, kein Fehler. Lesen Sie sich die Behauptung noch einmal vor, bevor Sie das Netzwerk beschuldigen.

Die Route, die ein Ziel außerhalb des Links braucht

Für einen genehmigten Pfad zu einer Dokumentationsadresse wie 198.51.100.25 über den LAN-Router ist die beabsichtigte Beziehung ein Ziel, ein Next Hop von 192.168.50.1 und das LAN-Interface, das diesen Next Hop erreicht. Das Interface ergibt sich aus der Next-Hop-Suche, statt vom route-Befehl erzwungen zu werden.

Unter macOS ist die reine Leseinspektion route -n get 198.51.100.25. Lesen Sie die Gateway- und Interface-Zeilen zusammen und prüfen Sie, ob das Gateway eine Adresse ist, die der Mac tatsächlich erreicht. Ein Gateway in einem anderen Subnetz oder eines, das seit der letzten Netzwerkänderung verschwunden ist, erzeugt eine Route, die korrekt aussieht und nichts weiterleitet.

Hardcodieren Sie en0 nicht in einer dauerhaften Anweisung. Interface-Namen ändern sich mit Adaptern, Docks und VPN-Clients, und eine Route, die den falschen nennt, scheitert auf eine Weise, die leicht als umfassenderer Netzwerkfehler missdeutet wird.

Lesen Sie die aktuelle Wahl, bevor Sie sie ersetzen

Bevor Sie etwas hinzufügen, prüfen Sie, was das System bereits gewählt hat und warum. Diese Ausgabe sagt Ihnen, ob der Verkehr durch den Tunnel, durch den LAN-Router oder nirgendwohin geht, und sie gibt Ihnen eine Basislinie zum Vergleich nach der Änderung. Ohne sie können Sie nicht sagen, ob die neue Route gewirkt hat.

Prüfen Sie dann die Adressfamilie. Eine für IPv4 hinzugefügte Route bewirkt nichts für ein IPv6-Ziel, und ein Dienst, der in beide Familien auflöst, kann zeitweise erreichbar erscheinen. Die Routentabelle und der Resolver beantworten unterschiedliche Fragen, und beide müssen mit dem beabsichtigten Pfad übereinstimmen.

Denken Sie schließlich daran, dass eine Route eine Auswahl ist, keine Erlaubnis. Ein verwaltetes VPN-Profil oder ein Client-Filter kann den direkten Pfad trotzdem verbieten, selbst wenn die Tabelle darauf zeigt, testen Sie also mit der tatsächlichen Anwendung, statt anzunehmen, dass ein erfolgreicher Tabelleneintrag die Untersuchung beendet.

Tunnel und Richtlinien ändern die Form

Punkt-zu-Punkt-Interfaces sind ihr eigener Fall. Ein Tunnel kann eine Route ohne Gateway-Adresse im Ethernet-Stil tragen, und das ist nicht automatisch falsch. Wenden Sie das echte Linkmodell des Interfaces an, statt ein Wi-Fi-Beispiel auf jeden Tabelleneintrag auszudehnen, den Sie sehen.

Für Änderungsanfragen notieren Sie das Ziel, den genehmigten Netzwerkpfad, das aktuelle Gateway und Interface sowie wer die Ausnahme pflegen soll. Der Eigentümer ist wichtig, weil eine einmalige, an der Eingabeaufforderung getippte Route keine Richtlinie ist und die nächste Wiederverbindung sie löscht.

Wenn die Anforderung lautet, diesen Host bei aktivem VPN zu erreichen, ist die ehrliche Antwort meist eine spezifische Host-Route über den lokalen Router, installiert von dem Netzwerkmanager, dem das Interface gehört. Wenn die Anforderung lautet, alles direkt zu erreichen, braucht die Anforderung selbst eine Richtlinienprüfung, bevor sie einen route-Befehl braucht.