Як дати одній тестовій мережі 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 і для інтерфейсу, тож налаштування інтерфейсу тунелю — це не те саме, що послаблення перевірки всюди.

Доведіть це відмовою

Задайте ядру точне питання, назвавши адресу джерела клієнта й інтерфейс, на який він приходить. Пошук без обох відповідає на інше питання і в обох випадках виглядатиме правильно. Потім подивіться на лічильники фаєрвола, стан передавання в партнера та власну службу клієнта.

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