Rutter som OpenVPN skickar ut installeras inte: timing, rättigheter eller policy

Servern säger att den pushade rutten, klienten säger att den är ansluten, och målet är fortfarande oåtkomligt. Tre orsaker ger exakt den bilden. Ruttillägget kördes innan enheten fanns, klienten saknade rättigheter att ändra tabellen, eller en policy sade åt klienten att ignorera pushade alternativ.

Utifrån ser de identiska ut och kräver olika åtgärder. Läs klientloggen där beslut om rutten fattas.

Bevisa att rutten saknas, inte bara att den är trasig

Börja med att bevisa att rutten saknas i stället för att vara trasig. På Linux listar ip route show dev tun0 vad klienten har installerat på tunnelenheten. På Windows visar route print eller Get-NetRoute samma sak i tabellform.

En rutt som finns men inte vidarebefordrar trafik är ett annat problem. Det flyttar utredningen till vidarebefordrings- och brandväggsregler, inte till ruttinstallation.

Timing: tillägget kördes innan enheten fanns

Klienten analyserar serverns PUSH_REPLY efter att kontrollkanalen är uppe och efter att den har konfigurerat gränssnittet. Först då rör den vid rutttabellen, med den mekanism plattformen erbjuder. Linux går via netlink; Windows använder ett API som kräver en förhöjd token. Ett skript eller en klient som lägger till rutter så snart den läser konfigurationen kan köras innan TUN/TAP-enheten finns, och kärnan avvisar tillägget.

Samma kapplöpning förklarar varför en handskriven rutt fungerar medan den automatiska inte gör det: när du skriver den är gränssnittet redan uppe.

route-delay finns för det här fallet, och route-up namnger ett skript som körs efter att gränssnittet och rutterna har konfigurerats. Lägg rutter som beror av tunneladressen i den kroken i stället för i ett tidigt skede.

Rättigheter: vem får ändra tabellen

Att ändra Windows rutttabell kräver en förhöjd token. En GUI som startats av en vanlig användare kan sätta adapteradressen via tjänsten och ändå inte kunna lägga till en rutt. Loggen visar då ett fel av typen åtkomst nekad i stället för en saknad push.

Att starta GUI:t som administratör, eller använda den tjänstebaserade klienten, ändrar det resultatet. En schemalagd uppgift som startar klienten utan den nödvändiga token gör det inte.

Kontrollera vilket konto klienten faktiskt kör som innan du ändrar något. Versionen och tjänsteläget avgör vilka orsaker som ens är möjliga, så anteckna båda bredvid ruttutdata.

Policy: pushade rutter kan kastas med avsikt

route-nopull får klienten att ignorera rutter som servern skickar ut, inklusive en pushad standardrutt, medan tunneladressen fortfarande accepteras. Pushade DNS- och DHCP-alternativ kastas av samma direktiv. En sådan klient är inte defekt; den förväntar sig uttryckliga ruttrader i sin egen konfiguration.

route-noexec är en annan kontroll: den stoppar klienten helt från att utföra ruttändringar. En topologi som klienten inte kan kartlägga kan ge ett liknande resultat, och rutten loggas som avvisad i stället för tillagd. Läs loggrader som rapporterar beslutet i stället för att gissa vilken av de tre som gäller. Kontrollera sedan den effektiva profilen, eftersom en importör eller ett administrationsverktyg kan lägga till alternativ som användaren aldrig har redigerat.

En profil som ser ren ut i en textredigerare kan ändå bära ett tillagt direktiv under körning.

Jämför pushlistan med tabellen

Efter anslutning, placera serverns pushlista bredvid klientens tabell. På Linux är det ip route show dev tun0; på Windows route print eller Get-NetRoute. Om rutten saknas, åtgärda installationen först. Om den finns och trafiken misslyckas, gå vidare till vidarebefordrings- och brandväggspolicy.

Anteckna klientversionen, kontot den kör som och om den är tjänstebaserad. Dessa tre fakta berättar för nästa person vilka orsaker som uteslutits.