LAN клиентите пренебрегват VPN на рутера, докато не се включи маршрутизация по правила

Рутерът достига интернет през своя тунел, докато лаптоп зад него все още показва адреса на доставчика. Добавянето на правила за приемане не помага и този неуспех е показателен: филтрирането отговаря дали пакетът може да премине, а не накъде отива. Изборът на интерфейс вече е направен от търсене на маршрут, което не знае нищо за списъка ви с клиенти. Поправете търсенето и защитната стена вече не е заподозряна.

Правило за филтриране не може да избере интерфейс

Потокът на пакети на Linux рутер първо изпълнява решението за маршрут и след това куката forward. Когато правило съвпадне с изходящото тунелно устройство, ядрото вече е решило, че тунелът е изходът. Ако главната таблица все още предпочита маршрута по подразбиране през WAN, пакетът е на път към доставчика и правилото за приемане, което току-що написахте, никога не го вижда. Този един факт за подредбата обяснява защо цяла страница нови правила за защитна стена не променя нищо.

Примерът по-долу използва LAN 192.168.8.0/24 на br-lan, тунелно устройство tun0 и един set-top box на 192.168.8.23, който трябва да минава през тунела.

Прочетете търсенето, преди да редактирате правила

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

Прикачете таблица към клиентите, които искате да покриете

Маршрутизацията по политики вмъква търсене по правила преди главната таблица. Създайте таблица, чийто маршрут по подразбиране е тунелът, после свържете тази таблица със селектор: входен интерфейс, адрес на източник или маркер на защитната стена. Приоритетите определят реда, а главната таблица стои много надолу в списъка, на 32766, затова правило с малък номер се преглежда първо. Селекторите по интерфейс покриват всеки клиент на моста; селекторите по адрес покриват една машина.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Интерфейсите на фърмуера обикновено показват същите обекти като страница за маршрутизация по политики или политика на VPN. Списъкът с устройства там е по-лесен за поддръжка от ръчно написани правила и обикновено оцелява при актуализации, които променят синтаксиса на правилата.

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

Дръжте локалните дестинации извън тунела

Новата таблица познава само маршрутите, които поставите в нея. Префиксът на LAN липсва, така че трафикът към принтера и NAS би последвал тунелния маршрут по подразбиране и би изчезнал. Маршрут throw прекратява търсенето в тази таблица и връща решението на главната таблица.

ip -4 route add throw 192.168.8.0/24 table 200

Пропуснете този маршрут и локалните споделени ресурси се чупят, а собствената управляваща сесия на рутера може да изчезне, ако селекторът е по-широк от предвиденото. После решете въпроса с източника: тунелните пакети, които все още носят LAN адреси, се нуждаят от обратен път, известен на другата страна, докато маскирането на тунела премахва това изискване и също премахва идентичността на клиента, която другата страна би видяла.

Правилата и маршрутите, добавени по време на работа, изчезват след рестарт или актуализация на фърмуера. Добавете ги към механизма за стартиране на рутера, рестартирайте веднъж и тествайте отново от клиента: неговия публичен адрес, втори клиент, който трябва да остане на WAN, и броячите на тунела при ново свързване.