OpenVPN redirect-gateway: vad varje flagga gör med rutterna

Anslut med redirect-gateway i profilen, och maskinens standardrutt kan försvinna, delas i två eller stanna exakt där den var, beroende på flaggor som ingen läser två gånger. Alternativet ändrar bara routingtillståndet och inget annat, så det enda tillförlitliga beviset på vad det gjorde är tabellen som klienten installerade efteråt. Det som följer är tabellen efter en anslutning, rutten som håller själva tunneln vid liv och IPv6-trafiken som direktivet aldrig hävdar att det täcker. Varje steg är ett kommando du kan köra på klienten medan tunneln är uppe.

Vad varje flagga gör med standardrutten

Utan någon flagga tar alternativet bort den vanliga standardrutten och sätter tunneln i dess ställe, så den gamla gatewayen försvinner från tabellen medan anslutningen är uppe. Lägg till def1 och den standarden blir kvar i listan, medan två smalare rutter gör jobbet i stället. Lägg till bypass-dhcp och DHCP-rutten överlever också, vilket spelar roll i ett nätverk där klienten fortfarande måste nå den lokala DHCP-servern. Flaglistan på manualsidan för OpenVPN 2.6 är kort nog att läsas en gång, och varje post ändrar vilka rutter som hamnar i tabellen.

Ett pushat alternativ beter sig på samma sätt när det anländer, så klientprofilen kan vara helt tom medan tabellen ser fullständigt omdirigerad ut. Det är normalt: servern skickade flaggorna, klienten tillämpade dem, och den lokala filen nämnde aldrig direktivet. När en push verkar inte göra något, kontrollera klientfiltret som accepterar eller släpper hämtade alternativ, för ett släppt alternativ ger inget fel i någon av ändarna.

def1 vinner på specificitet utan att röra din standardrutt

Två halva standardrutter täcker tillsammans IPv4-rymden, 0.0.0.0/1 och 128.0.0.0/1. Var och en är mer specifik än 0.0.0.0/0, så en sökning föredrar dem medan den riktiga standardrutten blir kvar i tabellen för allt som ber om den minst specifika träffen.

Läs tabellen i stället för profilen, för bara tabellen visar vilket av dessa fall du är i. Två rader räcker för att skilja dem åt:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Notera gränssnittet och metriken på varje rad, inte bara destinationen. En standardrutt som pekar på tunneln och ett par halva standardrutter som pekar på tunneln beskriver samma avsikt och misslyckas olika när tunneln faller, eftersom reservvägen fortfarande finns i det ena fallet. Skriv båda fälten i ändringsanteckningen. En överlevande reservväg är ibland det som håller en fjärrsession vid liv tillräckligt länge för att reparera tunneln, och den är också det som läcker trafik när avsikten var en full tunnel.

Håll tunnelns ändpunkt nåbar

Klienten behöver en rutt till tunnelns bortre ände som inte själv går genom tunneln. OpenVPN installerar den värdrutten innan det ändrar något annat, och en manuell ruttändring eller en andra VPN-klient kan ta bort den. Symtomet efteråt är en anslutning som rapporterar att den är ansluten och sedan inte släpper igenom något.

Fråga kärnan vilket gränssnitt den skulle använda för ändpunktens adress medan tunneln är uppe. Svaret måste namnge det fysiska gränssnittet och dess gateway, aldrig tun0:

ip route get 198.51.100.20

Om den sökningen returnerar tunneenheten bär tunneln sin egen transport och kollapsar så snart ett paket måste ut. Lokala prefix, en extra adapter och policy-routing spelar fortfarande roll här, och därför kan en omdirigering som fungerar på en ren bärbar dator misslyckas på en värd med ett hanteringsgränssnitt och två standardrutter. Oftast får profilen skulden för det adressplanen gjorde.

IPv6-trafik fortsätter använda sin egen tabell

Omdirigering av IPv4 lämnar IPv6 i fred, och de två familjerna ändras av olika flaggor. På en dual-stack-värd med en fungerande v6-standard kan v4-trafik sitta helt inne i tunneln medan varje v6-kapabel destination lämnar över den fysiska länken. En värd som ser rätt ut i den ena tabellen läcker i den andra.

Kontrollera v6-tabellen efter anslutningen i stället för att anta att tunneln täckte den. Direktivet bär adressfamiljeflaggor just därför, och en profil som utelämnar dem ärver det plattformen gör som standard:

ip -6 route show default
ip -6 route get 2001:db8::10

Bevisa vilket gränssnitt ett program använder

Ett anslutet tillstånd är inte en blockering, och en ruttändring är inte en nödstopp. Om direkt trafik måste stanna när tunneln misslyckas, lever den policyn i brandväggen och behöver sitt eget test.

Testa den väg ett program faktiskt tar i stället för den väg profilen beskriver. Fråga först efter rutten, bind sedan en begäran till varje gränssnitt i tur och ordning och jämför vad den bortre sidan rapporterar:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Om båda begäranden returnerar samma adress använder programmet inte tunneln trots att routingtabellen säger att det borde. Om bara den tunnelbundna begäran lyckas är den fysiska vägen filtrerad för den destinationen och tunneln gör det du bad om. Skriv flaggorna, de installerade rutterna, ändpunktsökningen och båda utgångsresultaten i ändringsprotokollet, så att nästa person ärver fakta i stället för en skärmbild.