Какво всъщност спира route-nopull на OpenVPN да изпраща сървърът

Сложихте 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 с работещо име сочи към маршрутизирането; и двете неуспешни обикновено означават, че тунелът не е в пътя.

После гледайте навън, а не навътре. Собственият маршрут на крайната точка на тунела трябва да оцелее при промяната, а всяко блокиране на повреда трябва да е ограничено до тунела, без да залавя крайната точка. Клиент, който продължава да разглежда след падане на тунела, е проблем на политиката, не на маршрутизирането, и няма да се появи в нито един от трите теста по-горе.

Запишете крайния списък в документацията на профила: маршрутите, резолвера, домейните и причината всеки да съществува. Повторно свързване, което възпроизвежда същата таблица, е единственото доказателство, че локалната политика е пълна. Ако приложенията все още се провалят при вдигнат тунел и всички три теста минати, следващото място за гледане е класът проблеми „свързан, но офлайн“, а не сертификатите, които вече са проверени.