Пір WireGuard выходзіць праз няправільны WAN: пяць праверак па парадку

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

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

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

Аддзяліце рукапоціск ад перанакіраванага патоку

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

Спыніцеся, як толькі зловіце сябе на разважанні ад рукапоціску. Ён сведчыць толькі пра шлях да канцавога пункта.

Чытайце правіла палітыкі, а не табліцу па змаўчанні

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

Праверце метку і трансляцыю разам

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

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

Сачыце, які інтэрфейс нясе адказ

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

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

Змяніце адну рэч, маючы шлях назад

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

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

Падобныя артыкулы