Wat bypass-dhcp feitelijk toevoegt aan een OpenVPN-routeplan

Een profiel met redirect-gateway def1 bypass-dhcp combineert een overschrijving van de standaard-IPv4-route met één smalle uitzondering. Mensen lezen het laatste woord en verwachten een algemene oplossing voor mobiele verbindingen, en besteden vervolgens een middag aan een DHCP-theorie die de vlag nooit heeft ondersteund. Elk deel doet één ding, en de uitzondering is veel kleiner dan haar reputatie.

Splits de vlaggen voordat je een fout die alleen op mobiel optreedt aan adrestoewijzing toeschrijft. De twee helften van die tekenreeks hebben niets met elkaar te maken.

Twee vlaggen, twee losse taken

Met def1 voegt de client twee IPv4-halfstandaardroutes toe in plaats van de bestaande standaardroute te vervangen. 0.0.0.0/1 dekt de onderste helft van de adresruimte en 128.0.0.0/1 de bovenste helft, zodat ze samen elke bestemming bereiken terwijl elk specifieker blijft dan 0.0.0.0/0. De oorspronkelijke standaardroute blijft daardoor in de tabel staan zonder die opzoekingen te winnen, wat de oude gateway bereikbaar houdt voor alles wat de client expliciet routeert. Het laat ook twee overlappende standaardroutes in de tabel staan, en daarom kan een routedump vreemder lijken dan het profiel suggereert.

bypass-dhcp staat apart en raakt de standaardroute helemaal niet. De OpenVPN 2.6-handleiding beschrijft het als het toevoegen van een directe route naar een DHCP-server die niet op het lokale subnet ligt, zodat leasetraffic buiten de tunnel gaat, en merkt op dat het gedrag op Windows-clients is geïmplementeerd en elders mogelijk niet beschikbaar is.

De reden dat het bestaat is mechanisch. Zodra de halfstandaardroutes het uitgaande verkeer vangen, zou een DHCP-vernieuwing gericht op een server op het fysieke netwerk de tunnel in worden gerouteerd, tenzij iets dat adres aan de echte interface vastmaakt. De vlag maakt het vast.

Waarop de uitzondering werkelijk betrekking heeft

Een illustratieve tabel na een geslaagde verbinding toont de vorm: twee halfstandaardroutes door de tunnel en één hostroute voor de DHCP-server via de fysieke gateway. Lees die als een vorm, niet als je eigen adressen.

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

Die derde regel noemt één bestemming. Het is geen resolverselector, geen algemene toestemming voor het lokale netwerk en geen uitgangsregel op de server. Een telefoon op een mobiele drager heeft misschien geen DHCP-server die de client zo kan identificeren, en daarom verandert de vlag daar niets.

Controleer wat de client werkelijk heeft geïnstalleerd

Onderscheid een optie die in een profiel staat, een optie die de server aanbiedt en een route die de eigenaar van de verbinding werkelijk heeft toegepast. Een client die een niet-ondersteunde vlag weigert, kan de rest van de configuratie behouden, waardoor de tunnel opkomt en de uitzondering simpelweg ontbreekt. Lees het eigen log van de client en de resulterende routetabel in plaats van aan te nemen dat de regel in het bestand van kracht werd. Drie daarvan kunnen tegelijk waar zijn, en alleen de laatste verandert waar pakketten werkelijk heen gaan.

Houd de route naar het VPN-eindpunt tegelijk bruikbaar. Die eindpuntuitzondering is een andere eis dan de DHCP-uitzondering, en zonder die kan de tunnel het transport vangen dat hem in stand houdt.

Voor een applicatiebestemming, onderzoek de effectieve opzoeking in de context waarin die faalt. Specifiekere lokale routes, policy-routing en uitsluitingen per applicatie veranderen allemaal het antwoord, dus de aanwezigheid van twee halfstandaardroutes is geen inventaris van elke stroom.

De rest van het pad zit niet in deze vlag

De server heeft nog steeds toestemming nodig om het internetverkeer van de client door te sturen en een uitgangsregeling die het kan terugsturen. Geen route aan de clientkant creëert ontbrekende doorsturing of bronvertaling op de server, en geen vlag vervangt een werkende terugweg.

Naamresolutie en IPv6 hebben elk hun eigen beleid nodig. Een IPv4-overschrijving stuurt de resolver niet naar een server aan de tunnelkant en stelt geen IPv6-dekking in, en een client die alleen v4 omleidt, laat een v6-pad ongemoeid.

Vergelijk één goedgekeurd onschadelijk verzoek over een werkend en een falend toegangspad, terwijl het profiel en de bestemming vast blijven. Noteer of het verschil in naamresolutie, tunnelopbouw, routekeuze of doorgestuurd verkeer zit, en bewaar het antwoord bij het profiel. Die notitie is wat de volgende persoon ervan weerhoudt DHCP de schuld te geven van een probleem dat het niet kan bereiken.