На Pi-ју раде два OpenVPN процеса која истовремено прихватају кориснике у покрету и достижу добављача изнад, и они не деле готово ништа осим хардвера. Један ослушкује долазне тунеле, други зове напоље. Сваки чита свој директоријум, и сваки има сопствени режим отказа. Поновно покретање погрешне јединице је најчешћи начин на који поправка клијента уместо тога пољуља слушаоца.

Ускладите назив јединице са директоријумом који учитава

Upstream 2.6 испоручује две шаблонске јединице, [email protected] и [email protected]. Шаблон сервера почиње у /etc/openvpn/server и одатле учитава %i.conf. Шаблон клијента почиње у /etc/openvpn/client. Инстанца под именом roaming може постојати на оба места истовремено, као сервер и као клијент, са две неповезане конфигурације и без икакве везе међу њима осим низа.

Питајте systemd, а не фајл систем, јер паковањари додају додатне фајлове који могу да промене радни директоријум или аргументе које бинарни фајл прима.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

Одлучите по смеру пакета, а не по називу интерфејса

Инстанца сервера има ослушкујући сокет и прихвата везе. Њен шифровани транспорт је локални улаз и локални излаз на Pi-ју, док саобраћај који прослеђује за кориснике прати путању прослеђивања и одговара другом скупу правила. Инстанца клијента у том смислу нема слушаоца: зове партнера, па је њен шифровани транспорт локални излаз ка доњем слоју.

Та разлика вам каже где правило припада. Правило које одговара интерфејсу унутар ланца прослеђивања само дозвољава саобраћај који је рутирање већ изабрало; оно никада не бира путању. Када пакети корисника у покрету изађу погрешним путем, ланац који треба прегледати је forward, а не output.

Погледајте сокете пре него што почнете да теоретишете. Сервер везан за udp/1194 показује ослушкујући сокет. Клијент показује асоцијацију са адресом добављача и ништа што ослушкује.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Подразумевана путања једне инстанце може да ухвати одговоре друге

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

Симптом је обично асиметричан. Руковање се завршава, клијент пријављује везу, и саобраћај умире после првог пакета одговора. Рутирање политике засновано на извору, или ознака пакета постављена на инстанци сервера са --mark, држи два тока одвојено; ниједно само по себи није потпун скуп правила, и оба захтевају важеће путање у табели коју изаберу.

Тестирајте локалну одлуку, а не стање тунела, јер кернел бира извор и интерфејс пре него што OpenVPN види пакет.

ip route get 203.0.113.44
ip rule show

Поново покрените једну улогу и докажите да је друга преживела

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

Запишите услов заустављања пре промене: да ли губитак горњег тунела блокира кориснике у покрету, или се враћа на сопствени горњи линк Pi-ја? DNS и IPv6 такође захтевају јасан одговор, јер гурнути резолвер често живи дуже од путање која га је учинила корисним.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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

Повезани чланци