Кліент OpenVPN спыняецца, калі яго сервер працуе на тым жа хосце

У мяне была лабараторная машына, якая прымала тунель з аддаленага сайта і адначасова званіла ў сетку пастаўшчыка. Зыходны профіль працаваў тыднямі. Пасля дадання ўваходнага сервера зыходны падключыўся, а затым праз некалькі секунд перастаў прапускаць трафік або адмовіўся запусціцца з памылкай «адрас ужо выкарыстоўваецца». Канфігурацыйныя файлы не змяніліся; хост проста набыў другі працэс OpenVPN са сваім меркаваннем пра порты і маршруты.

Збой не выпадковы, і гэта не праблема аўтэнтыфікацыі. Два дэманы на адной машыне спаборнічаюць за адзін лакальны сокет і адну табліцу маршрутызацыі, і той, хто запусціўся або перападключыўся апошнім, звычайна перамагае. Веданне таго, якое з гэтых двух сутыкненняў у вас, вызначае, куды глядзець перш за ўсё.

Чытайце сімптом у адваротным кірунку

Пачніце з таго, калі тунель памірае. Памылка прывязкі пры запуску паказвае на бок праслухоўвання: нешта ўжо валодае гэтым портам, і OpenVPN адмаўляецца запускацца, а не дзяліць яго. Тунель, які ўзнімаецца і затым змаўкае, паказвае на маршрутызацыю, бо маршрут, усталяваны іншай копіяй, можа сцягнуць пакеты знешняга злучэння з іх шляху.

Абодва выпадкі даюць адну і тую ж скаргу карыстальніка, таму цыклы паўтору і скрыпты-вартавыя нічога не выпраўляюць. Яны зноў падключаюць кліента да таго ж канфлікту. Карыснае першае пытанне: ці працэс усё яшчэ працуе, калі трафік спыняецца.

Адзін сокет і адна прылада на кожную копію

Сервер, які слухае, прывязвае свой порт; зыходнаму кліенту таксама патрэбны лакальны порт для інкапсуляванага трафіку. Калі абодва жывуць на адным хосце, стандартныя паводзіны кліента могуць сутыкнуцца з портам сервера. Лакальны порт кліента можна замацаваць, а прывязку можна прапусціць там, дзе партнёру не патрэбны фіксаваны зыходны порт:

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-сервера ўсё яшчэ вырашаецца праз звычайную табліцу; табліца, якая захоплівае знешні транспарт, ламае тунель, які павінна была абараніць, і цыкл перападключэння, што ідзе за гэтым, выглядае як ненадзейны правайдар.

Для ўстаноўкі, якая павінна перажываць перападключэнні і перазапускі, сеткавая прастора імёнаў — больш трывалая мяжа. Другі кліент працуе ў сваёй прасторы імёнаў са сваімі інтэрфейсамі і маршрутамі, і агаляюцца толькі тыя службы, якія павінны перасякаць мяжу. Хост захоўвае адзін маршрут па змаўчанні, і перападключэнне прасторы імёнаў не можа яго перапісаць.

Правярайце па табліцы, а не па радку стану

Кліент, які паведамляе пра падключэнне, даказвае толькі свой канал кіравання. Зафіксуйце стан маршрутызацыі да і пасля кожнага падключэння, затым спытайце ў ядра, якую прыладу выкарыстала б рэальная мэта:

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

Калі выбраная прылада для адраса пастаўшчыка змяняецца пры запуску другога тунелю, у вас сутыкненне маршрутаў. Калі абодва працэсы паказваюцца на адным лакальным порце, у вас сутыкненне сокетаў. Выпраўленне першага без другога проста пераносіць збой на наступнае перападключэнне.

Запішыце порты, прылады, табліцы і ўладальніка маршруту ў runbook хоста. Інакш наступны чалавек, які дадасць трэці тунель, зноў знойдзе тое ж сутыкненне, і адзіным бачным доказам будзе злучэнне, якое працуе, пакуль не перазапусціцца дэман кагосьці іншага.