pull-filter на OpenVPN се совпаѓа со повеќе од маршрутата што ја мислевте
pull-filter го споредува вашиот текст како префикс со турканите опции, па route ги фаќа и route-gateway и route-ipv6. Прво проверете ги глаголите, потоа маршрутите.
Додавате една линија за да ја задржите локалната стандардна маршрута, и потоа тунелот повеќе не стигнува до внатрешниот 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. Едно празно место на крајот го стеснува до семејството што веројатно го мислевте, а целосниот префикс го стеснува уште повеќе до конкретна дестинација.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
Последниот ред е оној што ги фаќа луѓето при работа со поделен тунел. Да го задржите својот resolver е легитимен избор и значи дека секое внатрешно име сега зависи од resolver што не ја гледа приватната зона. Тоа е последица што се прифаќа намерно, а не несакан ефект што се открива во производство.
Совпаѓањето по префикс значи и дека правилото може подоцна тивко да се прошири. Кога серверот додава нова опција што започнува со вашиот текст, вашиот филтер почнува да се применува на неа без некој да го уредува вашиот профил. Тоа е режимот на грешка против кој треба да се проектира, а ублажувањето е да се совпадне што е можно поголем дел од опцијата, а не што е можно помал.
Три глаголи со три различни исходи
accept, ignore и reject не се три правописи на истата идеја. Тие се разликуваат по тоа што прави клиентот со совпаѓање и по тоа дали некој ќе дознае.
ignore тивко ја фрла соодветната опција, што е она што го сакате за поставка што намерно сте ја замениле. reject ја фрла и го тера клиентот да се жали, што е она што го сакате кога нејзиното отсуство треба да се види во дневник наместо да се открие подоцна. accept е позитивната форма, се користи кога градите список за дозвола наместо да отстранувате поединечни опции.
Кое и да е глаголот што го користите, филтрите се применуваат по редоследот по кој се појавуваат, па две правила што се преклопуваат даваат резултат зависен од редоследот и многу тежок за преглед. Држете едно правило по намера и во секое ставете го најконкретниот текст. Ако ви треба список за дозвола, претпочитајте неколку правила accept пред куп правила ignore што се собираат на истото. Тогаш прегледувачите можат да ја прочитаат датотеката од горе надолу и да го предвидат резултатот, и тоа е единствениот тест што се скалира.
Проверете ја применетата маршрута и resolver, не профилот
Филтер што изгледа точно во датотеката сепак може да ве остави со тунел што не насочува ништо корисно. Проверете го ефектот на системот што работи, каде турканите опции веќе се применети или фрлени:
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/
Првите две линии ви кажуваат дали пристигна турканата стандардна маршрута и колку статични записи преживеале. Барањето до resolver покажува кој сервер интерфејсот на тунелот навистина го користи, и таму обично се појавува изненадување со DNS. Последната линија одговара на единственото прашање што е важно за корисникот.
Тестирајте ги двата правци додека сте таму. Правило што го одржува вашиот локален интернет функционален но тивко го крши внатрешното разрешување имиња поминува површна проверка и паѓа на првата вистинска задача, затоа вклучете еден внатрешен ресурс и еден јавен сајт во истиот тест.
Запишете го исклучокот и неговиот сопственик
Филтерот е исклучок од дизајнот на операторот, затоа запишете го со причина и точка за преглед. „Ги игнорира турканите маршрути за да ја задржи локалната стандардна“ е прегледно; гола линија во профил не е, и следниот човек ќе ја избрише или ќе ја прошири со погодување.
Верзијата е важна и овде. Однесувањето при совпаѓање и точната прифатена синтакса се усовршувани низ OpenVPN 2.4, 2.5 и 2.6, затоа потврдете ја шемата според прирачникот за изданието што го доставувате, а не според форумски пост за постара верзија. Прирачникот на OpenVPN 2.6 ја документира опцијата и нејзиното правило за совпаѓање.
На крајот, договорете го исклучокот со тој што го води серверот. Клиентски филтер што противречи на намерна серверска политика е инцидент за поддршка што чека следен одит, и многу е поевтино да се среди пред профилот да биде испратен отколку откако некој ќе забележи дека маршрутите недостасуваат.