pull-filter у OpenVPN супадае з большым, чым маршрут, які вы мелі на ўвазе

Вы дадаяце адзін радок, каб захаваць свой лакальны маршрут па змаўчанні, і пасля гэтага тунель больш не дасягае ўнутранага DNS-сервера. Гэты радок быў pull-filter ignore "route", што не азначае "ігнараваць гэты маршрут". Ён азначае "адкінуць кожную прасунутую опцыю, тэкст якой пачынаецца з гэтых пяці літар", і на звычайным серверы гэта ўключае route-gateway, route-metric і route-ipv6 разам з самімі маршрутамі. Спіс праверкі ніжэй — гэта тое, што я праганяю перад тым, як крануць профіль, якім павінен карыстацца хтосьці іншы.

Фільтр дзейнічае толькі на прасунутыя опцыі

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

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

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

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Чытайце прасунуты радок як спіс опцый, падзеленых коскамі, і звярніце ўвагу, што назвы опцый і іх аргументы падзелены прабеламі. Ваш тэкст фільтра параўноўваецца з гэтым патокам, таму прабелы так важныя на наступным кроку.

Супастаўленне — гэта прэфікс, таму прабелы вырашаюць усё

Параўнанне — гэта прэфікс радка, а не разабраная назва опцыі. Таму "route" супадае з route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 і route-metric 100. Адзін прабел у канцы звужае яго да сямейства, якое вы, хутчэй за ўсё, мелі на ўвазе, а поўны прэфікс звужае яго да канкрэтнага прызначэння.

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

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

Тры дзеясловы з трыма рознымі вынікамі

accept, ignore і reject — гэта не тры напісанні адной ідэі. Яны адрозніваюцца тым, што кліент робіць з супадзеннем, і тым, ці нехта пра гэта даведаецца.

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

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

Праверце ўжыты маршрут і рэзалвер, а не профіль

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

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

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

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

Запішыце выключэнне і яго ўладальніка

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

Версія тут таксама важная. Паводзіны супастаўлення і дакладны прымальны сінтаксіс удасканальваліся ў OpenVPN 2.4, 2.5 і 2.6, таму пацвердзіце шаблон па кіраўніцтве для зборкі, якую вы пастаўляеце, а не па допісе на форуме пра старую версію. Кіраўніцтва OpenVPN 2.6 дакументуе гэтую опцыю і яе правіла супастаўлення.

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