Vad bypass-dhcp faktiskt tillför en OpenVPN-ruttplan

En profil med redirect-gateway def1 bypass-dhcp kombinerar en överskrivning av IPv4-standardrutten med ett enda smalt undantag. Folk läser det sista ordet och förväntar sig en generell lösning för mobila anslutningar och lägger sedan en eftermiddag på en DHCP-teori som flaggan aldrig har stöttat. Varje del gör en sak, och undantaget är mycket mindre än sitt rykte.

Dela upp flaggorna innan du tillskriver ett fel som bara uppstår på mobil adresstilldelningen. De två halvorna av den strängen har ingenting med varandra att göra.

Två flaggor, två oberoende jobb

Med def1 lägger klienten till två IPv4-halvstandardrutter i stället för att byta ut den standardrutt som redan finns. 0.0.0.0/1 täcker den nedre halvan av adressutrymmet och 128.0.0.0/1 den övre halvan, så tillsammans når de varje destination medan var och en förblir mer specifik än 0.0.0.0/0. Den ursprungliga standardrutten blir därför kvar i tabellen utan att vinna de sökningarna, vilket håller den gamla gatewayen nåbar för allt som klienten routar uttryckligen. Det lämnar också två överlappande standardrutter i tabellen, och därför kan en ruttutskrift se märkligare ut än profilen antyder.

bypass-dhcp är separat och rör inte standardrutten alls. OpenVPN 2.6-handboken beskriver det som att lägga till en direkt rutt till en DHCP-server som inte ligger i det lokala subnätet, så att leasetrafik går utanför tunneln, och noterar att beteendet är implementerat på Windows-klienter och kanske inte finns någon annanstans.

Anledningen till att det finns är mekanisk. När halvstandardrutterna väl fångar utgående trafik skulle en DHCP-förnyelse riktad mot en server i det fysiska nätet routas in i tunneln om inte något fäster den adressen vid det riktiga gränssnittet. Flaggan fäster den.

Vad undantaget egentligen omfattar

En illustrativ tabell efter en lyckad anslutning visar formen: två halvstandardrutter genom tunneln och en värdrutt för DHCP-servern genom den fysiska gatewayen. Läs den som en form, inte som dina egna adresser.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Den tredje raden namnger en enda destination. Det är inte en inställning för resolvern, inte ett allmänt tillstånd för det lokala nätet och inte en utgångsregel på servern. En telefon på ett mobilnät har kanske ingen DHCP-server som klienten kan identifiera på detta sätt, och därför ändrar flaggan ingenting där.

Kontrollera vad klienten faktiskt installerade

Skilj mellan ett alternativ som skrivits i en profil, ett alternativ som servern erbjuder och en rutt som anslutningens ägare faktiskt tillämpade. En klient som avvisar en flagga som inte stöds kan behålla resten av konfigurationen, så tunneln kommer upp och undantaget saknas helt enkelt. Läs klientens egen logg och den resulterande rutttabellen i stället för att anta att raden i filen trädde i kraft. Tre av dessa kan vara sanna samtidigt, och bara den sista ändrar vart paketen faktiskt tar vägen.

Håll rutten till VPN-slutpunkten användbar samtidigt. Det slutpunktsundantaget är ett annat krav än DHCP-undantaget, och utan det kan tunneln fånga transporten som håller den igång.

För en applikationsdestination, undersök den effektiva sökningen i det sammanhang där den misslyckas. Mer specifika lokala rutter, policy-routing och undantag per applikation ändrar alla svaret, så förekomsten av två halvstandardrutter är inte en inventering av varje flöde.

Resten av vägen ligger inte i denna flagga

Servern behöver fortfarande tillstånd att vidarebefordra klientens internettrafik och en utgångsordning som kan skicka tillbaka den. Ingen rutt på klientsidan skapar saknad vidarebefordran eller källöversättning på servern, och ingen flagga ersätter en fungerande returväg.

Namnuppslagning och IPv6 behöver var sin policy. En IPv4-överskrivning pekar inte resolvern mot en server på tunnelsidan och etablerar inte IPv6-täckning, och en klient som bara omdirigerar v4 lämnar en v6-väg orörd.

Jämför en godkänd ofarlig begäran över en fungerande och en felande åtkomstväg med profilen och destinationen hållna fasta. Notera om skillnaden ligger i namnuppslagning, tunneletablering, ruttval eller vidarebefordrad trafik, och spara svaret med profilen. Den noteringen är det som hindrar nästa person från att skylla på DHCP för ett problem det inte kan nå.