Пълен тунел на Access Server в EC2: защо една отметка не е достатъчна

Изключването на проверката за източник и дестинация на EC2 инстанция е най-повтаряният отговор на въпросите за интернет изхода на Access Server и само по себе си не прави нищо за вашите клиенти. Проверката е ограничение за препращане в AWS: тя позволява на инстанцията да приема пакети, чийто източник или дестинация не е собственият ѝ адрес. Тя не казва на клиента на Access Server да изпраща интернет трафик през тунела, не създава маршрут нагоре и не добавя NAT. Митът е, че отметката е функцията.

Какво всъщност контролира проверката

Всеки мрежов интерфейс в EC2 изхвърля трафика, който не е адресиран до него, освен ако инстанцията не действа като рутер, устройство за NAT или VPN шлюз и вие не изключите тази проверка. Изключването дава разрешение за препращане. Разрешението не е конфигурация: инстанцията все още се нуждае от маршрут до интернет шлюз или NAT устройство, таблицата с маршрути на VPC все още се нуждае от съответния запис, групите за сигурност все още трябва да разрешават потока, а сървърът все още трябва да транслатира или маршрутизира обратния трафик.

Проверете текущата стойност с aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, преди да промените нещо. Ако я промените в конзолата, променете я защото инстанцията препраща за други, а не защото клиент не достига до интернет.

Политиката за маршрутизиране на клиента е на Access Server

В Access Server 3 отворете Access Controls и намерете раздела Internet Access and DNS. Изборът на Internet Gateway предлага пълен или разделен тунел; пълният тунел казва на клиента да маршрутизира трафика си по подразбиране в VPN, разделеният оставя интернет трафика по локалния път на клиента. Запазете и приложете през работния поток на продукта, после свържете отново тестов клиент, защото политиката се доставя в момента на свързване.

По-старите издания използват други менюта, а някои сборки Community OpenVPN нямат еквивалентен контрол. Проверете инсталираната основна версия, преди да търсите екран, който не съществува. После потвърдете какво е получил клиентът: профил за пълен тунел трябва да инсталира маршрут по подразбиране през тунела, а профил за разделен тунел не трябва.

Проследете пакета след тунела

Щом клиентът изпрати интернет трафик в тунела, сървърът трябва да го препрати и обикновено да го транслатира. Access Server управлява собствените си правила за NAT и маршрутизиране, затова четете ефективната конфигурация, вместо да добавяте правила на Community OpenVPN към генерираните файлове; неуправляваните правила се презаписват или влизат в конфликт при следващата актуализация на продукта. sudo iptables -t nat -L -n -v или еквивалентът за nftables показва какво реално се транслатира.

Страната на AWS е отделен път. Инстанция в публична подмрежа достига до интернет шлюз директно и запазва публичния си адрес или elastic IP. Инстанция в частна подмрежа се нуждае от маршрут до NAT шлюз или NAT инстанция, а устройството за NAT се нуждае от собствен маршрут до интернет шлюза. Прикачването на интернет шлюз към VPC само по себе си не дава на частен източник публичен адрес за връщане, затова същата настройка на Access Server работи в една подмрежа и тихо се проваля в друга.

Проверете таблицата с маршрути, свързана с подмрежата на инстанцията, а не само главната таблица на VPC. Асоциациите на подмрежите имат приоритет пред главната таблица, а остарялата асоциация е честа причина работеща конфигурация да спре след преизграждане.

Дръжте IP изхода и DNS отделно

Тествайте първо литерал на адрес, после име, от същото клиентско приложение. Ако curl -4 https://checkip.amazonaws.com връща публичен адрес, но имената на хостовете се провалят, тунелът и пътят през NAT работят, а проблемът е в DNS: изпратеният резолвер, състоянието на резолвера на клиента или група за сигурност, която блокира резолвера. Настройките за DNS на Access Server са в същата област Internet Access, но пътуват по различен път в кода.

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

Не позволявайте на една отметка да затвори разследването

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

Накрая тествайте състоянието без връзка. Изборът на пълен тунел описва политиката за маршрутизиране при свързване, а не какво се случва при падане на тунела. Ако изискването е никакъв трафик да не излиза извън VPN, това е въпрос на kill-switch и защитна стена и се нуждае от собствен тест, а не от извод от таблицата с маршрути.