Hvers vegna VPN-leið sýnir enga hlið í úttaki ip route
Lína með tæki og án hliðs er bein leið, ekki brotin. Lestu áfangastað, dev og scope og staðfestu síðan með ip route get.
Leiðatöflur eru lesnar sem brotnar í hvert sinn sem dálkur hliðsins stendur auður, þótt línan sé yfirleitt heil út af fyrir sig. Reiturinn via birtist aðeins þegar kjarninn afhendir pakkann til vistfangs næsta stökks; leið sem er tengd við tengi nær áfangastöðum sínum í staðinn með upplausn á tengilagi eða með jafningja frá punkti til punkts. Að lesa dálkana frá vinstri til hægri segir þér í hvaða tilfelli þú ert, og þá lestur ætti að eiga sér stað áður en einhver breytir sjálfgefinni leið. Flest miðar um hlið sem vantar enda á þessari aðgreiningu.
Lestu leiðarlínu dálk fyrir dálk
Hver færsla hefst á áfangastaðnum og lengd forskeytis hans og bætir síðan við breytum í föstum orðaforða: via, dev, proto, scope, src og metric. Lína eins og 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 er þétt en að fullu skilgreind. Ekkert vantar í hana og engu beinistöðvarfangi er gefið í skyn.
Fjarvera via er áhugaverði hlutinn. Án næsta stökks leysir kjarninn áfangastaðinn beint á tilgreindu tenginu, sem fyrir göng þýðir að afhenda rammann til gagnatækis gangsins og láta umbúðirnar taka við þaðan. proto kernel skráir að færslan hafi verið sett upp sjálfkrafa þegar vistfang var úthlutað, ekki slegin inn af stjórnanda. scope link segir að áfangastaðurinn sé aðgengilegur á þeirri tengingu án þess að fara í gegnum beini, og src nefnir það vistfang sem kjarninn mun velja sem uppruna fyrir samsvarandi umferð.
Lestu nú sjálfgefna leið á sama hátt: default via 192.0.2.254 dev eth0 proto static metric 100. Hér er via til staðar vegna þess að pakkinn þarf vissulega næsta stökk, og það stökk verður sjálft að vera aðgengilegt á eth0. Línurnar tvær eru ekki afbrigði hvor af annarri; þær svara mismunandi spurningum um hvert umferðin fer.
Tvö leiðarform sem ruglast saman
Leið fyrir undirnet göngs og sjálfgefin leið líta svipað út á skjámynd og hegða sér algjörlega öðruvísi. Notaðu töfluna hér að neðan sem lestrarhjálp fyrir reitina og staðfestu síðan rauntölurnar á vélinni sem þú villuleitar í stað þess að treysta sýnishorni úr leiðbeiningum.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Það sem taflan getur ekki sagt þér er ætlunin. Bein leið að einkasviði í gegnum göng er viljandi hönnun skiptra ganga; sama form á hýsli sem ætti að senda allt í gegnum VPN er einkenni. Ætlunin býr í stillingunni sem bjó til færsluna, svo skoðaðu tólið sem setti hana upp áður en þú ályktar að kjarninn hafi gert eitthvað rangt.
Á sama hátt er hlið sem vantar ekki leyfi til að búa hana til. Ef leið þarf sannarlega næsta stökk, verður það stökk að vera aðgengilegt á tenginu sem ber það, og fyrir göng frá punkti til punkts er vistfang jafningjans ekki sami hlutur og staðbundið vistfang. Að meðhöndla staðbundið vistfang gangsins sem Ethernet-beini er algeng leið til að búa til leið sem lítur út fyrir að vera rétt og sendir ekkert áfram.
Spurðu kjarnann hvaða línu hann muni í raun nota
Að lesa töfluna er ekki það sama og að framkvæma uppflettinguna, því kjarninn ráðfærir sig við stefnureglur, nokkrar töflur og skyggðar færslur áður en hann svarar. Sögnin sem framkvæmir raunverulegu uppflettinguna er ip route get, og hún prentar þá leið sem pakki með þessa eiginleika myndi fara.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Skiptu út áfangastaðnum sem þér er raunverulega annt um og bættu síðan við from eða iif þegar umferðin er valin eftir uppruna eða send áfram, því venjuleg staðbundin uppfletting getur valið aðra slóð en áfram sendur biðlari. Svarið nefnir tengið, valið upprunavistfang og hvert næsta stökk, sem eru sömu upplýsingar og pakki yrði beint með á þeirri stundu.
Ef svarið kemur þér á óvart skaltu prenta reglurnar áður en þú breytir nokkru: ip -4 rule show telur þær upp í forgangsröð, og VPN-biðlari sem setur upp sína eigin töflu eða reglu fyrir merktar pakka mun alls ekki birtast í aðaltöflunni. Upptalning allra taflna lokar þessari glufu.
ip -4 route show table all | grep -E 'tun|default'Athugaðu undirlagið áður en þú skiptir út sjálfgefnu leiðinni
Eigin pakkar gangsins verða að ná til fjarlæga endapunktsins, og þeir gera það í gegnum líkamlega tengið með því að nota leiðina sem var til áður en VPN-ið kom upp. Að skipta út allri sjálfgefinni leið án þess að festa þann endapunkt sendir umbúðu pökkunum inn í göngin sem þeir eiga að byggja, og tengingin hrynur. Staðfestu fyrst slóðina að endapunktinum með uppflettingu eingöngu á vistfang endapunktsins.
Haltu þremur hlutum aðskildum þegar þú gerir breytinguna: leiðinni að endapunktinum sem verður að vera á líkamlega tenginu, einkasviðunum sem ættu að fara inn í göngin, og sjálfgefnu leiðinni sem ræður öllu öðru. Skiptu þeim í sundur í þeirri röð, beittu einni í einu og keyrðu uppflettinguna aftur eftir hvert skref. Misheppnað ping eftir á sannar mjög litlu út af fyrir sig, þar sem heimildir, svarleiðsla, DNS og þjónustan sjálf liggja öll neðan við rétta leið.
Skrifaðu niður fjögur gildin sem línan gaf þér fyrir breytinguna: áfangastaður, næsta stökk eða fjarvera þess, tæki og valið upprunavistfang. Ef síðari breyting hreyfir eitthvert þeirra veistu hvaða ákvörðun var í raun breytt, og þú getur endurheimt eina færslu í stað þess að giska á alla töfluna.