OpenVPN клијент се заглави када његов сервер ради на истом хосту

Имао сам лабораторијску машину која је примала тунел са удаљене локације и истовремено се повезивала на мрежу добављача. Одлазни профил је радио недељама. Након што је долазни сервер додат, одлазни се повезао и затим престао да пропушта саобраћај у року од неколико секунди, или је одбио да се покрене са грешком да је адреса већ у употреби. Конфигурационе датотеке нису биле промењене; хост је једноставно добио други OpenVPN процес са сопственим мишљењем о портовима и рутама.

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

Прочитајте симптом уназад

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

Оба случаја производе исту корисничку примедбу, због чега петље поновног покушаја и watchdog скрипте не поправљају ништа. Оне поново повезују клијента у исти сукоб. Корисно прво питање је да ли процес још ради када саобраћај стане.

Један сокет и један уређај по инстанци

Сервер који слуша везује свој порт; одлазном клијенту је такође потребан локални порт за његов инкапсулирани саобраћај. Када оба живе на истом хосту, задано понашање клијента може се сударити с портом сервера. Локални порт клијента може се фиксирати, а везивање се може прескочити тамо где партнеру није потребан фиксни изворни порт:

lport 1195
nobind
dev tun1

Ти бројеви су примери, не захтев. Важно је да клијент престане да се такмичи за порт сервера и да свака инстанца добије засебан тунелски уређај. Два демона која деле tun0 преписују стање уређаја један другоме чак и када се њихови портови разликују, па један уређај по тунелу није опционалан.

nobind припада клијентској страни. Сервер и даље мора везивати и слушати, зато не копирајте линију у конфигурацију сервера и не искључујте везивање на клијенту чији партнер филтрира на фиксни изворни порт.

Изаберите једног власника задате руте

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Адресе и број табеле изнад су резервисани. Одмах након додавања правила потврдите да се властита адреса VPN сервера још увек разрешава кроз нормалну табелу; табела која хвата спољни транспорт квари тунел који је требало заштитити, а петља поновног повезивања која следи изгледа као непоуздан провајдер.

За поставку која мора преживети поновна повезивања и рестарте, мрежни namespace је чвршћа граница. Други клијент ради унутар свог namespace-а са својим интерфејсима и рутама, а излажу се само сервиси који морају прећи границу. Хост задржава једну задату руту, а поновно повезивање namespace-а је не може преписати.

Проверите табелом, не статусном линијом

Клијент који пријави да је повезан доказује само свој контролни канал. Забележите стање рутирања пре и после сваког повезивања, затим питајте кернел који би уређај користило стварно одредиште:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

Запишите портове, уређаје, табеле и власника руте у runbook хоста. Иначе ће следећа особа која дода трећи тунел поново открити исту колизију, а једини видљиви доказ биће веза која ради док се не рестартује нечији туђи демон.