Varför en VPN-rutt inte visar någon gateway i ip route-utskriften
En rad med en enhet och utan gateway är en direkt rutt, inte en trasig. Läs destination, dev och scope och bekräfta sedan med ip route get.
Ruttabeller läses som trasiga varje gång gateway-kolumnen står tom, trots att raden oftast är komplett i sig själv. Fältet via visas bara när kärnan lämnar över paketet till en nästa-hopp-adress; en rutt knuten till ett gränssnitt når i stället sina destinationer via uppslagning på länklagret eller via en punkt-till-punkt-partner. Att läsa kolumnerna från vänster till höger talar om vilket fall du är i, och den läsningen bör ske innan någon redigerar en standardrutt. De flesta ärenden om en saknad gateway slutar vid den här skillnaden.
Läs en ruttrad kolumn för kolumn
Varje post börjar med destinationen och längden på dess prefix och lägger sedan till modifierare i ett fast ordförråd: via, dev, proto, scope, src och metric. En rad som 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 är tät men fullt specificerad. Ingenting saknas i den, och ingen routeradress antyds.
Det intressanta är att via saknas. Utan ett nästa hopp löser kärnan destinationen direkt på det namngivna gränssnittet, vilket för en tunnel innebär att ramen lämnas över till tunnelenheten och att inkapslingen tar över därifrån. proto kernel registrerar att posten installerades automatiskt när en adress tilldelades, inte skrevs in av en administratör. scope link säger att destinationen är nåbar på den länken utan att passera en router, och src namnger den adress som kärnan föredrar som källa för trafik som matchar.
Läs nu en standardrutt på samma sätt: default via 192.0.2.254 dev eth0 proto static metric 100. Här finns via eftersom paketet verkligen behöver ett nästa hopp, och det hoppet måste självt vara nåbart på eth0. De två raderna är inte varianter av varandra; de svarar på olika frågor om vart trafiken tar vägen.
Två ruttformer som förväxlas med varandra
En tunnelsubnätsrutt och en standardrutt ser likadana ut på en skärmbild och beter sig helt olika. Använd tabellen nedan som läshjälp för fälten och bekräfta sedan de faktiska siffrorna på maskinen du felsöker i stället för att lita på ett exempel från 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 inte kan berätta är avsikten. En direkt rutt till ett privat intervall genom en tunnel är en medveten konstruktion med delad tunnel; samma form på en värd som borde skicka allt genom VPN:en är ett symptom. Avsikten bor i den konfiguration som skapade posten, så titta på verktyget som installerade den innan du drar slutsatsen att kärnan gjorde något fel.
På samma sätt är en saknad gateway inte tillåtelse att hitta på en. Om en rutt verkligen behöver ett nästa hopp, måste det hoppet vara nåbart på gränssnittet som bär det, och för en punkt-till-punkt-tunnel är partnerns adress inte samma objekt som den lokala adressen. Att behandla den lokala tunneladressen som en Ethernet-router är ett vanligt sätt att skapa en rutt som ser korrekt ut och inte vidarebefordrar något.
Fråga kärnan vilken rad den faktiskt kommer att använda
Att läsa tabellen är inte samma sak som att utföra slagningen, eftersom kärnan rådgör med policyregler, flera tabeller och cachelagrade poster innan den svarar. Verbet som utför den riktiga slagningen är ip route get, och det skriver ut den rutt som ett paket med dessa egenskaper skulle ta.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Byt in den destination du faktiskt bryr dig om och lägg sedan till from eller iif när trafiken väljs efter källa eller vidarebefordras, eftersom en vanlig lokal slagning kan välja en annan väg än en vidarebefordrad klient. Svaret namnger gränssnittet, den valda källadressen och eventuellt nästa hopp, vilket är samma information som ett paket skulle routas med i det ögonblicket.
Om svaret överraskar dig, skriv ut reglerna innan du ändrar något: ip -4 rule show listar dem i prioritetsordning, och en VPN-klient som installerar sin egen tabell eller en regel för markerade paket kommer inte att synas i huvudtabellen alls. Att lista alla tabeller stänger det gapet.
ip -4 route show table all | grep -E 'tun|default'Kontrollera underlagret innan du ersätter standardrutten
Tunnelns egna paket måste nå den avlägsna slutpunkten, och det gör de via det fysiska gränssnittet med hjälp av rutten som fanns innan VPN:en kom upp. Att ersätta hela standardrutten utan att fästa den slutpunkten skickar de inkapslade paketen in i tunneln de är tänkta att bygga, och anslutningen kollapsar. Bekräfta först vägen till slutpunkten med en slagning enbart på slutpunktens adress.
Håll tre saker åtskilda när du gör ändringen: rutten till slutpunkten som måste stanna på det fysiska gränssnittet, de privata intervallen som borde gå in i tunneln, och standardrutten som avgör allt annat. Dela upp dem i den ordningen, använd en i taget och kör slagningen igen efter varje steg. En misslyckad ping efteråt bevisar väldigt lite i sig, eftersom behörigheter, svarsroutning, DNS och själva tjänsten alla ligger nedströms om en korrekt rutt.
Skriv ner de fyra värden som raden gav dig före ändringen: destination, nästa hopp eller frånvaron av det, enhet och vald källa. Om en senare ändring flyttar något av dem vet du vilket beslut som faktiskt ändrades, och du kan återställa en post i stället för att gissa på hela tabellen.