Wêrom route -interface in gasthear bûten de ferbining net berikke kin

route akseptearret de Wi-Fi-ynterfacenamme, einiget sûnder klacht, en de gasthear bliuwt ûnberikber. Neat is skansearre; de relaasje yn 'e rûte is gewoan ferkeard: in ynterfaceflag seit op hokker ferbining in bestimming leit, net hokker router ferkear ûntfange moat foar in bestimming dy't earne oars leit. It kommando slagget om't it syntaktysk jildich is, net om't it in wurkjende paad beskriuwt.

Dat ûnderskied beslút oft in rûte-útsûndering njonken in VPN wurkje sil of allinnich leauweaardich liket.

It ynterface is de útgong, de folgjende sprong is de oerdracht

Op in Mac mei adres 192.168.50.20 en in router op 192.168.50.1 is in oare masine op deselde ferbining direkt berikber. It frame wurdt nei dy masine adressearre en op 'e tried set. Gjin router is belutsen, en in rûte beheind ta it ynterface drukt krekt dat út. Feroarje it fiere ein nei in gasthear yn in oar gebou en itselde kommando hat gjin betsjutting mear. De Mac hat gjin adres fan 'e twadde laach om op 'e tried te setten, dus it ynterfaceflag hat neat te beskriuwen.

In bestimming bûten de ferbining is oars. De Mac kin gjin frame op 'e tried sette dat nei in gasthear adressearre is dy't er op 'e twadde laach net berikt; hy jout it pakket oan in router dy't dat kin. De rûte hat dêrom in poarte nedich, en de poarte sels moat berikber wêze op 'e oansletten ferbining.

It ynterfaceflag brûke foar in bestimming bûten de ferbining fertelt macOS de bestimming te behanneljen as wie se op 'e tried. Dan slagget de kearn der net yn in adres fan 'e twadde laach dêrfoar op te lossen, en it pakket wurdt weilitten sûnder eat nuttich yn 'e flater.

Wat it ynterfaceflag eins beweart

Apple's rûteferwizing definiearret de ynterfacefoarm foar bestimmingen dy't direkt berikber binne sûnder tuskenpersoan. It is in útspraak oer it ferbiningsmodel, net in foarkar oer hokker adapter te brûken. In ynternetgasthear berikke fia Wi-Fi freget noch altyd in router op dy Wi-Fi-ferbining, en de rûte moat dy neame.

Ynterfaceberik is in apart attribút. It ferbynt in rûte mei in bepaald ynterface foar berikbesluten lykas hokker boarne-adres jildt, mar it makket gjin berikberens foar in bestimming dy't it ynterface sels net berikke kin. De twa attributen beantwurdzje ferskate fragen.

Dêrom kin in kommando akseptearre wurde, yn 'e tabel ferskine en dochs mislearje. De kearn falidearret jo bedoeling net; it registrearret wat jo bewearden, en de bewearing wie dat de bestimming op 'e ferbining is. Stille súkses folge troch stil weilitten is it ferwachte resultaat, gjin bug. Lês de bewearing ris werom foar't jo it netwurk de skuld jouwe.

De rûte dy't in bestimming bûten de ferbining nedich hat

Foar in goedkarde paad nei in dokumintaasje-adres lykas 198.51.100.25 fia de LAN-router is de bedoelde relaasje in bestimming, in folgjende sprong fan 192.168.50.1, en it LAN-ynterface dat dy folgjende sprong berikt. It ynterface wurdt ymplisearre troch it sykjen fan 'e folgjende sprong ynstee fan troch it rûtekommando twongen.

Op macOS is de lês-allinnich-ynspeksje route -n get 198.51.100.25. Lês de poarte- en ynterfaceregels tegearre en kontrolearje dat de poarte in adres is dy't de Mac echt berikke kin. In poarte op in oar subnet, of ien dy't sûnt de lêste netwurkferoaring fuort is, leveret in rûte op dy't korrekt liket en neat trochstjoert.

Hardkoadeje en0 net yn in duorjende ynstruksje. Ynterfacenammen feroarje mei adapters, dokken en VPN-klanten, en in rûte dy't de ferkearde neamt mislearret op in manier dy't maklik as in breder netwurkdefekt lêzen wurdt.

Lês de hjoeddeiske kar foar't jo him ferfange

Foar't jo eat tafoegje, ûndersykje wat it systeem al keazen hat en wêrom. Dy útfier fertelt oft ferkear troch de tunnel, troch de LAN-router of nearne giet, en jout in basisline om nei de feroaring te fergelykjen. Sûnder dat kinne jo net sizze oft de nije rûte wurke hat.

Kontrolearje dan de adresfamylje. In rûte tafoege foar IPv4 docht neat foar in IPv6-bestimming, en in tsjinst dy't nei beide famyljes oplost kin tuskenskofts berikber lykje. De rûtetabel en de oplosser beantwurdzje ferskate fragen, en beide moatte oerienkomme mei it bedoelde paad.

Unthâld úteinlik dat in rûte in kar is, gjin tastimming. In beheard VPN-profyl of in kliïntfilter kin it direkte paad noch altyd ferbiede, sels as de tabel dêrhinne wiist, dus test mei de echte applikaasje ynstee fan oan te nimmen dat in suksesfolle tabelynfier it ûndersyk einiget.

Tunnels en belied feroarje de foarm

Punt-nei-punt-ynterfaces binne har eigen gefal. In tunnel kin in rûte drage sûnder in poarte-adres yn Ethernet-styl, en dat is net automatysk ferkeard. Pas it echte ferbiningsmodel fan it ynterface ta ynstee fan in Wi-Fi-foarbyld út te wreidzjen nei elke tabelynfier dy't jo sjogge.

Foar feroaringsfersiken skriuw de bestimming, it goedkarde netwurkpaad, de hjoeddeiske poarte en it ynterface del, en wa't ferwachte wurdt de útsûndering te ûnderhâlden. De eigner is fan belang, want in ienmalige rûte dy't by de prompt yntype is, is gjin belied, en de folgjende werferbining sil him wiskje.

As de eask is om dizze gasthear te berikken wylst de VPN oan is, is it earlike antwurd meastentiids in spesifike gasthear-rûte fia de lokale router, ynstallearre troch de netwurkbehearder dy't it ynterface besit. As de eask is om alles direkt te berikken, hat de eask sels in beliedsresinsje nedich foar't er in rûtekommando nedich hat.