Поўны тунэль 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 і файрвола, і яно патрабуе ўласнай праверкі, а не вываду з табліцы маршрутаў.