Два 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

Запишете версиите на клиентите, интерфейсите, състоянието на резолвера и префиксите за всяка мрежа. Когато клиент се обнови и промени поведението си при маршрутизация, този запис е разликата между петминутна поправка и преустройство. Следващият човек няма да споделя паметта ви за това кой тунел е излязъл първи.

Списъкът е завършен, когато можете да назовете интерфейса, който притежава маршрута по подразбиране, резолвера, който използва всяко име, модела, който разделя втория тунел, и резултата от една заявка на мрежа след рестарт. Всичко по-малко е конфигурация, която просто случайно работи днес.