Поўны тунэль FortiClient: маршрутызаваць толькі офісную падсетку

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

Што ўсталяваў кліент і чаму знікла лакальная сетка

Пачніце з чытання табліцы, а не інтэрфейсу кліента. У macOS netstat -rn друкуе ўсю табліцу, а route -n get default называе інтэрфейс і метрыку, якія цяпер перамагаюць; у Linux пара — ip route show і ip route get 8.8.8.8. Абодва адказваюць на адно пытанне: які запіс панясе пакет, што не адпавядае нічому больш канкрэтнаму.

Назва тунэльнага прыстасавання не фіксаваная. Профіль IKEv2 у macOS звычайна паказвае utun з нумарам, кліент SSL VPN паказвае ppp0, а OpenVPN — tun0. Два маршруты па змаўчанні могуць прысутнічаць адначасова з рознымі метрыкамі, і запіс кліента можа перахапіць толькі пасля перападлучэння, а не ў момант з'яўлення. Таму два здымкі табліцы з розніцай у пяць хвілін могуць расказваць розныя гісторыі.

Чаму маршрут па змаўчанні тунэля павінен сысці першым

Ядро выбірае найдаўжэйшы адпаведны прэфікс, а калі некалькі маршрутаў аднолькава канкрэтныя — той, у якога метрыка ніжэйшая. Таму кліент, які ўсталёўвае 0.0.0.0/0 з лепшай метрыкай, выйграе кожны пункт прызначэння, не выдаляючы зыходны маршрут па змаўчанні; вось чаму фізічны маршрут усё яшчэ ў табліцы і ўсё яшчэ тлумачыць перапынак. Выдаленне маршруту па змаўчанні тунэля першым вяртае папярэднія паводзіны. Толькі пасля гэтага прэфіксны маршрут праз тунэль робіць тое, што меў на ўвазе аўтар.

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

Паслядоўнасць у macOS і Linux

У macOS паслядоўнасць выдаляе маршрут па змаўчанні тунэля, аднаўляе фізічны маршрут па змаўчанні і вяртае адзін офісны прэфікс у тунэль. Замяніце ілюстрацыйныя назвы інтэрфейсаў тут на свае з табліцы.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

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

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Калі маршруту патрэбен наступны пераход, а не прыстасаванне, вазьміце peer з вываду кліента. Здагадка дае адну з дзвюх памылак, і яны азначаюць рознае: няправільны шлюз адразу дае network unreachable, а няправільная мэта тунэля — таймаўт. Прачытайце, якую вы атрымалі, перш чым зноў мяняць каманду.

Прэфіксы, рэзальвер і DMZ, якая застаецца цёмнай

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

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

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

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Прачытайце два значэнні, перш чым запусціць. peer — гэта далёкі канец тунэля пункт-пункт, і менавіта гэты адрас патрэбен маршруту DMZ; у маршрутызаваным тунэлі эквівалент — інтэрфейс або шлюз, які паведамляе кліент. Калі ні адно не з'яўляецца, кліент не ў тым рэжыме, які вы меркавалі.

Пасля наступнага падключэння і калі спыніць рабіць гэта лакальна

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

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

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