Перанакіраванні ICMP супраць вашых маршрутаў VPN: што насамрэч змяняецца

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

Перанакіраванне — гэта прапанова ад маршрутызатара

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

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

Менавіта на гэтым адрозненні большасць расследаванняў перанакіраванняў ідзе не туды.

IPv4 і IPv6 дастаўляюць яго па-рознаму

У IPv6 аналагічны механізм знаходзіцца ўсярэдзіне выяўлення суседзяў, а не ў ICMPv4, з іншымі фарматамі паведамленняў і іншымі правіламі праверкі. Паняткі сугучныя, а пакеты — не. Фільтр запісу, напісаны для тыпу ICMP 5, нічога не пакажа ў сетцы IPv6, і гэта часам чытаецца як доказ таго, што перанакіравання не было.

Палітычныя ручкі таксама асобныя, таму хост можа прымаць перанакіраванні IPv4 і ігнараваць IPv6, або наадварот.

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

Прыняцце — гэта палітыка хоста, а не факт сеткі

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

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

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

Што перанакіраванне не можа тлумачыць

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

Састарэлыя запісы — іншая пастка, бо кліент, які змяніў сетку, мае іншы лакальны шлюз.

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

Праверце маршрут, перш чым вінаваціць тунель

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

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

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