Kion bypass-dhcp reale aldonas al OpenVPN-itinero

Profilo portanta redirect-gateway def1 bypass-dhcp kunigas anstataŭigon de la implicita IPv4-itinero kun unu mallarĝa escepto. Homoj legas la lastan vorton kaj atendas ĝeneralan solvon por poŝtelefonaj konektoj, poste pasigas posttagmezon pri DHCP-teorio, kiun la flago neniam subtenis. Ĉiu parto faras unu aferon, kaj la escepto estas multe pli malgranda ol ĝia reputacio.

Malkomponu la flagojn antaŭ ol atribui fiaskon nur en poŝtelefona reto al adres-atribuado. La du duonoj de tiu ĉeno havas nenion komunan.

Du flagoj, du nerilataj taskoj

Kun def1, la kliento aldonas du duon-implicitajn IPv4-itinerojn anstataŭ anstataŭigi la implicitan itineron, kiu jam ekzistas. 0.0.0.0/1 kovras la malsupran duonon de la adresa spaco kaj 128.0.0.0/1 la supran duonon, do kune ili atingas ĉiun celon, dum ĉiu restas pli specifa ol 0.0.0.0/0. La origina implicita itinero do restas en la tabelo sen gajni tiujn serĉojn, kio tenas la malnovan enirejon atingebla por ĉio, kion la kliento eksplicite enkursigas. Ĝi ankaŭ lasas du interkovrantajn implicitajn itinerojn en la tabelo, kaj tial eligo de itineroj povas aspekti pli stranga ol la profilo sugestas.

bypass-dhcp estas aparta kaj tute ne tuŝas la implicitan itineron. La manlibro de OpenVPN 2.6 priskribas ĝin kiel aldonon de rekta itinero al DHCP-servilo, kiu ne estas en la loka subreto, do luada trafiko eliras ekster la tunelo, kaj notas, ke la konduto estas efektivigita en Windows-klientoj kaj eble ne haveblas aliloke.

La kialo de ĝia ekzisto estas meĥanika. Post kiam la duon-implicitaj itineroj kaptas eliran trafikon, DHCP-renovigo direktita al servilo en la fizika reto estus enkursigita en la tunelon, se io ne fiksus tiun adreson al la reala interfaco. La flago fiksas ĝin.

Al kio la escepto fakte limiĝas

Ilustra tabelo post sukcesa konekto montras la formon: du duon-implicitaj itineroj tra la tunelo kaj unu gastiga itinero por la DHCP-servilo tra la fizika enirejo. Legu ĝin kiel formon, ne kiel viajn proprajn adresojn.

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

Tiu tria linio nomas unu celon. Ĝi ne estas agordo de solvilo, ne ĝenerala permeso por la loka reto kaj ne elira regulo sur la servilo. Telefono sur poŝtelefona portanto eble havas neniun DHCP-servilon, kiun la kliento povas identigi tiel, kaj tial la flago tie ŝanĝas nenion.

Kontrolu, kion la kliento vere instalis

Distingi opcion skribitan en profilo, opcion proponitan de la servilo kaj itineron, kiun la posedanto de la konekto efektive aplikis. Kliento, kiu rifuzas nesubtenatan flagon, povas konservi la reston de la agordo, do la tunelo ekfunkcias kaj la escepto simple mankas. Legu la propran protokolon de la kliento kaj la rezultan enkursigan tabelon anstataŭ supozi, ke la linio en la dosiero ekvalidis. Tri el tiuj povas esti veraj samtempe, kaj nur la lasta ŝanĝas, kien pakaĵoj efektive iras.

Tenu la itineron al la VPN-finpunkto uzebla samtempe. Tiu finpunkta escepto estas alia postulo ol la DHCP-escepto, kaj sen ĝi la tunelo povas kapti la transporton, kiu tenas ĝin.

Por aplikaĵa celo, ekzamenu la efektivan serĉon en la kunteksto, kie ĝi fiaskas. Pli specifaj lokaj itineroj, politika enkursigado kaj esceptoj laŭ aplikaĵo ĉiuj ŝanĝas la respondon, do la ĉeesto de du duon-implicitaj itineroj ne estas inventaro de ĉiu fluo.

La resto de la vojo ne estas en ĉi tiu flago

La servilo ankoraŭ bezonas permeson plusendi la interretan trafikon de la kliento kaj eliran aranĝon, kiu povas redoni ĝin. Neniu itinero ĉe la klienta flanko kreas mankantan plusendadon aŭ fonttradukon sur la servilo, kaj neniu flago anstataŭas funkciantan revenan vojon.

Nomtradukado kaj IPv6 ĉiu bezonas sian propran politikon. IPv4-anstataŭigo nek direktas la solvilon al servilo ĉe la tunela flanko nek starigas IPv6-kovradon, kaj kliento, kiu alidirektas nur v4, lasas v6-vojon netuŝita.

Komparu unu aprobitan sendanĝeran peton sur funkcianta kaj fiaskanta alirvojo, tenante la profilon kaj la celon fiksaj. Notu, ĉu la diferenco kuŝas en nomtradukado, tunela starigo, itinera elekto aŭ plusendita trafiko, kaj konservu la respondon kun la profilo. Ĝuste tiu noto malhelpas la sekvan personon kulpi DHCP pri problemo, kiun ĝi ne povas atingi.