Шта 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 уноси се прескачу истим знаком, па упити за унутрашње домаћине иду оном resolver-у који је обезбедила локална мрежа. Тај resolver нема зону за канцеларију, па упит не успева или враћа јавни одговор, и квар изгледа као проблем сервера док је то проблем конфигурације клијента. Тестирање адресе пре имена је оно што раздваја то двоје.

Избор између заставице и филтера префикса

Две опције решавају различите облике исте жалбе, и управо лош избор ствара стање повезан-али-бескористан. Једна у потпуности замењује гурнуту политику, друга је уређује по префиксу. Табела даје кратку верзију, а пасус после ње покрива део који људе изненади.

pull-filter је поклапач префикса са три глагола, па може да прихвати фамилију линија, тихо их игнорише или потпуно одбије везу када се префикс појави. Управо последње понашање вреди знати: правило одбијања претвара политичку неслогу у неуспешно руковање уместо у тихо изостављање. Приручник OpenVPN 2.6 наводи прихваћене префиксе и тачно значење сваког глагола.

Чест средњи пут је одбити само redirect-gateway и пустити руте канцеларије и DNS да стигну како је предвиђено. То одржава гурање функционалним за делове које сервер разуме боље од вас, а истовремено спречава ону једну линију која би преузела вашу подразумевану руту.

Ручно додавање рута и resolver-а

Ако задржите заставицу, профил мора да каже оно што би сервер рекао. Клијентске директиве route примењују се после успостављања везе, па раде уз заставицу уместо да их она блокира. Ставите их у профил, а не у интерактивну командну линију, иначе следеће поновно повезивање неће поновити радно стање.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS линија стоји на непријатном месту: то је клијентска директива, али неки клијенти је примењују само кроз DNS интеграцију платформе, која је може преписати када се веза промени. На systemd домаћину, постављање resolver-а директно на интерфејс тунела предвидиво је више од наде да ће клијент победити у такмичењу приоритета:

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

Домен рутирања је важан колико и адреса. Без њега, упити за јавна имена могу се слати и унутрашњем resolver-у, а сваки унутрашњи resolver који одбија рекурзију поквариће прегледање док приватна зона наставља да ради. С њим, само имена под тим суфиксом рутирају се ка resolver-у тунела, а све остало следи физичку везу.

Провера резултата: адреса, име и спољна путања

Три теста раздвајају могуће кварове. Узмите приватну адресу по IP-у, затим исти домаћин по имену, затим обичан јавни сајт. Радни IP са неуспешним именом указује на resolver; неуспешан IP са радним именом указује на рутирање; ако оба не успеју, обично тунела нема на путу.

Затим гледајте напоље, а не унутра. Сопствена рута крајње тачке тунела мора да преживи промену, и сваки блокирајући квар мора бити ограничен на тунел без хватања крајње тачке. Клијент који настави да прегледа после пада тунела је проблем политике, не рутирања, и неће се појавити ни у једном од три теста горе.

Упишите коначну листу у документацију профила: руте, resolver, домене и разлог зашто сваки постоји. Поновно повезивање које понови исту табелу једини је доказ да је локална политика потпуна. Ако апликације и даље не успевају док је тунел подигнут и сва три теста положена, следеће место за поглед је класа проблема повезан-али-офлајн, а не већ проверени сертификати.