Што 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 со работно име упатува на рутирањето; ако и двете не успеат, обично тунелот не е на патот.

Потоа гледајте кон надвор, а не кон внатре. Сопствената рута на крајната точка на тунелот мора да ја преживее промената, и секој блокирачки дефект мора да биде ограничен на тунелот без да ја фати крајната точка. Клиент што продолжува да прелистува откако тунелот ќе падне е проблем на политиката, не на рутирањето, и нема да се појави во ниту еден од трите теста погоре.

Запишете ја конечната листа во документацијата на профилот: рутите, разрешувачот, домените и причината зошто постои секој. Повторното поврзување што ја репродуцира истата табела е единствениот доказ дека локалната политика е целосна. Ако апликациите сѐ уште не успеваат додека тунелот е подигнат и сите три теста се поминати, следното место за гледање е класата проблеми поврзан-но-офлајн, а не веќе проверените сертификати.