Как да дадем на една тестова LAN собствен изход през WireGuard

Три решения решават същия лабораторен проблем: малка LAN трябва да излиза през партньор WireGuard, докато самият шлюз запазва обичайния си канал нагоре. Изкушаващият пряк път е маршрутът по подразбиране на рутера да се премести в тунела, но това чупи собствения път за управление на кутията и всичко останало, което тя препраща. Интересният вариант е маршрутизация по политика, ограничена до един интерфейс и един префикс. Изберете между тях, като отговорите на три въпроса за машината, която наистина имате.

Решете къде живее изходът

Първи въпрос: препраща ли този хост и за нещо друго? Отделен лабораторен шлюз може да живее с политика за препращане, която по подразбиране отхвърля всичко. Рутер с производствени задължения не може, а наслагването на конкурентен набор от правила върху управлявана защитна стена е точно начинът, по който се планират прекъсвания. Втори: можете ли да притежавате два обекта на политика и реда им след рестартиране? Трети: партньорът, който имате, разрешава ли адреса на източника на тунела ви и предлага ли изход към интернет? Партньор, който разкрива само частна мрежа, е друг продукт и никаква локална промяна в маршрутизацията не поправя това. Ако някой от отговорите е не, поставете изхода вместо това в именно пространство или в еднократна виртуална машина.

Именното пространство или виртуалната машина струват памет и ви дават чист радиус на щетите. Маршрутизацията по политика струва две правила и ви оставя една кутия за отстраняване на проблеми.

Изберете изхода, който разрешава вашия източник

Повечето откази в тази лаборатория се случват преди да съществува дори едно правило на защитната стена. Операторът на изхода трябва да приема адреса на източника, който пакетите ви носят след транслацията, а в това решение това е адресът на тунела, а не префиксът на LAN. Затова маскирането принадлежи на решението от самото начало, а не като късно допълнение.

Потвърдете три неща при оператора: партньорът разрешава адреса на тунела ви, той препраща IPv4, вместо да завършва при себе си, и прилага NAT на изхода. Без първото пакетите ви пристигат и изчезват. Без третото те напускат с частен източник и умират на следващата стъпка. След това проверете, че wg-quick не инсталира свой собствен маршрут по подразбиране, което предотвратява Table = off; тази настройка потиска създаването на маршрути, а не проверките на AllowedIPs при партньора или работата му с DNS.

Два обекта на политика извършват насочването

Насочването изисква таблица и правило. Таблицата държи два маршрута: префикса на LAN навън през LAN интерфейса и маршрут по подразбиране навън през тунела. Правилото изпраща трафика, който пристига на LAN интерфейса и носи този префикс, в таблицата. Използвайте селектора iif заедно със съвпадението по източник, защото собствените пакети на WireGuard на шлюза възникват локално и никога не съвпадат с входящ интерфейс.

Защитната клауза идва преди търсенето, не след него. Този ред е цялото свойство за безопасност на решението.

Защитната клауза е второ правило на същия селектор, чиято присъда е unreachable. Дайте му по-висок числов приоритет, така че търсенето да печели, докато тунелът е активен. Когато маршрутът на тунела изчезне, търсенето не връща нищо и защитната клауза спира издирването, вместо да го остави да пропадне към маршрута по подразбиране през WAN в главната таблица.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Затворете пролуката за отстъпление, преди да я отворите

Инсталирайте първо защитната клауза, а после търсенето. Обратният ред оставя прозорец от секунди, в който трафикът на тестов клиент може да достигне канала нагоре.

Филтърът допълва картината. В куката forward приемете посоката от LAN към тунела за тестовия префикс и установената обратна посока, после отхвърлете всичко останало; NAT за този префикс върху тунелния интерфейс отива в postrouting. Оставянето на policy drop на веригата за препращане е това, което превръща липсващия маршрут в тишина, а не в изтичане. Филтрирането на обратния път изисква свободен режим на тунелния интерфейс, защото публичен източник, пристигащ след декапсулация, има най-добрия си обратен маршрут от страната на WAN. Linux взема по-високата от стойностите за all и за интерфейса, така че настройването на тунелния интерфейс не е същото като отслабване на проверката навсякъде.

Докажете го с отказа

Попитайте ядрото точен въпрос, като назовете адреса на източника на клиента и интерфейса, на който пристига. Търсене без двете отговаря на друг въпрос и ще изглежда правилно и в двата случая. После погледнете броячите на защитната стена, състоянието на преноса при партньора и собствената услуга на клиента.

Тествайте премахването както трябва. Спрете тунела, като оставите правилото и филтъра на място: клиентът трябва да заседне, а собственият трафик на шлюза трябва да продължи да работи. После спрете партньора, без да пипате локалния интерфейс — това е случаят, който хваща решения, разчитащи само на наличието на маршрут. Накрая рестартирайте и проверете отново реда на правилата, защото кука за разглобяване, която маха защитната клауза, връща цялото решение на главната таблица. Запишете номера на таблицата, приоритетите и имената на интерфейсите в заявката за промяна, защото следващият човек, който добави правило, е този, който ще счупи това.