Табліца маршрутызацыі супраць фактычнага пошуку: куды ідзе трафік VPN

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

Табліца — гэта набор кандыдатаў, а не рашэнне

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

Пошук праходзіць спачатку правілы, затым табліцы

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

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

Што ўсталёўвае кліент VPN

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

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

Знешні маршрут таксама павінен выжыць

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

Што вывад маршрутызацыі не можа сказаць

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

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

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