LAN зад една сесија на AWS Client VPN: што се препраќа
Работна сесија на домаќинот не се проширува сама на LAN. Проверете ја поддршката на клиентот, препраќањето, преводот и патеката на одговорот по тој редослед.
Лаптопот се поврзува со крајната точка на 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 рутата на портата. Тој дел обично работи кога правилото за masquerading е на место, бидејќи мапирањето живее на домаќинот што го изврши. Се крши кога на страната на VPC има рута што го испраќа одговорот на друго место, и затоа и рутата на CIDR-от на клиентот и поврзувањето на подмрежата на крајната точка се важни.
Гледајте ги бројачите, не само ping. Правило за masquerading со нула пакети ви кажува дека барањето никогаш не стигнало до интерфејсот на тунелот, што упатува назад кон LAN рутата или сопствената табела за рутирање на клиентот. Правило со пакети, но без одговори, упатува кон страната на VPC, правилата за авторизација или безбедносна група што не го прифаќа преведениот извор. Прочитајте ги двата правци пред да промените нешто, бидејќи број што расте само на една страна е еднонасочен пат, а не бавен.
Запомнете дека крајната точка е управувана услуга. Нема серверска конфигурациска датотека за уредување и нема директива client-config за додавање, па упатствата напишани за самоуправуван OpenVPN сервер со приспособени рути за клиентска подмрежа не се пренесуваат. На AWS лостовите се поврзување на подмрежа, правила за авторизација и табелите за рутирање на VPC.
Споделениот идентитет е делот на кој политиката мора да одговори
Секој уред зад портата ја користи VPN сесијата на портата. Правилата за авторизација на крајната точка даваат пристап на корисник или група, и од гледна точка на услугата на таа сесија има точно еден корисник. Локалното препраќање не го умножува тој идентитет во автентикација по уред и не ги проширува проверките на состојбата на уредот до печатачот во аголот.
Тоа може да биде прифатливо или да биде причината зошто дизајнот се отфрла. Зависи од тоа што ресурсите на VPC претпоставуваат за тоа кој се јавува. Споделен идентитет што се вклопува во моделот на авторизација е во ред; оној што тивко претвора една автентикувана сесија во пристап до целиот LAN е наод што чека да биде напишан.
Ако барањето навистина е да се поврзе цела локација со VPC, споредете поддржан дизајн локација-кон-локација пред да проширите клиент за далечински пристап. Семантиката е различна, а NAT-ирана клиентска сесија е слаба замена за врска на локација кога VPC треба да иницира врски во LAN.
Одлучете ги клиентот, рутата, преводот и приказната за идентитетот по тој редослед. Секој го ограничува следниот, а редоследот објаснува зошто домаќинот работи, а LAN не.