Kāpēc route -interface nesasniedz saimnieku ārpus saites

route pieņem Wi-Fi interfeisa nosaukumu, iziet bez sūdzībām, un saimnieks paliek nesasniedzams. Nekas nav bojāts; attiecības maršrutā vienkārši ir nepareizas: interfeisa karodziņš pasaka, kurā saitē atrodas galamērķis, nevis kurš maršrutētājs saņem satiksmi galamērķim, kas atrodas citur. Komanda izdodas tāpēc, ka tā ir sintaktiski derīga, nevis tāpēc, ka tā apraksta strādājošu ceļu.

Šī atšķirība nosaka, vai maršruta izņēmums blakus VPN strādās, vai tikai izskatīsies ticami.

Interfeiss ir izeja, nākamais lēciens ir nodošana

Mac datorā ar adresi 192.168.50.20 un maršrutētāju 192.168.50.1 cita mašīna tajā pašā saitē ir sasniedzama tieši. Kadrs tiek adresēts šai mašīnai un novietots uz vada. Maršrutētājs nepiedalās, un interfeisam piesaistīts maršruts izsaka tieši to. Nomainiet tālo galu uz saimnieku citā ēkā, un tā pati komanda zaudē jēgu. Mac nav otrā slāņa adreses, ko novietot uz vada, tāpēc interfeisa karodziņam nav ko aprakstīt.

Galamērķis ārpus saites ir citāds. Mac nevar novietot uz vada kadru, kas adresēts saimniekam, kuru tas nesasniedz otrajā slānī; tas nodod paketi maršrutētājam, kas to var. Tāpēc maršrutam ir vajadzīga vārteja, un pašai vārtejai jābūt sasniedzamai pievienotajā saitē.

Interfeisa karodziņa izmantošana galamērķim ārpus saites pasaka macOS izturēties pret šo galamērķi tā, it kā tas būtu uz vada. Tad kodols nespēj atrisināt otrā slāņa adresi tam, un pakete tiek izmesta bez nekā noderīga kļūdā.

Ko interfeisa karodziņš patiešām apgalvo

Apple maršrutu uzziņa definē interfeisa formu galamērķiem, kas ir tieši sasniedzami bez starpnieka. Tas ir apgalvojums par saites modeli, nevis izvēle par to, kuru adapteri izmantot. Sasniegt interneta saimnieku ar Wi-Fi joprojām prasa maršrutētāju šajā Wi-Fi saitē, un maršrutam tas ir jānosauc.

Interfeisa tvērums ir atsevišķs atribūts. Tas saista maršrutu ar konkrētu interfeisu tvēruma lēmumiem, piemēram, kura avota adrese ir spēkā, bet tas nerada sasniedzamību galamērķim, kuru interfeiss pats nesasniedz. Abi atribūti atbild uz dažādiem jautājumiem.

Tāpēc komanda var tikt pieņemta, parādīties tabulā un tomēr neizdoties. Kodols nevalidē jūsu nodomu; tas reģistrē to, ko jūs apgalvojāt, un apgalvojums bija, ka galamērķis ir saitē. Klusa veiksme, kam seko klusa nomešana, ir gaidītais iznākums, nevis kļūda. Izlasiet apgalvojumu vēlreiz, pirms vainojat tīklu.

Maršruts, kas vajadzīgs galamērķim ārpus saites

Apstiprinātam ceļam uz dokumentācijas adresi, piemēram, 198.51.100.25, caur LAN maršrutētāju paredzētās attiecības ir galamērķis, nākamais lēciens 192.168.50.1 un LAN interfeiss, kas sasniedz šo nākamo lēcienu. Interfeiss izriet no nākamā lēciena meklēšanas, nevis tiek uzspiests ar route komandu.

macOS tikai lasīšanas pārbaude ir route -n get 198.51.100.25. Lasiet vārtejas un interfeisa rindas kopā un pārbaudiet, vai vārteja ir adrese, kuru Mac patiešām sasniedz. Vārteja citā apakštīklā vai tāda, kas pazudusi kopš pēdējās tīkla izmaiņas, rada maršrutu, kas izskatās pareizi un neko nepiegādā.

Necietiniet en0 ilgstošā instrukcijā. Interfeisu nosaukumi mainās līdz ar adapteriem, dokiem un VPN klientiem, un maršruts, kas nosauc nepareizo, neizdodas tā, ka to viegli pārprast kā plašāku tīkla kļūmi.

Izlasiet pašreizējo izvēli, pirms to aizstājat

Pirms kaut ko pievienot, pārbaudiet, ko sistēma jau izvēlējusies un kāpēc. Šī izvade pasaka, vai satiksme iet caur tuneli, caur LAN maršrutētāju vai nekur, un dod bāzes līniju salīdzināšanai pēc izmaiņām. Bez tās jūs nevarat pateikt, vai jaunais maršruts ir stājies spēkā.

Pēc tam pārbaudiet adrešu saimi. Maršruts, kas pievienots IPv4, neko nedara IPv6 galamērķim, un pakalpojums, kas atrisinās abās saimēs, var šķist periodiski sasniedzams. Maršrutu tabula un atrisinātājs atbild uz dažādiem jautājumiem, un abiem jāsaskan ar paredzēto ceļu.

Visbeidzot, atcerieties, ka maršruts ir izvēle, nevis atļauja. Pārvaldīts VPN profils vai klienta filtrs joprojām var aizliegt tiešo ceļu, pat ja tabula uz to norāda, tāpēc testējiet ar īsto lietojumprogrammu, nevis pieņemiet, ka veiksmīgs tabulas ieraksts beidz izmeklēšanu.

Tuneļi un politika maina formu

Punkts-punkts interfeisi ir atsevišķs gadījums. Tunelis var nest maršrutu bez Ethernet stila vārtejas adreses, un tas nav automātiski nepareizi. Piemērojiet interfeisa īsto saites modeli, nevis paplašiniet Wi-Fi piemēru uz katru redzamo tabulas ierakstu.

Izmaiņu pieprasījumiem pierakstiet galamērķi, apstiprināto tīkla ceļu, pašreizējo vārteju un interfeisu un to, kam jāuztur izņēmums. Īpašnieks ir svarīgs, jo vienreizējs maršruts, kas ierakstīts komandu rindā, nav politika, un nākamā atkārtotā savienošanās to izdzēsīs.

Ja prasība ir sasniegt šo saimnieku, kamēr VPN ir ieslēgts, godīgā atbilde parasti ir konkrēts saimnieka maršruts caur vietējo maršrutētāju, ko instalē tīkla pārvaldnieks, kuram pieder interfeiss. Ja prasība ir sasniegt jebko tieši, pašai prasībai vispirms vajadzīga politikas pārskatīšana, nevis route komanda.