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, — це не та конфігурація, яку можна завершити, і жодна кількість masquerading цього не змінить.

Замінний клієнт також має відповідати методу автентифікації кінцевої точки та політиці, яку ви збираєтеся застосовувати. Кінцеві точки на основі сертифікатів, каталогу та 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 на шлюзі. Ця частина зазвичай працює, коли правило masquerade на місці, бо зіставлення живе на хості, який його виконав. Воно ламається, коли на боці VPC є маршрут, що надсилає відповідь в інше місце, і саме тому важливі і маршрут CIDR клієнта, і прив'язка підмережі на кінцевій точці.

Дивіться на лічильники, а не лише на ping. Правило masquerade з нулем пакетів каже вам, що запит так і не дійшов до інтерфейсу тунелю, що вказує назад на маршрут LAN або на власну таблицю маршрутизації клієнта. Правило з пакетами, але без відповідей указує на бік VPC, правила авторизації або групу безпеки, яка не приймає трансльоване джерело. Читайте обидва напрямки, перш ніж щось змінювати, бо число, що зростає лише з одного боку, — це односторонній шлях, а не повільний.

Пам'ятайте, що кінцева точка — керований сервіс. Немає файлу конфігурації сервера для редагування і немає директиви client-config для додавання, тому інструкції, написані для самостійно керованого сервера OpenVPN з власними маршрутами клієнтських підмереж, не переносяться. У AWS важелі — це прив'язка підмережі, правила авторизації та таблиці маршрутизації VPC.

Спільна ідентичність — це частина, на яку має відповісти політика

Кожен пристрій за шлюзом використовує VPN-сесію шлюзу. Правила авторизації кінцевої точки дають доступ користувачу або групі, і з погляду сервісу в цій сесії рівно один користувач. Локальне пересилання не множить цю ідентичність в автентифікацію для кожного пристрою і не поширює перевірки стану пристроїв на принтер у кутку.

Це може бути прийнятно, а може бути причиною, чому проєкт відхиляють. Це залежить від того, що ресурси VPC припускають про того, хто телефонує. Спільна ідентичність, що вписується в модель авторизації, — це нормально; та, що тихо перетворює одну автентифіковану сесію на доступ до всього LAN, — знахідка, що чекає на запис.

Якщо вимога справді в тому, щоб підключити цілий майданчик до VPC, порівняйте підтримуваний проєкт «майданчик-майданчик», перш ніж розширювати клієнт віддаленого доступу. Семантика відрізняється, і сесія клієнта з NAT — погана заміна каналу майданчика, коли VPC має ініціювати з'єднання в LAN.

Вирішіть клієнт, маршрут, трансляцію та історію ідентичності саме в такому порядку. Кожен обмежує наступний, і порядок пояснює, чому хост працює, а LAN — ні.