Што всушност додава bypass-dhcp на маршрутниот план на OpenVPN

Профил со redirect-gateway def1 bypass-dhcp комбинира замена на стандардната IPv4 рута со едно тесно исклучок. Луѓето го читаат последниот збор и очекуваат општо решение за мобилни врски, потоа поминуваат попладне со DHCP теорија што знаменцето никогаш не ја поддржало. Секој дел прави една работа, а исклучокот е многу помал од неговиот углед.

Раздвојте ги знаменцата пред да припишете дефект само во мобилната мрежа на доделувањето адреси. Двете половини од таа низа немаат ништо заедничко.

Две знаменца, две неповрзани работи

Со def1, клиентот додава две IPv4 полустандардни рути наместо да ја замени стандардната рута што веќе постои. 0.0.0.0/1 ја покрива долната половина од адресниот простор, а 128.0.0.0/1 горната, па заедно стигнуваат до секоја дестинација, додека секоја останува поспецифична од 0.0.0.0/0. Затоа првобитната стандардна рута останува во табелата без да ги добие тие пребарувања, што ја одржува старата порта достапна за сите што клиентот експлицитно го рутира. Тоа исто така остава две преклопувачки стандардни рути во табелата, и затоа исписот на рути може да изгледа почудно отколку што сугерира профилот.

bypass-dhcp е одделно и воопшто не ја допира стандардната рута. Прирачникот за OpenVPN 2.6 го опишува како додавање директна рута до DHCP сервер што не е во локалната подмрежа, така што сообраќајот за закуп излегува надвор од тунелот, и забележува дека однесувањето е имплементирано на Windows клиенти и може да не е достапно на друго место.

Причината за неговото постоење е механичка. Откако полустандардните рути ќе го фатат излезниот сообраќај, обновувањето на DHCP закупот насочено кон сервер во физичката мрежа би било рутирано во тунелот, освен ако нешто не ја закачи таа адреса на вистинскиот интерфејс. Знаменцето ја закачува.

На што всушност се однесува исклучокот

Илустративна табела по успешно поврзување ја покажува формата: две полустандардни рути низ тунелот и една хост-рута за DHCP серверот низ физичката порта. Читајте ја како форма, а не како вашите сопствени адреси.

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

Третиот ред именува една дестинација. Тоа не е поставување на резолверот, не е општо дозвола за локалната мрежа и не е правило за излез на серверот. Телефон на мобилен оператор може да нема DHCP сервер што клиентот може да го препознае на овој начин, и затоа знаменцето таму не менува ништо.

Проверете што клиентот навистина инсталирал

Разликувајте опција напишана во профил, опција понудена од серверот и рута што сопственикот на врската навистина ја применил. Клиент што одбива неподдржано знаменце може да го задржи остатокот од конфигурацијата, така што тунелот се крева, а исклучокот едноставно отсуствува. Читајте го сопствениот дневник на клиентот и добиената табела за рутирање, наместо да претпоставувате дека редот во датотеката стапил на сила. Три од овие можат да бидат точни истовремено, и само последното менува каде пакетите навистина одат.

Одржувајте ја рутата до крајната точка на VPN истовремено употреблива. Тој исклучок за крајната точка е различен услов од исклучокот за DHCP, и без него тунелот може да го фати транспортот што го одржува.

За дестинација на апликација, испитајте го ефективното пребарување во контекстот каде што не успева. Поточни локални рути, рутирање по политика и исклучувања по апликација ги менуваат сите одговорот, така што присуството на две полустандардни рути не е попис на секој тек.

Остатокот од патеката не е во ова знаменце

Серверот и понатаму бара дозвола да го препраќа интернет сообраќајот на клиентот и излезна постава што може да го врати. Ниту една рута на страната на клиентот не создава недостапно препраќање или превод на изворот на серверот, и ниту едно знаменце не заменува работна повратна патека.

Претворањето на имиња и IPv6 секое бара своја политика. Замената на IPv4 ниту го насочува резолверот кон сервер на страната на тунелот, ниту воспоставува покриеност со IPv6, а клиент што пренасочува само v4 го остава патот v6 недопрен.

Споредете едно одобрено безопасно барање на работна и на неуспешна патека за пристап, држејќи ги профилот и дестинацијата непроменети. Запишете дали разликата е во претворањето на имиња, воспоставувањето на тунелот, изборот на рута или препратениот сообраќај, и чувајте го одговорот со профилот. Токму тој запис го спречува следниот човек да го обвини DHCP за проблем до кој тоа не може да стигне.