Wat bypass-dhcp werklik by ’n OpenVPN-roetebeplanning voeg

’n Profiel met redirect-gateway def1 bypass-dhcp kombineer ’n IPv4-standaardoorheersing met een noue uitsondering. Mense lees die laaste woord en verwag ’n algemene oplossing vir mobiele verbindings, en spandeer dan ’n middag op ’n DHCP-teorie wat die vlag nooit ondersteun het nie. Elke deel doen een ding, en die uitsondering is baie kleiner as sy reputasie.

Haal die vlae uitmekaar voordat jy ’n slegs-sellulêre fout aan adrestoewysing toeskryf. Die twee helftes van daardie string het niks met mekaar te doen nie.

Twee vlae, twee onverwante take

Met def1 voeg die kliënt twee IPv4-halfstandaarde by eerder as om die standaard wat al daar is te vervang. 0.0.0.0/1 dek die onderste helfte van die adresruimte en 128.0.0.0/1 die boonste helfte, so saam bereik hulle elke bestemming terwyl elkeen meer spesifiek bly as 0.0.0.0/0. Die oorspronklike standaard bly dus in die tabel sonder om daardie opsoekte te wen, wat die ou poort bereikbaar hou vir enigiets wat die kliënt eksplisiet roeteer. Dit laat ook twee oorvleuelende standaarde in die tabel, en dit is waarom ’n roete-uitgooi vreemder kan lyk as wat die profiel voorstel.

bypass-dhcp is apart, en dit raak glad nie die standaard nie. Die OpenVPN 2.6-handleiding dokumenteer dit as die byvoeging van ’n direkte roete na ’n DHCP-bediener wat nie op die plaaslike subnet is nie, sodat huurverkeer buite die tonnel uitgaan, en noem dat die gedrag op Windows-kliënte geïmplementeer is en moontlik elders nie beskikbaar is nie.

Die rede waarom dit bestaan is meganies. Sodra die halfstandaarde uitgaande verkeer vang, sou ’n DHCP-hernuwing gerig op ’n bediener op die fisiese netwerk in die tonnel ingeroeteer word tensy iets daardie adres aan die werklike koppelvlak vaspen. Die vlag pen dit vas.

Waarop die uitsondering werklik van toepassing is

’n Illustratiewe tabel ná ’n suksesvolle verbinding wys die vorm: twee halfstandaarde deur die tonnel, en een host-roete vir die DHCP-bediener deur die fisiese poort. Lees dit as ’n vorm eerder as as jou eie adresse.

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

Daardie derde reël noem een bestemming. Dit is nie ’n oplosserinstelling nie, nie ’n algemene toestemming vir die plaaslike netwerk nie en nie ’n uitgangsreël op die bediener nie. ’n Foon op ’n sellulêre draer het dalk geen DHCP-bediener wat die kliënt so kan identifiseer nie, en daarom verander die vlag niks daar nie.

Kontroleer wat die kliënt werklik geïnstalleer het

Onderskei ’n opsie wat in ’n profiel geskryf is, ’n opsie wat deur die bediener aangebied word en ’n roete wat die verbindingseienaar werklik toegepas het. ’n Kliënt wat ’n onondersteunde vlag verwerp, kan die res van die konfigurasie behou, so die tonnel kom op en die uitsondering is bloot afwesig. Lees die kliënt se eie logboek en die resulterende roetetabel eerder as om te aanvaar dat die reël in die lêer in werking getree het. Drie daarvan kan gelyktydig waar wees, en net die laaste een verander waar pakkette werklik heen gaan.

Hou die roete na die VPN-eindpunt terselfdertyd bruikbaar. Daardie eindpunt-uitsondering is ’n ander vereiste as die DHCP-uitsondering, en daarsonder kan die tonnel die vervoer vang wat dit in stand hou.

Vir ’n toepassingsbestemming, ondersoek die effektiewe opsoek in die konteks waar dit misluk. Meer spesifieke plaaslike roetes, beleidsroetering en uitsluitings per toepassing verander almal die antwoord, so die teenwoordigheid van twee halfstandaarde is nie ’n inventaris van elke vloei nie.

Waar die res van die pad nie in hierdie vlag sit nie

Die bediener het steeds toestemming nodig om die kliënt se internetverkeer deur te stuur en ’n uitgangsreëling wat dit kan terugstuur. Geen kliëntkant-roete skep ontbrekende deurstuur of bronvertaling op die bediener nie, en geen vlag vervang ’n werkende terugpad nie.

Naamresolusie en IPv6 het elk hul eie beleid nodig. ’n IPv4-oorheersing wys nie die oplosser na ’n tonnelkant-bediener nie en vestig ook nie IPv6-dekking nie, en ’n kliënt wat net v4 herlei, laat ’n v6-pad onaangeraak.

Vergelyk een goedgekeurde skadelose versoek oor ’n werkende en ’n falende toegangspad terwyl die profiel en bestemming vas bly. Teken aan of die verskil in naamresolusie, tonnelvestiging, roeteseleksie of deurstuurde verkeer sit, en hou die antwoord by die profiel. Daardie rekord is wat die volgende persoon daarvan weerhou om DHCP te blameer vir ’n probleem wat dit nie kan bereik nie.