Waarom route -interface een host buiten de link niet bereikt

route accepteert de Wi-Fi-interfacenaam, sluit af zonder klagen, en de host blijft onbereikbaar. Niets is beschadigd; de relatie in de route is simpelweg verkeerd: een interface-vlag zegt op welke link een bestemming staat, niet welke router verkeer moet ontvangen voor een bestemming die elders staat. Het commando slaagt omdat het syntactisch geldig is, niet omdat het een werkend pad beschrijft.

Dat onderscheid bepaalt of een route-uitzondering naast een VPN werkt of alleen aannemelijk lijkt.

De interface is de uitgang, de volgende hop is de overdracht

Op een Mac met adres 192.168.50.20 en een router op 192.168.50.1 is een andere machine op dezelfde link rechtstreeks bereikbaar. Het frame wordt aan die machine geadresseerd en op de draad gezet. Er is geen router bij betrokken, en een interfacegebonden route drukt precies dat uit. Verander het verre uiteinde in een host in een ander gebouw en hetzelfde commando houdt op zinvol te zijn. De Mac heeft geen adres op de tweede laag om op de draad te zetten, dus de interface-vlag heeft niets te beschrijven.

Een bestemming buiten de link is anders. De Mac kan geen frame op de draad zetten dat aan een host is geadresseerd die hij op de tweede laag niet bereikt; hij draagt het pakket over aan een router die dat wel kan. De route heeft daarom een gateway nodig, en de gateway zelf moet bereikbaar zijn op de aangesloten link.

De interface-vlag gebruiken voor een bestemming buiten de link vertelt macOS om die bestemming te behandelen alsof zij op de draad staat. De kernel slaagt er dan niet in een adres op de tweede laag ervoor op te lossen, en het pakket wordt weggegooid zonder iets nuttigs in de fout.

Wat de interface-vlag werkelijk beweert

De routedocumentatie van Apple definieert de interfacevorm voor bestemmingen die rechtstreeks bereikbaar zijn zonder tussenpersoon. Het is een uitspraak over het linkmodel, geen voorkeur voor welke adapter te gebruiken. Een internethost via Wi-Fi bereiken vereist nog steeds een router op die Wi-Fi-link, en de route moet die noemen.

Interfacescope is een apart attribuut. Het koppelt een route aan een bepaalde interface voor scope-beslissingen zoals welk bronadres geldt, maar het creëert geen bereikbaarheid voor een bestemming die de interface zelf niet kan bereiken. De twee attributen beantwoorden verschillende vragen.

Daarom kan een commando worden geaccepteerd, in de tabel verschijnen en toch falen. De kernel valideert uw bedoeling niet; hij legt vast wat u beweerde, en de bewering was dat de bestemming on-link is. Stil succes gevolgd door stil weggooien is het verwachte resultaat, geen bug. Lees de bewering nog eens terug voordat u het netwerk de schuld geeft.

De route die een bestemming buiten de link nodig heeft

Voor een goedgekeurd pad naar een documentatieadres zoals 198.51.100.25 via de LAN-router is de bedoelde relatie een bestemming, een volgende hop van 192.168.50.1 en de LAN-interface die die volgende hop bereikt. De interface volgt uit het opzoeken van de volgende hop in plaats van te worden afgedwongen door het route-commando.

Op macOS is de alleen-lezen-inspectie route -n get 198.51.100.25. Lees de gateway- en interfaceregels samen en controleer of de gateway een adres is dat de Mac werkelijk kan bereiken. Een gateway op een ander subnet, of een die sinds de laatste netwerkwijziging weg is, levert een route op die er correct uitziet en niets doorstuurt.

Harcodeer en0 niet in een blijvende instructie. Interfacenamen veranderen met adapters, docks en VPN-clients, en een route die de verkeerde noemt faalt op een manier die makkelijk als een bredere netwerkstoring wordt gelezen.

Lees de huidige keuze voordat u die vervangt

Voordat u iets toevoegt, inspecteert u wat het systeem al heeft gekozen en waarom. Die uitvoer vertelt u of verkeer via de tunnel, via de LAN-router of nergens heen gaat, en geeft een basislijn om na de wijziging mee te vergelijken. Zonder die uitvoer kunt u niet zeggen of de nieuwe route effect heeft gehad.

Controleer daarna de adresfamilie. Een route die voor IPv4 is toegevoegd, doet niets voor een IPv6-bestemming, en een dienst die naar beide families oplost kan periodiek bereikbaar lijken. De routetabel en de resolver beantwoorden verschillende vragen, en beide moeten overeenkomen met het bedoelde pad.

Bedenk ten slotte dat een route een keuze is, geen toestemming. Een beheerd VPN-profiel of een clientfilter kan het directe pad nog steeds verbieden, zelfs wanneer de tabel erop wijst, dus test met de werkelijke toepassing in plaats van aan te nemen dat een geslaagde tabelvermelding het onderzoek beëindigt.

Tunnels en beleid veranderen de vorm

Point-to-point-interfaces zijn een eigen geval. Een tunnel kan een route dragen zonder gatewayadres in Ethernet-stijl, en dat is niet automatisch fout. Pas het werkelijke linkmodel van de interface toe in plaats van een Wi-Fi-voorbeeld uit te breiden naar elke tabelvermelding die u ziet.

Voor wijzigingsverzoeken schrijft u de bestemming, het goedgekeurde netwerkpad, de huidige gateway en interface op, en wie de uitzondering wordt geacht te onderhouden. De eigenaar is van belang omdat een eenmalige route die bij de prompt is getypt geen beleid is, en de volgende herverbinding wist hem.

Als de eis is om deze host te bereiken terwijl de VPN actief is, is het eerlijke antwoord meestal een specifieke hostroute via de lokale router, geïnstalleerd door de netwerkbeheerder die de interface bezit. Als de eis is om alles rechtstreeks te bereiken, heeft de eis zelf een beleidsherziening nodig voordat hij een route-commando nodig heeft.