Адказ выходзіць праз LAN, а не праз тунель: чаму і як

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

Што насамрэч вызначае выходны пакет

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

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

Чаму перамагае лакальная падсетка

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

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

Пакрыццё піраў — не тое самае, што ўсталяваныя маршруты

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

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

Выберыце табліцу па адрасе крыніцы

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

Спачатку пацвердзіце шлях, потым сэрвіс

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

Чаго гэта не выпраўляе

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

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

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