LAN иза једне AWS Client VPN сесије: шта се прослеђује

Преносни рачунар се повезује на AWS Client VPN крајњу тачку, долази до приватне подмреже и све изгледа здраво. Радна станица на истом LAN-у не достиже ништа, иако Linux хост такође има bridge интерфејс и оба рачунара су на истом каблу. Ништа у тунелу није погрешно конфигурисано; део који недостаје је усмеравање, а bridge је лажни траг.

Проширење Client VPN сесије на LAN је улога гејтвеја. То није Ethernet сегмент развучен у управљани сервис.

Хост ради, а LAN не

Интерфејс тунела на Linux рачунару има адресу унутар Client VPN клијентског CIDR-а, а крајња тачка је послала руте за VPC опсеге. Захтев са тог рачунара је локално генерисан саобраћај: бира руту, излази кроз тунел и добија одговор. Тај пут никада не дира код за прослеђивање, LAN интерфејс ни било које правило заштитног зида које управља транзитом.

Саобраћај са другог LAN уређаја је другачији ток. Долази на LAN интерфејс, треба му рута која показује у тунел, треба укључено прослеђивање, треба заштитни зид који га дозвољава и треба да се одговор врати кроз исти хост. Четири услова, а радни тест на преносном рачунару не доказује ниједан. Са радне станице квар изгледа чудно: тунел је активан, акредитиви су важећи, а одредиште једноставно никада не одговара. Дефект је локалан за пут прослеђивања гејтвеја, не за сервис.

Није сваки клијент гејтвеј

AWS наводи да његова desktop апликација Client VPN не подржава IP прослеђивање, а да други клијенти могу. То ограничење одређује архитектуру пре него што се откуца иједна команда. Ако је једини доступни клијент званична desktop апликација, 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 не.