Насочване покрай VPN само на една локална уеб услуга по порт

Една услуга на хоста трябва да отговаря на интернет през физическия възходящ канал, докато всичко останало на машината продължава да използва тунела. Три условия решават дали маршрутизацията, базирана на политики, може да понесе този товар, и всяко от тях е евтино за проверка, преди да напишете правило. Услугата трябва да завършва на този хост, а не зад DNAT или пренасочен порт, собствените правила на VPN трябва да разрешават изключението и трябва да съпоставяте отговора, а не заявката. Провалите ли и едно от трите, командите по-долу се зареждат чисто, но не правят нищо полезно.

Проверете трите условия, преди да напишете правило

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

Второто условие е политика, а не механика. Всеки маршрут, който заобикаля тунела, е изключение от предназначението на тунела, а на управляван хост това решение принадлежи на този, който притежава политиката, не на човека, който отстранява проблем с изчакване.

Съпоставяйте отговора, а не порта на местоназначение на клиента

Отговор от сървър, който слуша на TCP 443, напуска хоста с порт на източника 443. Браузър на същия хост, който се свързва с отдалечен сайт по HTTPS, изпраща ефимерен порт на източника и порт на местоназначение 443. И двете са трафик на порт 443 и само едното трябва да използва таблицата на WAN, затова съпоставяне по порт на местоназначение би хванало грешната половина.

Посоката на отговора е това, което можете да различите. Съпоставете порта на източника, ограничете правилото до локално генерирани пакети и правилото покрива собствените отговори на услугата, без да засяга заявките на браузъра.

Изградете пълна таблица за връщане, преди правилото да сочи към нея

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

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Четете числата от живия хост, вместо да ги копирате. ip -4 rule show ви казва кои приоритети са заети, а добавянето на правило при вече съществуващ приоритет тихо променя реда на две правила, които поотделно изглеждат наред.

Истинската работа тук вършат два селектора. iif lo е начинът, по който ядрото отчита пакетите, генерирани от самия хост, така че правилото не може случайно да улови препратения трафик, идващ отвън. ipproto tcp sport 443 го стеснява до един транспорт и един порт, което е толкова тясно, колкото изискването позволява. Махнете селектора за протокол и правилото ще хване и UDP 443, което е друга услуга с друго поведение.

Запазете частните отговори вътре в тунела

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

ip -4 route add table 100 throw 10.90.0.0/24

Маршрутът throw прекратява търсенето в тази таблица и връща пакета на списъка с правила, така че следващата VPN политика получава шанса си. Той сам не насочва нищо в тунела и ако никое следващо правило няма съвпадащ маршрут, пакетът пак се проваля; проверете следващата политика, вместо да приемате, че throw е поправка.

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

Тествайте TCP, после QUIC, после рестарт

Отворете една връзка от оторизиран външен клиент и една от частната страна, после прегледайте търсенето на отговора с действителните адреси и портове. Ако външният отговор влиза в таблица 100, а частният не, политиката прави това, което сте поискали.

HTTP/3 се доставя през UDP и няма да бъде съпоставен от правило за TCP, така че слушателят на QUIC се нуждае от свой селектор, иначе ще продължи да използва тунела, докато HTTPS работи. Запазете правилата, на които се спрете, с компонента, който притежава интерфейса, и ги потвърдете след повторно свързване или подновяване на DHCP. Когато конкурентен мениджър премахне маршрут по време на работа след рестарт, това е проблем на собственост, който се решава в източника, а не причина да добавяте по-широки NAT правила отгоре.