Як адрозніць маршруты, прасунутыя VPN, ад статычных у Linux

Прэфікс з'яўляецца на ноўтбуку, калі паднімаецца тунэль, таму здаецца, што яго ўсталяваў VPN. Магчыма, так і было, але той жа вынік можа даць кліенцкі скрыпт, які запускаецца пры падключэнні, профіль злучэння са спісам падсеткі або статычны маршрут, які быў там увесь час і пачаў працаваць толькі тады, калі з'явіўся інтэрфейс. Выбар няправільнага ўладальніка азначае, што маршрут вяртаецца пасля кожнай чысткі, і наступны чалавек паўтарае тое ж выпраўленне. Паслядоўнасць ніжэй раздзяляе гэтыя тры выпадкі перш чым нешта змяняць.

Крок 1: назавіце механізм, які ўсталёўвае прэфіксы

Розныя пратаколы забяспечваюць дасяжнасць рознымі спосабамі, і называць усё гэта аб'явай значыць хаваць розніцу. Сервер OpenVPN перадае дырэктыву маршруту праз канал кіравання, і кліент усталёўвае яе, калі гэтага не блакуе фільтр pull. Канфігурацыя WireGuard пералічвае дазволеныя прэфіксы лакальна, і кліент выкарыстоўвае іх як для маршрутызацыі крыптаключоў, так і для маршрутаў, якія дадае. Тунэль IPsec узгадняе селектары трафіку з партнёрам, і ядро ўсталёўвае маршруты з гэтых селектараў.

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

Крок 2: параўнайце табліцу падчас падключэння

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

Зрабіце здымак з ip route show table main > /tmp/route-down.txt, падключыцеся і зрабіце здымак зноў. Зрабіце тое ж самае для ip -6 route, калі сайт выкарыстоўвае IPv6, бо адсутны прэфікс там спараджае збоі, якія выглядаюць не звязанымі з маршрутызацыяй.

Крок 3: чытайце метрыку, а не толькі наяўнасць

Два запісы для аднаго прэфікса могуць суіснаваць, і ядро выбірае меншую метрыку. Статычны маршрут з метрыкай 50 будзе перамагаць прасунуты маршрут з метрыкай 100, нават калі бачныя абодва, таму «маршрут ёсць» і «трафік ідзе праз яго» розныя сцвярджэнні.

Спытайце ядро напрамкі праз ip route get 10.20.5.7 і прачытайце інтэрфейс, які яно пакажа. Калі трафік выходзіць праз фізічны адаптар, пакуль маршрут тунэля ляжыць у табліцы, гэта тлумачыць метрыка або даўжыня прэфікса, а не кліент VPN. Паўтарыце пошук для хоста, які, як вы ведаеце, знаходзіцца за тунэлем, і для таго, які, як вы ведаеце, не, і розніца пакажа, ці падзел працуе як задумана.

Крок 4: знайдзіце запісы, якія перажываюць тунэль

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

Праверце пастаянны бок у тым месцы, якое выкарыстоўвае ваш дыстрыбутыў: ці гэта модуль systemd-networkd, профіль NetworkManager або скрыпт у каталогу up кліента. Выпраўленне жывой табліцы праз ip route del трымаецца толькі да наступнага падключэння. Стаўцеся да гэтага выдалення як да праверкі гіпотэзы, а не як да рамонту.

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

Крок 5: пацвердзіце зваротны шлях, перш чым вінаваціць кліента

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

Фільтрацыя зваротнага шляху дадае другую пастку на шлюзах Linux. Адказ, які прыходзіць на іншы інтэрфейс, чым прадказвае маршрут, адкідаецца строгім рэжымам, і асіметрычныя шляхі праз двух пастаўшчыкоў надзейна гэта выклікаюць. Лічыльнікі адкіданняў на шлюзе, а не на кліенце, скажуць, ці прычына ў фільтрацыі.

Крок 6: праверце рэсурс, а не ping

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

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