Miért nem ér el a route -interface egy kapcsolaton kívüli gazdagépet

A route elfogadja a Wi-Fi-interfész nevét, panaszkodás nélkül kilép, és a gazdagép továbbra is elérhetetlen. Semmi sem sérült meg; az útvonalban lévő viszony egyszerűen hibás: az interfész-jelző azt mondja meg, melyik kapcsolaton van a cél, nem azt, melyik router kapja a forgalmat egy máshol lévő cél számára. A parancs azért sikerül, mert szintaktikailag érvényes, nem azért, mert működő utat ír le.

Ez a különbség dönti el, hogy a VPN melletti útvonal-kivétel működik-e, vagy csak hihetőnek látszik.

Az interfész a kijárat, a következő ugrás az átadás

Egy 192.168.50.20 című Macen és egy 192.168.50.1 címen lévő routerrel az ugyanazon a kapcsolaton lévő másik gép közvetlenül elérhető. A keret ehhez a géphez van címezve, és a vezetékre kerül. Router nem vesz részt benne, és az interfészhez kötött útvonal pontosan ezt fejezi ki. Változtassa meg a távoli véget egy másik épületben lévő gazdagépre, és ugyanez a parancs értelmét veszti. A Macnek nincs második rétegbeli címe, amit a vezetékre tehetne, így az interfész-jelzőnek nincs mit leírnia.

A kapcsolaton kívüli cél más. A Mac nem tehet a vezetékre olyan keretet, amely egy olyan gazdagépnek van címezve, amelyet a második rétegen nem ér el; átadja a csomagot egy routernek, amely igen. Az útvonalnak tehát átjáró kell, és magának az átjárónak is elérhetőnek kell lennie a csatlakoztatott kapcsolaton.

Ha az interfész-jelzőt kapcsolaton kívüli célra használja, a macOS úgy kezeli a célt, mintha a vezetéken lenne. Ekkor a kernel nem tud második rétegbeli címet feloldani hozzá, és a csomag eldobódik, anélkül hogy a hiba bármi hasznosat tartalmazna.

Mit állít valójában az interfész-jelző

Az Apple útvonal-referenciája az interfész-formát a közvetítő nélkül közvetlenül elérhető célokra definiálja. Ez a kapcsolatmodellről szóló állítás, nem pedig az adapter kiválasztására vonatkozó preferencia. Egy internetes gazdagép Wi-Fi-n keresztüli elérése továbbra is routert igényel azon a Wi-Fi-kapcsolaton, és az útvonalnak meg kell neveznie azt.

Az interfész-hatókör külön attribútum. Egy útvonalat egy adott interfészhez rendel a hatókör-döntésekhez, például hogy melyik forráscím érvényes, de nem teremt elérhetőséget olyan cél számára, amelyet az interfész önmagában nem ér el. A két attribútum különböző kérdésekre válaszol.

Ezért lehet egy parancs elfogadott, megjelenhet a táblázatban, és mégis meghiúsulhat. A kernel nem ellenőrzi a szándékát; rögzíti, amit állított, és az állítás az volt, hogy a cél a kapcsolaton van. A csendes siker után következő csendes eldobás a várt eredmény, nem hiba. Olvassa vissza magának az állítást, mielőtt a hálózatot hibáztatná.

Az útvonal, amelyre egy kapcsolaton kívüli célnak szüksége van

Egy jóváhagyott útvonalhoz egy olyan dokumentációs címhez, mint 198.51.100.25, a LAN-routeren keresztül a szándékolt viszony: cél, 192.168.50.1 következő ugrása, és a LAN-interfész, amely eléri azt a következő ugrást. Az interfész a következő ugrás kereséséből adódik, nem pedig a route parancs kényszeríti ki.

A macOS-en a csak olvasható vizsgálat a route -n get 198.51.100.25. Olvassa együtt az átjáró és az interfész sorait, és ellenőrizze, hogy az átjáró olyan cím-e, amelyet a Mac ténylegesen elér. Egy másik alhálózaton lévő átjáró, vagy amelyik eltűnt az utolsó hálózati változás óta, olyan útvonalat hoz létre, amely helyesnek látszik és semmit nem továbbít.

Ne kódolja be a en0 értékét tartós utasításba. Az interfésznevek adapterekkel, dokkolókkal és VPN-kliensekkel változnak, és a rosszat megnevező útvonal olyan módon hibázik, amely könnyen szélesebb hálózati hibának tűnik.

Olvassa el a jelenlegi választást, mielőtt lecseréli

Mielőtt bármit hozzáadna, vizsgálja meg, mit választott már a rendszer, és miért. Az a kimenet megmondja, hogy a forgalom az alagúton, a LAN-routeren vagy sehova nem megy, és alapvonalat ad a változás utáni összehasonlításhoz. Enélkül nem tudhatja, hogy az új útvonal hatályba lépett-e.

Ezután ellenőrizze a címcsaládot. Az IPv4-hez hozzáadott útvonal semmit nem tesz egy IPv6-célért, és egy mindkét családba feloldódó szolgáltatás időszakosan elérhetőnek tűnhet. Az útválasztási tábla és a feloldó különböző kérdésekre válaszol, és mindkettőnek egyeznie kell a szándékolt úttal.

Végül ne feledje, hogy az útvonal kiválasztás, nem engedély. Egy felügyelt VPN-profil vagy egy kliensszűrő továbbra is megtilthatja a közvetlen utat, még akkor is, ha a tábla arra mutat, ezért a tényleges alkalmazással teszteljen, ahelyett hogy feltételezné, hogy egy sikeres táblázatbejegyzés lezárja a vizsgálatot.

Az alagutak és a szabályzatok megváltoztatják a formát

A pont-pont interfészek külön esetek. Egy alagút Ethernet-stílusú átjárócím nélkül is hordozhat útvonalat, és ez nem automatikusan hiba. Az interfész valódi kapcsolatmodelljét alkalmazza, ahelyett hogy egy Wi-Fi-példát kiterjesztene minden látott táblázatbejegyzésre.

Változási kérésekhez írja le a célt, a jóváhagyott hálózati utat, a jelenlegi átjárót és interfészt, valamint hogy ki fogja karbantartani a kivételt. A tulajdonos számít, mert a parancssorba beírt egyszeri útvonal nem szabályzat, és a következő újracsatlakozás törli.

Ha a követelmény az, hogy elérje ezt a gazdagépet a VPN bekapcsolása alatt, az őszinte válasz általában egy adott gazdagép-útvonal a helyi routeren keresztül, amelyet az interfészt birtokló hálózatkezelő telepít. Ha a követelmény az, hogy közvetlenül bármit elérjen, magának a követelménynek van szüksége szabályzat-felülvizsgálatra, mielőtt route parancsra lenne szüksége.