Kial route -interface ne atingas gastiganton ekster la ligo

route akceptas la nomon de la Wi-Fi-interfaco, eliras sen plendo, kaj la gastiganto restas neatingebla. Nenio estas difektita; la rilato en la vojo simple malĝustas: interfaca flago diras, sur kiu ligo celo troviĝas, ne kiu enkursigilo devas ricevi trafikon por celo, kiu estas aliloke. La komando sukcesas ĉar ĝi estas sintakse valida, ne ĉar ĝi priskribas funkciantan vojon.

Tiu distingo decidas, ĉu voja escepto apud VPN funkcios aŭ nur ŝajnos kredinda.

La interfaco estas la eliro, la sekva salto estas la transdono

Sur Mac kun adreso 192.168.50.20 kaj enkursigilo ĉe 192.168.50.1, alia maŝino sur la sama ligo estas rekte atingebla. La kadro estas adresita al tiu maŝino kaj metita sur la draton. Neniu enkursigilo partoprenas, kaj interfac-lima vojo esprimas ĝuste tion. Ŝanĝu la malproksiman finon al gastiganto en alia konstruaĵo, kaj la sama komando ĉesas havi sencon. La Mac ne havas adreson de dua tavolo por meti sur la draton, do la interfaca flago havas nenion por priskribi.

Celo ekster la ligo estas alia. La Mac ne povas meti sur la draton kadron adresitan al gastiganto, kiun ĝi ne atingas sur la dua tavolo; ĝi transdonas la paketon al enkursigilo, kiu povas. La vojo do bezonas pordegon, kaj la pordego mem devas esti atingebla sur la alkroĉita ligo.

Uzi la interfacan flagron por celo ekster la ligo diras al macOS trakti tiun celon kvazaŭ ĝi estus sur la drato. Tiam la kerno malsukcesas solvi adreson de dua tavolo por ĝi, kaj la paketo estas forĵetita sen io utila en la eraro.

Kion la interfaca flago fakte asertas

La voja referenco de Apple difinas la interfacan formon por celoj rekte atingeblaj sen peranto. Ĝi estas aserto pri la liga modelo, ne prefero pri tio, kiun adaptilon uzi. Atingi interretan gastiganton per Wi-Fi ankoraŭ postulas enkursigilon sur tiu Wi-Fi-ligo, kaj la vojo devas nomi ĝin.

Interfaca amplekso estas aparta atributo. Ĝi ligas vojon al aparta interfaco por ampleksaj decidoj kiel kiu fonta adreso validas, sed ĝi ne kreas atingebl-econ por celo, kiun la interfaco ne povas atingi mem. La du atributoj respondas malsamajn demandojn.

Tial komando povas esti akceptita, aperi en la tabelo kaj tamen malsukcesi. La kerno ne validigas vian intencon; ĝi registras tion, kion vi asertis, kaj la aserto estis, ke la celo estas sur la ligo. Silenta sukceso sekvata de silenta forĵeto estas la atendata rezulto, ne cimo. Relutu la aserton al vi mem antaŭ ol kulpigi la reton.

La vojo, kiun celo ekster la ligo bezonas

Por aprobita vojo al dokumenta adreso kiel 198.51.100.25 tra la LAN-enkursigilo, la intencita rilato estas celo, sekva salto de 192.168.50.1, kaj la LAN-interfaco, kiu atingas tiun sekvan salton. La interfaco estas implicita de la serĉo de la sekva salto anstataŭ devigita de la voja komando.

En macOS la lega inspektado estas route -n get 198.51.100.25. Legu la liniojn de pordego kaj interfaco kune kaj kontrolu, ke la pordego estas adreso, kiun la Mac povas efektive atingi. Pordego en alia subreto, aŭ unu, kiu malaperis post la lasta reta ŝanĝo, produktas vojon, kiu aspektas ĝusta kaj plusendas nenion.

Ne fiksu en0 en daŭra instrukcio. Interfacaj nomoj ŝanĝiĝas kun adaptiloj, dokoj kaj VPN-klientoj, kaj vojo, kiu nomas la malĝustan, malsukcesas tiel, ke oni facile mislegas ĝin kiel pli vastan retan difekton.

Legu la nunan elekton antaŭ ol anstataŭigi ĝin

Antaŭ ol aldoni ion, inspektu, kion la sistemo jam elektis kaj kial. Tiu eligo diras, ĉu trafiko iras tra la tunelo, tra la LAN-enkursigilo aŭ nenie, kaj ĝi donas bazlinion por kompari post la ŝanĝo. Sen ĝi vi ne povas diri, ĉu la nova vojo ekvalidis.

Poste kontrolu la adresan familion. Vojo aldonita por IPv4 faras nenion por IPv6-celo, kaj servo, kiu solviĝas al ambaŭ familioj, povas ŝajni intermita atingebla. La voja tabelo kaj la solvilo respondas malsamajn demandojn, kaj ambaŭ devas kongrui kun la intencita vojo.

Fine, memoru, ke vojo estas elekto, ne permeso. Administrita VPN-profilo aŭ klienta filtrilo ankoraŭ povas malpermesi la rektan vojon eĉ kiam la tabelo montras al ĝi, do testu per la reala aplikaĵo anstataŭ supozi, ke sukcesa tabula enskribo finas la esploron.

Tuneloj kaj politiko ŝanĝas la formon

Punkt-al-punktaj interfacoj estas sia propra kazo. Tunelo povas porti vojon sen pordega adreso laŭ Ethernet-stilo, kaj tio ne estas aŭtomate malĝusta. Apliku la realan ligan modelon de la interfaco anstataŭ etendi Wi-Fi-ekzemplon al ĉiu tabula enskribo, kiun vi vidas.

Por ŝanĝpetoj, notu la celon, la aprobitan retan vojon, la nunan pordegon kaj interfacon, kaj kiu devos prizorgi la escepton. La posedanto gravas, ĉar unufoja vojo tajpita ĉe la prompto ne estas politiko, kaj la sekva rekonekto forviŝos ĝin.

Se la postulo estas atingi ĉi tiun gastiganton dum la VPN estas aktiva, la honesta respondo kutime estas specifa gastiganta vojo tra la loka enkursigilo, instalita de la reta administranto, kiu posedas la interfacon. Se la postulo estas atingi ion ajn rekte, la postulo mem bezonas politikan revizion antaŭ ol ĝi bezonas vojan komandon.