Два 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 кућног рутера судара се са канцеларијским опсегом чешће него што ико очекује. Забележите оба опсега у тикету да следећа измена не би поново створила преклапање.

Одвојте и два циља: стизање до обе мреже је проблем рутирања, док је ланчано повезивање тунела ради приватности други дизајн са додатним оператером на путањи. Не користите једно да решите друго.