Што насамрэч дадае 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 у праблеме, да якой ён не можа дацягнуцца.