Hvorfor en VPN-rute ikke viser noen gateway i ip route-utskriften
En linje med en enhet og uten gateway er en direkte rute, ikke en ødelagt. Les destinasjon, dev og scope, og bekreft deretter med ip route get.
Rutingtabeller leses ofte som ødelagte hver gang gateway-kolonnen står tom, selv om linjen vanligvis er komplett i seg selv. Feltet via vises bare når kjernen overlater pakken til en neste-hopp-adresse; en rute knyttet til et grensesnitt når i stedet destinasjonene sine via oppslag på lenkelaget eller via en punkt-til-punkt-partner. Å lese kolonnene fra venstre mot høyre forteller deg hvilket tilfelle du er i, og den lesningen bør skje før noen redigerer en standardrute. De fleste sakene om en manglende gateway ender ved denne forskjellen.
Les en rute kolonne for kolonne
Hver oppføring begynner med destinasjonen og lengden på prefikset, og legger deretter til modifikatorer i et fast vokabular: via, dev, proto, scope, src og metric. En linje som 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 er tett, men fullt spesifisert. Ingenting mangler i den, og ingen ruteradresse antydes.
Fraværet av via er den interessante delen. Uten en neste hopp løser kjernen destinasjonen direkte på det navngitte grensesnittet, som for en tunnel betyr å overlevere rammen til tunnel-enheten og la innkapslingen ta over derfra. proto kernel registrerer at oppføringen ble installert automatisk da en adresse ble tildelt, ikke skrevet inn av en administrator. scope link sier at destinasjonen er nåbar på den lenken uten å passere en ruter, og src navngir adressen kjernen vil foretrekke som kilde for trafikk som samsvarer.
Les nå en standardrute på samme måte: default via 192.0.2.254 dev eth0 proto static metric 100. Her er via til stede fordi pakken faktisk trenger et neste hopp, og det hoppet må selv være nåbart på eth0. De to linjene er ikke varianter av hverandre; de svarer på forskjellige spørsmål om hvor trafikken går.
To ruteformer som forveksles med hverandre
En tunnelsubnett-rute og en standardrute ser like ut på et skjermbilde og oppfører seg helt forskjellig. Bruk tabellen nedenfor som lesehjelp for feltene, og bekreft deretter de faktiske tallene på maskinen du feilsøker i stedet for å stole på et eksempel fra en veiledning.
| 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 ikke kan fortelle deg, er hensikten. En direkte rute til et privat område gjennom en tunnel er et bevisst design med delt tunnel; den samme formen på en vert som burde sende alt gjennom VPN-en, er et symptom. Hensikten bor i konfigurasjonen som skapte oppføringen, så se på verktøyet som installerte den før du konkluderer med at kjernen gjorde noe galt.
På samme måte er en manglende gateway ikke tillatelse til å finne opp en. Hvis en rute virkelig trenger et neste hopp, må det hoppet være nåbart på grensesnittet som bærer det, og for en punkt-til-punkt-tunnel er partnerens adresse ikke det samme objektet som den lokale adressen. Å behandle den lokale tunneladressen som en Ethernet-ruter er en vanlig måte å lage en rute som ser riktig ut og ikke videresender noe.
Spør kjernen hvilken linje den faktisk vil bruke
Å lese tabellen er ikke det samme som å utføre oppslaget, fordi kjernen konsulterer policyregler, flere tabeller og hurtiglagrede oppføringer før den svarer. Verbet som utfører det egentlige oppslaget, er ip route get, og det skriver ut ruten en pakke med disse egenskapene 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 kildevalgt eller videresendt, fordi et vanlig lokalt oppslag kan velge en annen vei enn en videresendt klient. Svaret navngir grensesnittet, den valgte kildeadressen og et eventuelt neste hopp, som er den samme informasjonen en pakke ville blitt rutet med i det øyeblikket.
Hvis svaret overrasker deg, skriv ut reglene før du endrer noe: ip -4 rule show lister dem i prioritetsrekkefølge, og en VPN-klient som installerer sin egen tabell eller en regel for merkede pakker, vil ikke vises i hovedtabellen i det hele tatt. Å liste alle tabeller lukker dette gapet.
ip -4 route show table all | grep -E 'tun|default'Sjekk underlaget før du erstatter standardruten
Tunnelens egne pakker må nå det eksterne endepunktet, og det gjør de gjennom det fysiske grensesnittet ved hjelp av ruten som fantes før VPN-en kom opp. Å erstatte hele standardruten uten å feste det endepunktet sender de innkapslede pakkene inn i tunnelen de skal bygge, og forbindelsen kollapser. Bekreft først endepunktets vei med et oppslag kun på endepunktadressen.
Hold tre ting atskilt når du gjør endringen: endepunktruten som må bli værende på det fysiske grensesnittet, de private områdene som skal inn i tunnelen, og standardruten som avgjør alt annet. Del dem opp i den rekkefølgen, bruk én om gangen, og kjør oppslaget på nytt etter hvert steg. En mislykket ping etterpå beviser svært lite i seg selv, siden tillatelser, svar-ruting, DNS og tjenesten selv alle ligger nedstrøms for en korrekt rute.
Skriv ned de fire verdiene linjen ga deg før endringen: destinasjon, neste hopp eller fraværet av det, enhet og valgt kilde. Hvis en senere endring flytter noen av dem, vet du hvilken beslutning som faktisk ble endret, og du kan gjenopprette én oppføring i stedet for å gjette på hele tabellen.