Ko bypass-dhcp patiešām pievieno OpenVPN maršrutu plānam

Profils ar redirect-gateway def1 bypass-dhcp apvieno IPv4 noklusējuma maršruta aizstāšanu ar vienu šauru izņēmumu. Cilvēki izlasa pēdējo vārdu un gaida vispārīgu risinājumu mobilajiem savienojumiem, pēc tam pavada pēcpusdienu ar DHCP teoriju, ko šis karodziņš nekad nav atbalstījis. Katra daļa dara vienu lietu, un izņēmums ir daudz mazāks par tā reputāciju.

Izjauciet karodziņus, pirms attiecināt tikai mobilajā tīklā sastopamu kļūmi uz adrešu piešķiršanu. Abām šīs virknes pusēm nav nekā kopīga.

Divi karodziņi, divi nesaistīti darbi

Ar def1 klients pievieno divus IPv4 pusnoklusējuma maršrutus, nevis aizstāj jau esošo noklusējuma maršrutu. 0.0.0.0/1 aptver adrešu telpas apakšējo pusi, bet 128.0.0.0/1 augšējo, tāpēc kopā tie sasniedz jebkuru galamērķi, kamēr katrs paliek konkrētāks par 0.0.0.0/0. Tāpēc sākotnējais noklusējuma maršruts paliek tabulā, neuzvarot šos meklējumus, kas veco vārteju notur sasniedzamu visam, ko klients skaidri maršrutē. Tas arī atstāj tabulā divus pārklājošus noklusējuma maršrutus, tāpēc maršrutu izdruka var izskatīties dīvaināka, nekā profils liecina.

bypass-dhcp ir atsevišķs, un tas vispār neaiztiek noklusējuma maršrutu. OpenVPN 2.6 rokasgrāmata to apraksta kā tieša maršruta pievienošanu DHCP serverim, kas neatrodas vietējā apakštīklā, lai nomas trafiks izietu ārpus tuneļa, un norāda, ka šī uzvedība ir ieviesta Windows klientos un citur var nebūt pieejama.

Tā pastāvēšanas iemesls ir mehānisks. Kad pusnoklusējuma maršruti pārņem izejošo trafiku, uz serveri fiziskajā tīklā vērsts DHCP atjauninājums tiktu maršrutēts tunelī, ja vien kaut kas šo adresi nepiespraustu īstajai saskarnei. Karodziņš to piesprauž.

Uz ko izņēmums patiešām attiecas

Ilustratīva tabula pēc veiksmīga savienojuma parāda formu: divi pusnoklusējuma maršruti caur tuneli un viens resursdatora maršruts DHCP serverim caur fizisko vārteju. Lasiet to kā formu, nevis kā savas adreses.

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

Trešā rinda nosauc vienu galamērķi. Tā nav atrisinātāja iestatīšana, nav vispārīga atļauja vietējam tīklam un nav izejas noteikums serverī. Telefonam mobilajā tīklā var nebūt DHCP servera, ko klients šādi identificētu, tāpēc karodziņš tur neko nemaina.

Pārbaudiet, ko klients patiešām instalēja

Atšķiriet profilā rakstītu opciju, servera piedāvātu opciju un maršrutu, ko savienojuma īpašnieks faktiski piemēroja. Klients, kas noraida neatbalstītu karodziņu, var saglabāt pārējo konfigurāciju, tāpēc tunelis paceļas un izņēmums vienkārši nav. Lasiet paša klienta žurnālu un iegūto maršrutēšanas tabulu, nevis pieņemiet, ka faila rinda stājās spēkā. Trīs no šiem var būt patiesi vienlaikus, un tikai pēdējais maina, kur paketes patiešām dodas.

Vienlaikus saglabājiet lietojamu maršrutu uz VPN galapunktu. Šis galapunkta izņēmums ir cita prasība nekā DHCP izņēmums, un bez tā tunelis var pārņemt transportu, kas to uztur.

Lietojumprogrammas galamērķim pārbaudiet efektīvo meklējumu kontekstā, kurā tas neizdodas. Konkrētāki vietējie maršruti, politikas maršrutēšana un izslēgšana pa lietojumprogrammām maina atbildi, tāpēc divu pusnoklusējuma maršrutu klātbūtne nav katra plūsma uzskaitījums.

Atlikusī ceļa daļa nav šajā karodziņā

Serverim joprojām vajag atļauju pārsūtīt klienta interneta trafiku un izejas kārtību, kas to var atgriezt. Neviena klienta puses maršruts nerada trūkstošu pārsūtīšanu vai avota tulkošanu serverī, un neviens karodziņš neaizstāj strādājošu atgriešanās ceļu.

Nosaukumu izšķiršanai un IPv6 katram vajadzīga sava politika. IPv4 aizstāšana nevirza atrisinātāju uz serveri tuneļa pusē, neveido IPv6 pārklājumu, un klients, kas novirza tikai v4, atstāj v6 ceļu neskartu.

Salīdziniet vienu apstiprinātu nekaitīgu pieprasījumu strādājošā un neveiksmīgā piekļuves ceļā, turot profilu un galamērķi fiksētus. Pierakstiet, vai atšķirība ir nosaukumu izšķiršanā, tuneļa izveidē, maršruta izvēlē vai pārsūtītajā trafikā, un glabājiet atbildi kopā ar profilu. Tieši šis ieraksts neļauj nākamajam cilvēkam vainot DHCP problēmā, kurai tas nevar piekļūt.