Чаму другі VPN-тунэль ламае першы?

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

Сімптом: другі кліент ціха перамагае

OpenVPN: параметр redirect-gateway def1 не перазапісвае 0.0.0.0/0. Ён дадае 0.0.0.0/1 і 128.0.0.0/1: разам яны ахопліваюць кожны адрас IPv4, і кожны прэфікс пераўзыходзіць звычайны маршрут па змаўчанні па даўжыні. Першапачатковы маршрут па змаўчанні застаецца ў табліцы і больш не выкарыстоўваецца для звычайнага трафіку, а маршрут да хоста сервера VPN не дазваляе тунэлю захопліваць уласныя знешнія пакеты. Абодва кліенты робяць гэта, і другі проста ўсталёўвае сваю пару пазней.

Таму першы тунэль выглядае мёртвым, а не адключаным. Яго інтэрфейс уключаны, канал кіравання жывы, і ніякі трафік праграм да яго больш не даходзіць. Зваротная скарга мае тую ж прычыну — адсутнасць push: тэлефон, які падключаецца, але нічога не адпраўляе, звычайна размаўляе з серверам, які ніколі не абвяшчаў redirect-gateway, таму прылада захоўвае ўласны маршрут па змаўчанні і дасягае толькі пул.

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

Прачытайце, які тунэль сапраўды перамагае

Не рабіце выснову пра пераможцу з парадку запуску кліентаў або з значка ў латцы. Спытайце ядро, які маршрут яно выкарыстае для пункту прызначэння па-за абодвума прыватнымі сеткамі, і прачытайце інтэрфейс, які вернецца.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Першыя два — адказ Linux, апошнія два — эквівалент Windows. Выканайце іх, пакуль абодва тунэлі ўключаны, затым адключыце адзін і выканайце зноў. Розніца паміж двума вынікамі — факт, патрэбны перад выбарам рашэння, і гэта хутчэй, чым чытаць журнал любога кліента.

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

Windows: не дазваляйце аднаму профілю валодаць маршрутам па змаўчанні

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

Linux: трымайце другі тунэль па-за асноўнай табліцай

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

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Прасторы імёнаў сеткі — найцяжэйшы і найчысцейшы варыянт. Запусціце другі кліент унутры ip netns, дайце яму пару veth і ўвайдзіце ў гэтую прастору, каб карыстацца ім. Перашкоды знікаюць, бо кожная прастора мае ўласныя табліцы замест агульнай; гэта варта дадатковай наладкі, калі абодва тунэлі мусяць трымацца тыднямі.

Па праграмах і ланцуг як асобная праблема

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

Ланцуговае злучэнне — іншая аперацыя, чым запуск двух тунэляў побач. Злучыць A праз B значыць, што адрас унутранага сервера мусіць быць дасяжны знутры знешняга тунэля. Знешні кліент таксама не павінен прымаць зашыфраваныя пакеты ўнутранага кліента за ўцечку. Адзін кліент унутры віртуальнай машыны — грубы, але надзейны варыянт; абодва на адным хосце патрабуюць працы з маршрутамі вышэй плюс знешняга шляху да ўнутранага сервера, які ніколі не ўваходзіць ва ўнутраны тунэль.

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