Клиенти зад upstream VPN: маршрут или NAT?

Един gateway пуска WireGuard за вашите собствени устройства и клиент OpenVPN към чужда мрежа. Препращането между двата вътрешни интерфейса работи и е лесно да се заключи, че долната подмрежа вече е част от upstream услугата. Не е. Маршрутът, изтеглен от клиента, казва на gateway-а къде да изпраща заявки; той не казва нищо за това как отдалечената мрежа връща трафик към устройства, за които никога не е чувала. Изберете модел на връщане, който upstream действително поддържа, преди да добавите дори едно правило.

Решете модела на връщане, преди да пипате маршрутизацията

В това ръководство долните клиенти използват 10.90.0.0/24, зададеният на gateway-а upstream адрес на тунела е 10.80.0.6, а одобреният отдалечен ресурс е 172.20.0.30. Два модела пасват на тази форма: запазване на долния източник и накарване на далечната страна да го маршрутизира, или преобразуване на източника в собствения адрес на тунела на gateway-а. Всичко след това решение е механично, а самото решение изисква собственика на услугата. Единият ред по-горе е договор за маршрутизация с далечната страна; другият е локална промяна на политиката, която можете да направите сами. Объркването на двете е това, което превръща десетминутна промяна в преговори.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

Запазване на източника чрез маршрутизация

Далечната страна получава заявка от долен адрес, така че ѝ трябва поддържан маршрут и собственост на peer за тази подмрежа, плюс разрешение да я приеме. Това са отдалечени настройки и никой локален Linux маршрут не ги създава. Поискайте ги изрично, писмено, с префикса и тунелния peer, който ще го носи, и очаквайте отговорът да зависи от това дали услугата изобщо поддържа site-to-site уредби.

Ако отговорът е да, локалната конфигурация е малка: включено препращане, allowed-ips на WireGuard peer, покриващи долния диапазон, и firewall политика, която разрешава преминаването в двете посоки.

Умишлено преобразуване на източника

Ако услугата връща трафик само към адреса на свързания клиент, преобразувайте източника към този адрес на изхода и запазете conntrack състоянието, което го обръща за отговорите. Ограничете правилото до предвидените долни източници, предвидените отдалечени дестинации и upstream интерфейса. Правило, което преобразува всичко, излизащо от всеки интерфейс, е много по-голяма политика от това изискване и ще ви изненада по-късно.

IPv6 се нуждае от собствен дизайн; копирането на IPv4 masquerade ред не е архитектура. Тествайте преобразувания път с ново свързване, а не с кеширано.

Локалният път на данните все още трябва да работи

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

Тествайте от действително долно устройство, не от gateway-а. Адресът на източника е целият смисъл на упражнението.

Един източник означава една идентичност на сесията

Отдалечената услуга вижда удостоверената сесия на gateway-а и неговия преобразуван адрес, а не независимо удостоверяване за всяко долно устройство. Дръжте разрешенията за устройство и идентичностите на приложенията явни и потвърдете със собственика на услугата, че gateway, действащ за няколко устройства, изобщо е позволен. Преобразуването не е начин да заобиколите изискване за регистрация на всяко устройство; ако услугата изисква всяко устройство да се регистрира, използвайте този модел или преговаряйте за site-to-site уредба.

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

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

Решете какво се случва, когато upstream тунелът падне. Оторизираният отдалечен трафик не бива тихо да следва обикновен WAN резервен път там, където това е забранено, затова firewall политиката, която разрешава преминаването, трябва също да се проваля затворена. След това тествайте три случая от реално долно устройство: разрешена заявка, която работи, забранена заявка, която се проваля, и upstream повреда, която спира разрешената.

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