Што OpenVPN route-nopull насамрэч перашкаджае серверу праштурхоўваць

Вы ўпісалі route-nopull у профіль кліента, каб тунель не праглынуў маршрут па змаўчанні, і цяпер падсетка офіса недасяжная, хаця кліент па-ранейшаму кажа, што злучаны. Абедзве назіранні праўдзівыя, і нічога не зламалася. Сцяг кажа кліенту прапусціць маршруты і запісы DHCP, якія праштурхоўвае сервер, і гэта больш вузкая інструкцыя, чым чакае большасць людзей, калі дадае яе. Застаецца працоўны тунель без меркавання пра тое, якія пункты прызначэння павінны ім карыстацца.

Гэтая прага — і ёсць усё рашэнне, якому прысвечаны артыкул. Альбо сервер апісвае сетку, альбо гэта робіць кліент, і сцяг перадае гэтую працу кліенту, не робячы за вас нічога з яе.

Што сцяг адключае ў момант злучэння

Кліент OpenVPN, які цягне, звычайна атрымлівае ад сервера пасля аўтэнтыфікацыі пакет: маршруты, перанакіраванне шлюза па змаўчанні, DNS-серверы і некалькі дырэктыў наладкі. Калі дзейнічае route-nopull, кліент па-ранейшаму прымае сеанс, па-ранейшаму правярае сертыфікаты, па-ранейшаму ўзгадняе шыфры і keepalive і па-ранейшаму ўздымае інтэрфейс. Адкідае ён прымяненне праштурхнутых радкоў route і праштурхнутых радкоў dhcp-option, уключаючы DNS.

Блытаніна ўзнікае з-за зялёнага індыкатара побач з мёртвай праграмай. Тунель існуе; сувязі пунктаў прызначэння з гэтым тунелем няма. Нішто ў панэлі стану кліента не адрознівае «злучана і маршрутызуе» ад «злучана і бяздзейнічае», бо з пункту гледжання тунеля абодва станы аднолькавыя.

Чаму жывы тунель можа не маршрутызаваць нічога

Інтэрфейс з'яўляецца са сваім адрасам, і на двухкропкавым злучэнні часта няма нічога больш канкрэтнага, чым маршрут да вузла-партнёра. Прыватная падсетка становіцца дасяжнай толькі тады, калі нейкі маршрут паказвае на гэты інтэрфейс з правільным прэфіксам, а пры адключаным штурханні гэты маршрут ніколі не прыходзіць. Спампаваны профіль таксама звычайна не дапаможа, бо ён напісаны з разлікам на тое, што сервер падасць менавіта гэтую інфармацыю. Таму інтэрфейс можа выглядаць здаровым, пакуль падсетка застаецца цёмнай.

Такім чынам, чытанне профілю даказвае вельмі мала. Чытайце бягучы стан на злучанай машыне:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Адрас без маршруту падсеткі ў другой камандзе — гэта подпіс гэтай праблемы. Трэцяя каманда адказвае на пытанне, якое насамрэч хвалюе карыстальнікаў, бо паведамляе пра інтэрфейс, які выбера ядро для канкрэтнага пункта прызначэння, а не пра спіс, на які вы спадзяваліся. Калі яна адказвае праз ваша фізічнае злучэнне, тунеля ў шляху няма зусім.

Развязанне імёнаў не спраўляецца па звязанай прычыне, а не па асобнай. Праштурхнутыя запісы dhcp-option DNS прапускаюцца тым жа сцягам, таму запыты пра ўнутраныя хасты ідуць да таго рэзалвера, які дала лакальная сетка. У гэтага рэзалвера няма зоны для офіса, таму запыт не спраўляецца ці вяртае публічны адказ, і збой выглядае як праблема сервера, хоць гэта праблема канфігурацыі кліента. Праверка адраса перад імем — гэта тое, што аддзяляе адно ад другога.

Выбар паміж сцягам і фільтрам прэфіксаў

