Два VPN-кліенты на адным працоўным стале: што сутыкаецца і што працуе

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

Крок 1: вызначце, які кліент валодае выхадам

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

ip route get 1.1.1.1
ip route show default
route print

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

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

Крок 2: праверце рэзалвер і перакрыжаваныя прэфіксы

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Затым параўнайце прыватныя прэфіксы, якія выкарыстоўваюць дзве сеткі. Калі абодва бакі выдзяляюць з аднаго дыяпазону, ніякая налада з боку кліента не выправіць гэта, бо машына не можа сказаць, які адрас 10.0.0.0/8 належыць якому тунелю. Адзін бок трэба перанумараваць або трансляваць, і гэта размова з уладальнікамі сетак, а не змена канфігурацыі. Перакрыццё — адзінае сутыкненне, дзе сумленны адказ у тым, што праект трэба змяніць.

Спыніцеся тут, калі прэфіксы перакрываюцца. Усё далейшае ў гэтым спісе мяркуе, што яны не перакрываюцца.

Крок 3: выберыце схему падзелу, якая трымаецца

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

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

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

Крок 4: праверце абедзве сеткі з аднаго сеансу

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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