Miks route -interface ei jõua lingivälise hostini

route võtab Wi-Fi-liidese nime vastu, väljub ilma kaebuseta ja host jääb kättesaamatuks. Miski pole rikutud; marsruudi seos on lihtsalt vale: liidese lipp ütleb, millisel lingil sihtkoht asub, mitte milline ruuter peab saama liiklust sihtkohale, mis asub mujal. Käsk õnnestub, sest see on süntaktiliselt korrektne, mitte sellepärast, et see kirjeldaks töötavat teed.

See erinevus otsustab, kas VPN-i kõrval olev marsruudierand töötab või ainult näib usutav.

Liides on väljapääs, järgmine hüpe on üleandmine

Macil aadressiga 192.168.50.20 ja ruuteriga 192.168.50.1 on teine masin samal lingil otseselt kättesaadav. Kaader adresseeritakse sellele masinale ja pannakse juhtmele. Ükski ruuter ei osale ja liidesega piiratud marsruut väljendab täpselt seda. Muutke kaugem ots teises hoones asuvaks hostiks ja sama käsk kaotab mõtte. Macil pole teise kihi aadressi, mille juhtmele panna, seega pole liidese lipul midagi kirjeldada.

Väljaspool linki olev sihtkoht on teistsugune. Mac ei saa juhtmele panna kaadrit, mis on adresseeritud hostile, kelleni ta teisel kihil ei jõua; ta annab paketi üle ruuterile, kes saab. Marsruut vajab seega lüüsi ja lüüs ise peab olema ühendatud lingil kättesaadav.

Liidese lipu kasutamine lingivälise sihtkoha jaoks ütleb macOS-ile kohelda seda sihtkohta nii, nagu oleks see juhtmel. Siis ei suuda tuum selle jaoks teise kihi aadressi lahendada ja pakett visatakse kõrvale, ilma et veas oleks midagi kasulikku.

Mida liidese lipp tegelikult väidab

Apple'i marsruudiviide määratleb liidese vormi sihtkohtadele, mis on otseselt kättesaadavad ilma vahendajata. See on väide lingimudeli kohta, mitte eelistus selle kohta, millist adapterit kasutada. Interneti-hostini jõudmine Wi-Fi kaudu nõuab endiselt ruuterit sellel Wi-Fi-lingil ja marsruut peab selle nimetama.

Liidese ulatus on eraldi atribuut. See seob marsruudi kindla liidesega ulatusotsuste jaoks, näiteks milline lähteaadress kehtib, kuid ei loo kättesaadavust sihtkohale, milleni liides ise ei jõua. Need kaks atribuuti vastavad erinevatele küsimustele.

Seetõttu võidakse käsk vastu võtta, see tabelisse ilmuda ja siiski ebaõnnestuda. Tuum ei valideeri teie kavatsust; see registreerib, mida te väitsite, ja väide oli, et sihtkoht on lingil. Vaikne edu, millele järgneb vaikne kõrvaleviskamine, on oodatud tulemus, mitte viga. Lugege väide endale uuesti ette, enne kui võrku süüdistate.

Marsruut, mida lingiväline sihtkoht vajab

Dokumentatsiooniaadressile nagu 198.51.100.25 LAN-ruuteri kaudu kinnitatud tee jaoks on kavatsetud seos sihtkoht, järgmine hüpe 192.168.50.1 ja LAN-liides, mis selle järgmise hüppeni jõuab. Liides tuleneb järgmise hüppe otsingust, mitte ei sunni seda marsruudikäsk.

macOS-is on ainult lugemiseks kontroll route -n get 198.51.100.25. Lugege lüüsi ja liidese read koos ning kontrollige, et lüüs on aadress, milleni Mac tegelikult jõuab. Lüüs teises alamvõrgus või selline, mis on pärast viimast võrgu muudatust kadunud, annab marsruudi, mis näib õige ja ei edasta midagi.

Ärge kõvakodeerige en0 püsivasse juhisesse. Liidese nimed muutuvad adapterite, dokkide ja VPN-klientidega ning vale nime kasutav marsruut ebaõnnestub viisil, mida on lihtne ekslikult pidada laiemaks võrguveaks.

Lugege praegust valikut enne selle asendamist

Enne millegi lisamist uurige, mille süsteem on juba valinud ja miks. See väljund ütleb, kas liiklus läheb tunnelist, LAN-ruuterist või mitte kuskilt, ja annab aluse võrdlemiseks pärast muudatust. Ilma selleta ei saa te teada, kas uus marsruut mõjule pääses.

Seejärel kontrollige aadressiperekonda. IPv4 jaoks lisatud marsruut ei tee IPv6 sihtkoha jaoks midagi ja mõlemasse perekonda lahenduv teenus võib tunduda aeg-ajalt kättesaadav. Marsruuditabel ja lahendaja vastavad erinevatele küsimustele ning mõlemad peavad kavatsetud teega kokku langema.

Lõpuks pidage meeles, et marsruut on valik, mitte luba. Hallatav VPN-profiil või kliendifilter võib otsese tee siiski keelata, isegi kui tabel sellele osutab, seega testige tegeliku rakendusega, selle asemel et eeldada, et õnnestunud tabelikirje lõpetab uurimise.

Tunnelid ja poliitika muudavad kuju

Punkt-punkt-liidesed on omaette juhtum. Tunnel võib kanda marsruuti ilma Etherneti-stiilis lüüsiaadressita ja see pole automaatselt vale. Rakendage liidese tegelikku lingimudelit, selle asemel et laiendada Wi-Fi näidet igale tabelikirjele, mida näete.

Muudatustaotluste jaoks kirjutage üles sihtkoht, kinnitatud võrgutee, praegune lüüs ja liides ning kes peaks erandit hooldama. Omanik on oluline, sest viipale trükitud ühekordne marsruut ei ole poliitika ja järgmine taasühendus kustutab selle.

Kui nõue on jõuda selle hostini VPN-i töötamise ajal, on aus vastus tavaliselt konkreetne hosti marsruut kohaliku ruuteri kaudu, mille paigaldab liidest omav võrguhaldur. Kui nõue on jõuda millenigi otse, vajab nõue ise poliitika ülevaatamist enne, kui vajab marsruudikäsku.