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

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