Какво всъщност добавя 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 за проблем, до който то не може да достигне.