Два VPN клиента, една маршрутна таблица: кой печели маршрута по подразбиране

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

Конфликтът живее в маршрутната таблица

Виртуален адаптер плюс маршрут по подразбиране — така пълният тунел прихваща трафика. Когато вторият клиент инсталира свой маршрут по подразбиране, по-старият запис се заменя или понижава по метрика и всяка дестинация вече минава през по-новия тунел. Първият клиент остава свързан и все още показва зелена икона, тоест интерфейсът е активен, докато пътят е изчезнал. Точно това разделяне между състояние на връзката и състояние на маршрутизацията прави поведението объркващо.

Клиентите са редактори на една споделена таблица. Знанието коя промяна е била последна обяснява почти всеки симптом.

Прочетете кой тунел притежава текущия път

Проверете действителното решение, вместо да се доверявате на клиента, който съобщава, че е свързан. Попитайте системата кой интерфейс би понесъл конкретна дестинация.

ip route get 10.20.0.5
route print -4

Първата команда посочва интерфейса и изходния адрес за една дестинация, а това е точният въпрос, който ви интересува. Изхвърлянето на маршрутите показва конкуриращите се записи по подразбиране и техните метрики в Windows, така че виждате кой печели в момента. Изпълнете търсенето за хост във всяка отдалечена мрежа, защото една дестинация може да е правилна, докато другата мрежа е недостъпна. Ако отговорът посочи грешния тунел, повторното свързване няма да помогне; маршрутната политика трябва да се промени.

Спрете втория клиент да претендира за всичко

Единият клиент трябва да притежава маршрута по подразбиране, а другият да носи само своите префикси. OpenVPN клиенти могат да отказват това, което сървърът изтласква.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull игнорира всеки изтласкан маршрут, докато pull-filter ignore "redirect-gateway" изхвърля само директивата за маршрут по подразбиране и запазва изтласканите DNS и други опции. Изберете между тях според това колко от конфигурацията на сървъра все още искате, после добавете конкретните префикси, нужни на втората мрежа. Помнете DNS, защото резолвер, изтласкан от тунел, който не носи заявките, не връща нищо. Тествайте един известен хост във всяка мрежа и потвърдете изходния адрес, който вижда отдалечената страна.

Припокриващи се подмрежи не могат да бъдат заобиколени

Когато двете мрежи публикуват един и същ префикс, ядрото държи един запис за две различни места и трябва да избира. Хост маршрут не може да измисли липсващото разграничение, нито настройка на метриката. Пренаредете номерацията на едната страна или нека администраторът ѝ преведе отдалечения диапазон, за да се различават префиксите. Проверете реалните подмрежи, преди да обвинявате клиентите, защото домашният рутер по подразбиране 192.168.1.0/24 се сблъсква с офис диапазон по-често, отколкото някой очаква. Запишете двата диапазона в заявката, за да не пресъздаде следващата промяна припокриването.

Разделете и две цели: достигането до двете мрежи е маршрутен проблем, докато свързването на тунели за поверителност е различен дизайн с допълнителен оператор по пътя. Не използвайте едното, за да решите другото.