Varför enbart route-nopull lämnar filservern oåtkomlig
Att ignorera pushade rutter är bara halva en delad tunnel. Välj ruttägaren, lägg till kontorets prefix för hand och testa tre flöden innan du kallar det löst.
Filservern öppnas fint, och videosamtalet i nästa fönster börjar hacka. Inget är långsamt och ingen MTU är fel: din klient tog emot ruttlistan som servern gav den, så varje paket går nu ut genom kontorets brandvägg. Lösningen är inte ännu en justeringsflagga utan ett beslut om vem som äger klientens rutttabell. Det beslutet hör hemma på ett ställe, och fellägena nedan berättar vilket ställe du faktiskt valde.
Bestäm vem som äger rutttabellen
Tre ägare är möjliga. Servern kan pusha rutter och en standardgateway, och då installerar klienten vad den blir tillsagd och blir en full tunnel. Klientprofilen kan ta ägarskap genom att kasta bort pusharna och bära sina egna ruttrader. En skrivbordsanslutningshanterare kan också äga beslutet via sina egna rutt- och standardruttsegenskaper.
Varje val misslyckas på sitt eget sätt, och därför är det värt att läsa tabellen innan du redigerar en profil. Raden som matchar ditt symptom är den ägare du faktiskt har.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Välj en och skriv ned den. Att blanda två lämnar en värd vars standardväg motsäger sin egen dokumentation, och nästa ingenjör kan inte se vilket lager som vann. Ta bort förloraren uttryckligen.
route-nopull filtrerar pushar, det lägger inte till rutter
route-nopull hör hemma i klientprofilen, och ordningen i den filen spelar ingen roll eftersom den bara kastar bort värden som kommer från servern. Den kastar bort pushade rutter, inklusive en pushad standardrutt, medan tunneln fortfarande kommer upp normalt.
Konsekvensen folk missar är att pushade DHCP-alternativ följer med. DNS-inställningarna som servern skickar kastas också bort, så interna namn slutar att slås upp även om tunneln är frisk och servern nås på adressen.
Det lämnar en tunnel utan väg till kontorets prefix om du inte lägger till en själv: route-nopull följt av route 10.30.0.0 255.255.0.0 i samma profil. Den raden bär en adress och en mask; den namnger inte ett nästa hopp.
En alternativ form lägger till en gateway-token, route 10.30.0.0 255.255.0.0 vpn_gateway, som pekar posten mot tunneln vid namn. Importörer skiljer sig åt i om de översätter den varianten, så granska den sparade anslutningen om posten saknas i kärntabellen.
Verifiera med ruttuppslagningar, inte med ping
En ping berättar att något svarade. En ruttuppslagning berättar vilket gränssnitt kärnan skulle välja, och det är frågan du faktiskt ställde. Fyra korta kommandon skiljer en saknad rutt från en rutt som pekar på fel enhet.
Läs vad tunneln installerade med ip route show dev tun0. Ingen utdata alls betyder noll rutter, vilket inte är en delad tunnel som fungerar, och det är det vanliga resultatet av att lägga till filtret utan den uttryckliga raden.
Kontrollera sedan en kontorsadress med ip route get 10.30.5.7, och en vanlig internetadress med ip route get 1.1.1.1. Den andra bör namnge det fysiska gränssnittet; namnger den tunneln filtrerades pushen inte alls.
Läs till sist ip rule, eftersom en policyregel som ett tidigare försök lämnade kvar kan åsidosätta tabellen du just rättade. En korrekt profil med en föråldrad regel ovanpå ser exakt ut som en trasig profil. Ta bort regeln du lade till förra gången innan du lägger till en ny.
Överlappande subnät ser ut som en trasig tunnel
Två privata intervall kan vara identiska ur klientens synvinkel, och det är där en delad tunnel får skulden för något den inte orsakade. Om kontoret delar ut samma prefix som din hemrouter använder täcker tunnelrutten routern, och hemnätverket verkar försvinna.
Jämför adressen på ditt eget gränssnitt med rutten profilen installerar, med en vanlig adresslista innan du ändrar något. Överlappningen är verklig, och ingen profilinställning löser den. Det du kan rätta är namngivningen, så att nästa person ser två intervall i stället för ett.
De ärliga rättningarna är att numrera om ena sidan eller översätta adresser på kontoret. Att fästa en enda värdrutt vid routern fungerar tills routeradressen ändras, och då blir det ett andra mysterium ovanpå det första.
Låt beslutet överleva en återanslutning
Poster som skrivs för hand överlever inte en återanslutning, och en anslutningshanterare bygger om tabellen varje gång profilen startar. Lägg beslutet där anslutningen skapas, vare sig det är profilen eller hanterarens sparade inställningar. Starta sedan om anslutningen en gång med avsikt i stället för att upptäcka beteendet under ett samtal. En profil som bara fungerar till nästa återanslutning är inte klar.
Öva tre vägar samtidigt: en kontorsvärd på den bokstavliga adressen, samma värd på namn, och en vanlig offentlig webbplats. Den mellersta beror på namntjänsten du konfigurerade efter att du släppte de pushade DNS-inställningarna, och det är den som tyst misslyckas.