Два варыянты вырашаюць розныя формы адной і той жа скаргі, і менавіта дрэнны выбар стварае стан «злучана, але бескарысна». Адзін цалкам замяняе праштурхнутую палітыку, другі рэдагуе яе па прэфіксе. Табліца дае кароткі варыянт, а абзац пасля яе ахоплівае тую частку, якая збівае людзей з панталыку.

pull-filter — гэта супастаўшчык прэфіксаў з трыма дзеясловамі, таму ён можа прымаць сямейства радкоў, моўчкі іх ігнараваць або цалкам адхіляць злучэнне, калі з'яўляецца прэфікс. Менавіта апошнія паводзіны варта ведаць: правіла адхілення ператварае разыходжанне ў палітыцы ў няўдалае рукапацісканне, а не ў ціхі пропуск. Кіраўніцтва OpenVPN 2.6 пералічвае прынятыя прэфіксы і дакладную семантыку кожнага дзеяслова.

Часты сярэдні шлях — адхіліць толькі redirect-gateway і даць маршрутам офіса і DNS прыйсці як задумана. Гэта захоўвае штурханне працоўным для тых частак, якія сервер разумее лепш за вас, і адначасова перашкаджае таму адзінаму радку, які заняў бы ваш маршрут па змаўчанні.

Даданне маршрутаў і рэзалвера ўручную

Калі вы пакідаеце сцяг, профіль павінен сказаць тое, што сказаў бы сервер. Дырэктывы route на баку кліента прымяняюцца пасля ўсталявання злучэння, таму яны працуюць разам са сцягам, а не блакуюцца ім. Змесціце іх у профіль, а не ў інтэрактыўны радок каманд, інакш наступнае перападключэнне не ўзнавіць працоўны стан.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Радок DNS стаіць у нязручным становішчы: гэта дырэктыва на баку кліента, але некаторыя кліенты прымяняюць яе толькі праз DNS-інтэграцыю платформы, якая можа перазапісаць яе пры змене злучэння. На хастле з systemd наладзіць рэзалвер непасрэдна на тунельным інтэрфейсе больш прадказальна, чым спадзявацца, што кліент выйграе спаборніцтва прыярытэтаў:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Домен маршрутызацыі важны не менш за адрас. Без яго запыты пра публічныя імёны таксама могуць ісці да ўнутранага рэзалвера, а любы ўнутраны рэзалвер, які адмаўляе рэкурсію, зломіць прагляд, пакідаючы прыватную зону працаздольнай. З ім да рэзалвера тунеля накіроўваюцца толькі імёны пад гэтым суфіксам, а ўсё астатняе ідзе па фізічным злучэнні.

Праверка выніку: адрас, імя і вонкавы шлях

Тры тэсты аддзяляюць магчымыя збоі. Атрымайце прыватны адрас па IP, потым той жа хост па імені, потым звычайны публічны сайт. Працоўны IP з няўдалым імем паказвае на рэзалвер; няўдалы IP з працоўным імем паказвае на маршрутызацыю; калі не працуе і тое і другое, звычайна тунеля няма ў шляху.

Затым глядзіце вонкі, а не ўнутр. Уласны маршрут канцавой кропкі тунеля павінен перажыць змену, а любое блакаванне павінна абмяжоўвацца тунелем, не захопліваючы канцавую кропку. Кліент, які працягвае праглядаць пасля падзення тунеля, — гэта праблема палітыкі, а не маршрутызацыі, і яна не выявіцца ні ў адным з трох тэстаў вышэй.

Запішыце канчатковы спіс у дакументацыю профілю: маршруты, рэзалвер, дамены і прычыну існавання кожнага. Перападключэнне, якое ўзнаўляе тую ж табліцу, — адзіны доказ таго, што лакальная палітыка поўная. Калі праграмы ўсё яшчэ не спраўляюцца пры ўзнятым тунелі і ўсіх трох пройдзеных тэстах, наступнае месца для пошуку — клас праблем «злучана, але афлайн», а не сертыфікаты, якія ўжо правераны.