Waarom route -interface nie 'n gasheer buite die skakel kan bereik nie

route aanvaar die Wi-Fi-koppelvlaknaam, stop sonder klagte, en die gasheer bly onbereikbaar. Niks is beskadig nie; die verhouding in die roete is bloot verkeerd: 'n koppelvlakvlag sê op watter skakel 'n bestemming sit, nie watter router verkeer vir 'n bestemming elders moet ontvang nie. Die opdrag slaag omdat dit sintakties geldig is, nie omdat dit 'n werkende pad beskryf nie.

Daardie onderskeid bepaal of 'n roete-uitsondering langs 'n VPN sal werk of net geloofwaardig sal lyk.

Koppelvlak is die uitgang, volgende sprong is die oorhandiging

Op 'n Mac met adres 192.168.50.20 en 'n router by 192.168.50.1 kan 'n ander masjien op dieselfde skakel direk bereik word. Die raam word aan daardie masjien geadresseer en op die draad gesit. Geen router is betrokke nie, en 'n koppelvlakbeperkte roete druk presies dit uit. Verander die verre kant na 'n gasheer in 'n ander gebou, en dieselfde opdrag hou op om sin te maak. Die Mac het geen tweede-laag-adres om op die draad te sit nie, so daar is niks vir die koppelvlakvlag om te beskryf nie.

'n Bestemming buite die skakel is anders. Die Mac kan nie 'n raam op die draad sit wat aan 'n gasheer geadresseer is wat dit nie op laag twee kan bereik nie; dit oorhandig die pakket aan 'n router wat dit kan. Die roete het dus 'n poort nodig, en die poort self moet op die gekoppelde skakel bereikbaar wees.

Om die koppelvlakvlag vir 'n bestemming buite die skakel te gebruik, sê vir macOS om daardie bestemming te behandel asof dit op die draad is. Die kern slaag dan nie daarin om 'n tweede-laag-adres daarvoor op te los nie, en die pakket word laat val met niks nuttigs in die fout nie.

Wat die koppelvlakvlag werklik beweer

Apple se roeteverwysing definieer die koppelvlakvorm vir bestemmings wat direk sonder 'n tussenganger bereikbaar is. Dit is 'n stelling oor die skakelmodel, nie 'n voorkeur oor watter adapter om te gebruik nie. Om 'n internetgasheer deur Wi-Fi te bereik, vereis steeds 'n router op daardie Wi-Fi-skakel, en die roete moet dit noem.

Koppelvlakomvang is 'n aparte eienskap. Dit verbind 'n roete met 'n bepaalde koppelvlak vir omvattingsbesluite soos watter bronadres geld, maar dit skep nie bereikbaarheid vir 'n bestemming wat die koppelvlak nie op sy eie kan bereik nie. Die twee eienskappe antwoord verskillende vrae.

Dit is hoekom 'n opdrag aanvaar kan word, in die tabel kan verskyn en steeds kan misluk. Die kern valideer nie jou bedoeling nie; dit teken op wat jy beweer het, en die bewering was dat die bestemming op die skakel is. 'n Stille sukses gevolg deur 'n stille val is die verwagte uitkoms, nie 'n fout nie. Lees die bewering vir jouself terug voordat jy die netwerk blameer.

Die roete wat 'n bestemming buite die skakel nodig het

Vir 'n goedgekeurde pad na 'n dokumentasie-adres soos 198.51.100.25 deur die LAN-router, is die bedoelde verhouding 'n bestemming, 'n volgende sprong van 192.168.50.1, en die LAN-koppelvlak wat daardie volgende sprong bereik. Die koppelvlak word deur die volgende-sprong-soektog afgelei eerder as deur die roete-opdrag afgedwing.

Op macOS is die lees-alleen-inspeksie route -n get 198.51.100.25. Lees die poort- en koppelvlaklyne saam en kyk of die poort 'n adres is wat die Mac werklik kan bereik. 'n Poort op 'n ander subnet, of een wat sedert die laaste netwerkverandering weg is, lewer 'n roete wat korrek lyk en niks aanstuur nie.

Moenie en0 in 'n blywende instruksie hardkodeer nie. Koppelvlakname verander met adapters, dokke en VPN-kliënte, en 'n roete wat die verkeerde een noem, misluk op 'n manier wat maklik as 'n breër netwerkfout gelees kan word.

Lees die huidige keuse voordat jy dit vervang

Voordat jy iets byvoeg, ondersoek wat die stelsel reeds gekies het en waarom. Daardie uitset sê of verkeer deur die tonnel, deur die LAN-router of nêrens gaan nie, en dit gee 'n basislyn om ná die verandering te vergelyk. Sonder dit kan jy nie sê of die nuwe roete effek gehad het nie.

Kyk dan na die adresfamilie. 'n Roete wat vir IPv4 bygevoeg is, doen niks vir 'n IPv6-bestemming nie, en 'n diens wat na beide families oplos, kan ongereeld bereikbaar lyk. Die roetetabel en die oplosser antwoord verskillende vrae, en beide moet met die beoogde pad ooreenstem.

Onthou laastens dat 'n roete 'n keuse is, nie 'n toestemming nie. 'n Bestuurde VPN-profiel of 'n kliëntfilter kan steeds die direkte pad verbied, selfs wanneer die tabel daarheen wys, so toets met die werklike toepassing eerder as om te aanvaar dat 'n suksesvolle tabelinskrywing die ondersoek beëindig.

Tunnels en beleid verander die vorm

Punt-tot-punt-koppelvlakke is hul eie geval. 'n Tonnel kan 'n roete dra sonder 'n poortadres in Ethernet-styl, en dit is nie outomaties verkeerd nie. Pas die koppelvlak se werklike skakelmodel toe eerder as om 'n Wi-Fi-voorbeeld na elke tabelinskrywing te verleng.

Vir veranderingversoeke, skryf die bestemming, die goedgekeurde netwerkpad, die huidige poort en koppelvlak neer, en wie die uitsondering na verwagting sal onderhou. Die eienaar maak saak, want 'n eenmalige roete wat by die opdragprompt getik is, is nie 'n beleid nie, en die volgende herverbinding sal dit uitwis.

As die vereiste is om hierdie gasheer te bereik terwyl die VPN op is, is die eerlike antwoord gewoonlik 'n spesifieke gasheerroete deur die plaaslike router, geïnstalleer deur die netwerkbestuurder wat die koppelvlak besit. As die vereiste is om enigiets direk te bereik, het die vereiste self 'n beleidsoorsig nodig voordat dit 'n roete-opdrag nodig het.