Hvorfor en VPN-rute ikke viser nogen gateway i ip route-output
En linje med en enhed og uden gateway er en direkte rute, ikke en brudt. Læs destination, dev og scope, og bekræft derefter med ip route get.
Routingtabeller læses som brudte, når gateway-kolonnen står tom, selvom linjen som regel er komplet i sig selv. Feltet via vises kun, når kernen overlader pakken til en næste-hop-adresse; en rute knyttet til en grænseflade når i stedet sine destinationer via opløsning på linklaget eller via en punkt-til-punkt-peer. Læser man kolonnerne fra venstre mod højre, kan man se, hvilket tilfælde man er i, og den læsning bør ske, før nogen redigerer en standardrute. De fleste sager om en manglende gateway ender ved denne forskel.
Læs en rute kolonne for kolonne
Hver post starter med destinationen og dens præfikslængde og tilføjer derefter modifikatorer i et fast ordforråd: 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 tæt, men fuldt specificeret. Der mangler intet i den, og der antydes ingen routeradresse.
Fraværet af via er det interessante. Uden næste hop opløser kernen destinationen direkte på den navngivne grænseflade, hvilket for en tunnel betyder at aflevere rammen til tunnel-enheden og lade indkapslingen tage over derfra. proto kernel registrerer, at posten blev installeret automatisk, da en adresse blev tildelt, ikke skrevet af en administrator. scope link siger, at destinationen kan nås på det link uden at passere en router, og src navngiver den adresse, som kernen vil foretrække som kilde for trafik, der matcher.
Læs nu en standardrute på samme måde: default via 192.0.2.254 dev eth0 proto static metric 100. Her er via til stede, fordi pakken faktisk har brug for et næste hop, og det hop skal selv være nåbart på eth0. De to linjer er ikke varianter af hinanden; de besvarer forskellige spørgsmål om, hvor trafikken går hen.
To ruteformer, der forveksles med hinanden
En tunnelsubnetrute og en standardrute ser ens ud på et skærmbillede og opfører sig helt forskelligt. Brug tabellen nedenfor som læsehjælp til felterne, og bekræft derefter de faktiske tal på den maskine, du fejlfinder, i stedet for at stole på et eksempel fra en guide.
| 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 fortælle dig, er hensigten. En direkte rute til et privat område gennem en tunnel er et bevidst design med delt tunnel; den samme form på en vært, der burde sende alt gennem VPN'en, er et symptom. Hensigten ligger i den konfiguration, der frembragte posten, så se på det værktøj, der installerede den, før du konkluderer, at kernen gjorde noget forkert.
På samme måde er en manglende gateway ikke tilladelse til at opfinde en. Hvis en rute virkelig har brug for et næste hop, skal det hop være nåbart på den grænseflade, der bærer det, og for en punkt-til-punkt-tunnel er peer-adressen ikke det samme objekt som den lokale adresse. At behandle den lokale tunneladresse som en Ethernet-router er en almindelig måde at frembringe en rute, der ser korrekt ud og ikke videresender noget.
Spørg kernen, hvilken linje den rent faktisk vil bruge
At læse tabellen er ikke det samme som at udføre opslaget, fordi kernen konsulterer politikregler, flere tabeller og cachede poster, før den svarer. Det udsagnsord, der udfører det rigtige opslag, er ip route get, og det udskriver den rute, som en pakke med disse egenskaber ville tage.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Indsæt den destination, du faktisk bekymrer dig om, og tilføj derefter from eller iif, når trafikken er kildevalgt eller videresendt, fordi et almindeligt lokalt opslag kan vælge en anden vej end en videresendt klient. Svaret angiver grænsefladen, den valgte kildeadresse og et eventuelt næste hop, hvilket er de samme oplysninger, som en pakke ville blive routet med i det øjeblik.
Hvis svaret overrasker dig, så udskriv reglerne, før du ændrer noget: ip -4 rule show lister dem i prioritetsrækkefølge, og en VPN-klient, der installerer sin egen tabel eller en regel for markerede pakker, vil slet ikke optræde i hovedtabellen. At liste alle tabeller lukker dette hul.
ip -4 route show table all | grep -E 'tun|default'Kontroller underlaget, før du erstatter standardruten
Tunnelens egne pakker skal nå det fjerne endepunkt, og de gør det gennem den fysiske grænseflade ved hjælp af den rute, der fandtes, før VPN'en kom op. At erstatte hele standardruten uden at fastgøre det endepunkt sender de indkapslede pakker ind i den tunnel, de skulle bygge, og forbindelsen bryder sammen. Bekræft først endepunktsvejen med et opslag på endepunktsadressen alene.
Hold tre ting adskilt, når du laver ændringen: endepunktsruten, der skal blive på den fysiske grænseflade, de private områder, der skal ind i tunnelen, og standardruten, der afgør alt andet. Bryd dem op i den rækkefølge, anvend en ad gangen, og kør opslaget igen efter hvert skridt. Et mislykket ping bagefter beviser meget lidt i sig selv, da tilladelser, svar-routing, DNS og tjenesten selv alle ligger nedstrøms for en korrekt rute.
Skriv de fire værdier ned, som linjen gav dig før ændringen: destination, næste hop eller dets fravær, enhed og valgt kilde. Hvis en senere ændring flytter nogen af dem, ved du, hvilken beslutning der faktisk blev ændret, og du kan gendanne én post i stedet for at gætte på hele tabellen.