LAN зад една сесия на AWS Client VPN: какво се препраща

Лаптопът се свързва с крайната точка на AWS Client VPN, достига до частната подмрежа и всичко изглежда здраво. Настолният компютър в същия LAN не достига до нищо, макар Linux хостът също да има мостов интерфейс и двете машини да са на един и същ кабел. В тунела нищо не е конфигурирано погрешно; липсващото парче е маршрутизацията, а мостът е подвеждаща следа.

Разширяването на сесия на Client VPN към LAN е роля на шлюз. То не е Ethernet сегмент, разтегнат в управлявана услуга.

Хостът работи, а LAN — не

Тунелният интерфейс на Linux машината има адрес в CIDR диапазона на Client VPN клиента и крайната точка е изпратила маршрути за диапазоните на VPC. Заявката, направена от тази машина, е локално генериран трафик: избира маршрут, излиза през тунела и получава отговор. Този път никога не докосва кода за препращане, LAN интерфейса или някое правило на защитна стена, което управлява транзита.

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

Не всеки клиент може да бъде шлюз

AWS посочва, че настолното приложение Client VPN не поддържа IP препращане и че други клиенти може да го поддържат. Това ограничение решава архитектурата преди да е написана каквато и да е команда. Ако единственият наличен клиент е официалното настолно приложение, Linux шлюз, препращащ за LAN, не е конфигурация, която можете да завършите, и никакво количество маскиране няма да го промени.

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

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

Насочете LAN към тунела и го транслирайте

С поддържан клиент на място останалото е обичайна работа по шлюза. LAN устройствата се нуждаят от маршрут за диапазона на VPC, сочещ към Linux хоста, а хостът се нуждае от включено препращане. Ако искате VPC да вижда трафика като свързания клиент, а не като произволен LAN адрес, транслирайте източника на изхода.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

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

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

Отговорът също се нуждае от път

След като заявката достигне VPC, отговорът трябва да се върне през същите състояния на транслация и да намери LAN маршрута на шлюза. Тази част обикновено работи, когато правилото за маскиране е на място, защото съответствието живее на хоста, който го е извършил. То се чупи, когато от страна на VPC има маршрут, който изпраща отговора другаде; затова и маршрутът за CIDR на клиента, и свързването на подмрежата в крайната точка имат значение.

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

Помнете, че крайната точка е управлявана услуга. Няма сървърен конфигурационен файл за редактиране и няма директива client-config за добавяне, така че инструкциите, написани за самостоятелно управляван OpenVPN сървър с персонализирани маршрути за клиентски подмрежи, не се пренасят. В AWS лостовете са свързване на подмрежа, правила за упълномощаване и таблиците за маршрутизация на VPC.

Споделената идентичност е частта, на която политиката трябва да отговори

Всяко устройство зад шлюза използва VPN сесията на шлюза. Правилата за упълномощаване на крайната точка дават достъп на потребител или група и от гледна точка на услугата в тази сесия има точно един потребител. Локалното препращане не умножава тази идентичност в удостоверяване за всяко устройство и не разширява проверките за състояние на устройството до принтера в ъгъла.

Това може да е приемливо или да е причината дизайнът да бъде отхвърлен. Зависи от това какво ресурсите на VPC предполагат за този, който се обажда. Споделена идентичност, която пасва на модела за упълномощаване, е добре; такава, която тихо превръща една удостоверена сесия в достъп за целия LAN, е констатация, която чака да бъде написана.

Ако изискването наистина е да свържете цял сайт към VPC, сравнете поддържан дизайн сайт-към-сайт, преди да разширявате клиент за отдалечен достъп. Семантиката е различна и NAT-ирана клиентска сесия е лош заместител на връзка между сайтове, когато VPC трябва да инициира връзки към LAN.

Решете клиента, маршрута, транслацията и историята с идентичността в този ред. Всяко ограничава следващото и редът обяснява защо хостът работи, а LAN — не.