Kvifor ei VPN-rute ikkje viser nokon gateway i ip route-utskrifta
Ei linje med ein eining og utan gateway er ei direkte rute, ikkje ei øydelagd. Les destinasjon, dev og scope, og stadfest deretter med ip route get.
Rutetabellar vert lesne som øydelagde kvar gong gateway-kolonnen står tom, sjølv om linja vanlegvis er komplett i seg sjølv. Feltet via viser seg berre når kjernen overlèt pakken til ein neste-hopp-adresse; ei rute knytt til eit grensesnitt når i staden destinasjonane sine via oppslag på lenkjelaget eller via ein punkt-til-punkt-partnar. Å lese kolonnane frå venstre mot høgre fortel deg kva tilfelle du er i, og den lesinga bør skje før nokon redigerer ei standardrute. Dei fleste sakene om ein manglande gateway endar ved denne skilnaden.
Les ei rute kolonne for kolonne
Kvar oppføring byrjar med destinasjonen og lengda på prefikset, og legg deretter til modifikatorar i eit fast vokabular: via, dev, proto, scope, src og metric. Ei linje som 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 er tett, men fullt spesifisert. Ingenting manglar i henne, og inga ruteradresse vert antyda.
Fråværet av via er den interessante delen. Utan ein neste hopp løyser kjernen destinasjonen direkte på det namngjevne grensesnittet, som for ein tunnel tyder å overlevere ramma til tunnel-eininga og la innkapslinga ta over derfrå. proto kernel registrerer at oppføringa vart installert automatisk då ei adresse vart tildelt, ikkje skriven inn av ein administrator. scope link seier at destinasjonen er nåbar på den lenkja utan å passere ein ruter, og src namngjev adressa kjernen vil føretrekke som kjelde for trafikk som samsvarar.
Les no ei standardrute på same måte: default via 192.0.2.254 dev eth0 proto static metric 100. Her er via til stades fordi pakken faktisk treng ein neste hopp, og den hoppen må sjølv vere nåbar på eth0. Dei to linjene er ikkje variantar av kvarandre; dei svarar på ulike spørsmål om kvar trafikken går.
To ruteformer som vert forveksla med kvarandre
Ei tunnelsubnett-rute og ei standardrute ser like ut på eit skjermbilete og oppfører seg heilt ulikt. Bruk tabellen nedanfor som lesehjelp for felta, og stadfest deretter dei faktiske tala på maskina du feilsøkjer i staden for å stole på eit døme frå ei rettleiing.
| 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 |
Det tabellen ikkje kan fortelje deg, er hensikta. Ei direkte rute til eit privat område gjennom ein tunnel er eit medvite design med delt tunnel; den same forma på ein vert som burde sendt alt gjennom VPN-en, er eit symptom. Hensikta bur i konfigurasjonen som skapte oppføringa, så sjå på verktøyet som installerte henne før du konkluderer med at kjernen gjorde noko gale.
På same måte er ein manglande gateway ikkje løyve til å finne opp ein. Viss ei rute verkeleg treng ein neste hopp, må den hoppen vere nåbar på grensesnittet som ber han, og for ein punkt-til-punkt-tunnel er adressa til partnaren ikkje det same objektet som den lokale adressa. Å handsame den lokale tunneladressa som ein Ethernet-ruter er ein vanleg måte å lage ei rute som ser rett ut og ikkje videresender noko.
Spør kjernen kva linje han faktisk vil bruke
Å lese tabellen er ikkje det same som å utføre oppslaget, fordi kjernen rådfører seg med policyreglar, fleire tabellar og hurtiglagra oppføringar før han svarar. Verbet som utfører det eigentlege oppslaget, er ip route get, og det skriv ut ruta ein pakke med desse eigenskapane ville ta.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Bytt inn destinasjonen du faktisk bryr deg om, og legg deretter til from eller iif når trafikken er vald etter kjelde eller videresend, fordi eit vanleg lokalt oppslag kan velje ein annan veg enn ein videresend klient. Svaret namngjev grensesnittet, den valde kjeldeadressa og ein eventuell neste hopp, som er den same informasjonen ein pakke ville vorte ruta med i det augneblinken.
Viss svaret overraskar deg, skriv ut reglane før du endrar noko: ip -4 rule show listar dei i prioritetsrekkjefølgje, og ein VPN-klient som installer sin eigen tabell eller ein regel for merkte pakkar, vil ikkje visast i hovudtabellen i det heile. Å liste alle tabellar lukkar dette gapet.
ip -4 route show table all | grep -E 'tun|default'Sjekk underlaget før du erstattar standardruta
Tunnelens eigne pakkar må nå det eksterne endepunktet, og det gjer dei gjennom det fysiske grensesnittet ved hjelp av ruta som fanst før VPN-en kom opp. Å erstatte heile standardruta utan å feste det endepunktet sender dei innkapsla pakkane inn i tunnelen dei skal byggje, og sambandet kollapsar. Stadfest først vegen til endepunktet med eit oppslag berre på endepunktadressa.
Hald tre ting åtskilde når du gjer endringa: endepunktruta som må bli verande på det fysiske grensesnittet, dei private områda som skal inn i tunnelen, og standardruta som avgjer alt anna. Del dei opp i den rekkjefølgja, bruk éin om gongen, og køyr oppslaget på nytt etter kvart steg. Ein mislukka ping etterpå beviser svært lite i seg sjølv, sidan løyve, svar-ruting, DNS og tenesta sjølv alle ligg nedstraums for ei korrekt rute.
Skriv ned dei fire verdiane linja gav deg før endringa: destinasjon, neste hopp eller fråværet av det, eining og vald kjelde. Viss ei seinare endring flyttar nokon av dei, veit du kva avgjerd som faktisk vart endra, og du kan gjenopprette éi oppføring i staden for å gjette på heile tabellen.