Сервер і кліент OpenVPN на адным хосце: чаму кліенты адвальваюцца

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

Адна машына, дзве ролі і два несумяшчальныя адказы на пытанне, куды павінны ісці адказы.

Адзін пул, два серверы: хто перамагае

Кожнаму экзэмпляру сервера патрэбна ўласная падсетка тунеля. Калі скапіяваць радок накшталт server 10.8.0.0 255.255.255.0 у другую канфігурацыю, два экзэмпляры атрымаюць адзін і той жа прэфікс, і вынікам будзе альбо адмова запускацца, альбо ціхая барацьба, у якой кліенты аднаго сервера атрымліваюць адрасы, якія другі таксама лічыць сваімі. Розныя UDP-порты і розныя імёны прылад не дапамагаюць, бо ні тое, ні тое не закранае адрасную прастору. Змяніце другі пул і змяніце яго ўсюды, дзе пра яго згадваюць маршруты.

Пералічыце, што ўжо працуе, перад правакамі: ip -4 addr show паказвае тунельныя прылады, ss -lunp паказвае слухачоў, а systemctl list-units называе юніты. Аднаго погляду на адрасы тунеляў дастаткова, каб вырашыць, ці сутыкаюцца пулы.

Што кліенцкі профіль дадае ў табліцу

Кліенцкая палова запісвае маршруты адразу пасля злучэння. redirect-gateway def1 разбівае маршрут па змаўчанні на 0.0.0.0/1 плюс 128.0.0.0/1, абодва ідуць праз новую прыладу, разам з маршрутам да вядучага вузла да далёкага сервера, які наўмысна замацаваны за фізічным інтэрфейсам. Гэтае замацаванне патрэбна, каб тунель меў шлях для ўласнага транспарту. Усё астатняе, уключаючы адказы, якія лакальны сервер вінен сваім кліентам, цяпер ідзе новым маршрутам па змаўчанні і выходзіць праз далёкае злучэнне.

Значыць, другая калізія — гэта не зламаны тунель. Гэта працоўны тунель, які стаіць у табліцы не на сваім месцы.

Тры спосабы развесці ролі

Найменш інвазіўнае выпраўленне трымае маршрут па змаўчанні па-за кліенцкім профілем: route-nopull плюс яўныя радкі route для далёкіх прэфіксаў, так што лакальная табліца змяняецца толькі там, дзе вы прасілі. Наступны крок — палітыка, якая вызваляе лакальную падсетку тунеля і дазваляе адказам для лакальных кліентаў выходзіць праз той інтэрфейс, праз які яны прыйшлі, нават калі маршрут па змаўчанні існуе. Самае грунтоўнае — асобная сеткавая прастора імёнаў для кліенцкай ролі: яна цалкам прыбірае агульную табліцу і каштуе другога кантэксту маршрутызацыі ў абслугоўванні.

Які б шлях вы ні выбралі, выключэнне павінна называць лакальную падсетку тунеля, а не LAN. Адказ, які дасылае лакальны сервер, мае пунктам прызначэння адрас тунеля, таму выключэнне ў форме LAN ніколі не супадае з ім.

Які з двух экзэмпляраў вінаваты

Спыніце кліенцкі экзэмпляр і пераправерце першапачатковых кліентаў. Імгненнае аднаўленне азначае маршрутызацыю, а не сервер. Вярніце кліент і прасачыце адзін адказ з дапамогай ip route get, якому пададзены і адрас крыніцы, і адрас прызначэння: ён паказвае шлях, які выбера ядро, а потым паназірайце за інтэрфейсам, які рэальна выкарыстоўваюць пакеты, праз tcpdump -ni any port 1194. Файл стану сервера, які пішацца кожныя некалькі секунд праз дырэктыву status, змяшчае спіс падлучаных кліентаў і байтавыя лічыльнікі ў абодвух кірунках.

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