Два кліенты 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 па змаўчанні сутыкаецца з офісным дыяпазонам часцей, чым хто-небудзь чакае. Занатуйце абодва дыяпазоны ў заяўцы, каб наступнае змяненне не аднавіла перакрыццё.

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