AWS Client VPN ці Site-to-Site: праверце, хто ўстанаўлівае злучэнне

Гэта вырашаюць чатыры праверкі, і ні адна з іх не з'яўляецца назвай пратакола. Хто адкрывае злучэнне, што аўтэнтыфікуе AWS, як злучэнне далучаецца да вашай сеткі і якія маршрутызацыя і палітыка ідуць з ім. Адкажыце на гэта па парадку, і выбар прадукту звычайна робіць сябе сам; адкажыце пасля таго, як ужо набылі праект, і вы будзеце абараняць тунель, які вырашае не тую палову праблемы. Ні адна з чатырох не просіць вас выбраць шыфр, і менавіта таму праект, які пачынаецца з пратакола, звычайна сведчыць пра тое, што патрабаванні ніколі не былі запісаны.

Праводзьце кожную праверку супраць фактычнай канцавой кропкі, кліента і сямейства адрасоў, якія вы плануеце выкарыстоўваць, а не супраць катэгорыі. Кіраваныя VPN-прадукты адрозніваюцца ад будаўнічых блокаў OpenVPN і IPsec, на якія яны падобныя.

Перш за ўсё, хто адкрывае злучэнне

Калі тое, што патрабуе доступу, — гэта ноўтбук, тэлефон або працоўная станцыя аднаго адміністратара, злучэнне пачынаецца з аддаленай прылады, і праект — гэта аддалены кліенцкі доступ. Калі тое, што патрабуе доступу, — гэта філіял, поўны машын за адным маршрутызатарам, злучэнне пачынаецца з гэтага маршрутызатара, і праект — гэта шлюз-да-шлюза. Гэта праверка вырашае большасць выпадкаў, і менавіта яе людзі прапускаюць, калі прэзентацыя пастаўшчыка ўжо пабудавала размову вакол шыфраў.

Спыніцеся тут, калі вы не можаце назваць кампанент, які ініцыюе. Праект, які спрабуе абслугоўваць абодва выпадкі адным тунелем, звычайна заканчваецца кліенцкай сесіяй, якая выдае сябе за шлюз.

Па-другое, што аўтэнтыфікуе AWS

З Client VPN AWS аўтэнтыфікуе наладжаны кліенцкі або карыстальніцкі ідэнтыфікатар: сертыфікаты, каталог або федэратыўны ідэнтыфікатар, у залежнасці ад налады. З Site-to-Site VPN AWS аўтэнтыфікуе ідэнтыфікатар шлюзавага партнёра. Гэта розніца не касметычная. Адна мадэль масштабуецца даданнем карыстальнікаў і адкліканнем іх уліковых даных; іншая масштабуецца даверам да ўсяго, што стаіць за адным шлюзам.

Аўтэнтыфікацыя шлюза не аўтэнтыфікуе кожнага супрацоўніка або праграму за ім, таму захоўвайце ідэнтыфікатары праграм і доступ на ўзроўні рэсурсаў на месцы, нават калі сам тунель лічыцца давераным. Філіял, чый маршрутызатар мае сапраўдны ідэнтыфікатар партнёра, не павінен аўтаматычна чытацца як дазвол для кожнага стала ў гэтым будынку.

Па-трэцяе, як далучаецца злучэнне

Client VPN далучаецца праз асацыяцыі падсетак VPC або падтрыманае прамое далучэнне Transit Gateway. Site-to-Site VPN далучаецца да мэты AWS VPN, звычайна да віртуальнага прыватнага шлюза або Transit Gateway. Кіраўніцтва па архітэктуры Client VPN дакументуе варыянт Transit Gateway, і яго наяўнасць не ператварае сесію ноўтбука ў філіяльны шлюз і не выдаляе аўтэнтыфікацыю і аўтарызацыю кліента, апісаныя вышэй.

Праверце далучэнне, якое ваш уліковы запіс і рэгіён фактычна падтрымліваюць, перш чым праектаваць маршруты вакол яго, затым праверце, хто валодае гэтым далучэннем. Варыянт, які існуе ў дакументацыі, але знаходзіцца ў сетцы, якую вы не можаце наладзіць, не з'яўляецца варыянтам.

Па-чацвёртае, якія маршрутызацыя і палітыка ідуць з ім

Client VPN прыносіць кіраванне кліенцкімі злучэннямі і правілы аўтарызацыі для сетак прызначэння, якія вы дазваляеце. Падключаны карыстальнік усё яшчэ патрабуе патрэбнага маршруту да канцавой кропкі, правіла аўтарызацыі, якое яго дазваляе, і таго доступу, які патрабуе сам рэсурс. Site-to-Site VPN маршрутызуе паміж сеткамі, прадстаўленымі кліенцкім шлюзам, выкарыстоўваючы падтрыманыя статычныя маршруты або BGP у залежнасці ад праекта, таму асобныя машыны за філіяльным маршрутызатарам не патрабуюць кожная кліенцкага ўваходу.

Не выводзьце непадтрыманыя паводзіны з катэгорыі ні ў адзін бок. VPN аддаленага доступу не з'яўляюцца ўніверсальна нездольнымі перавозіць зваротны трафік або падтрымліваць шлюзавыя схемы, і IPsec не блакуецца NAT аўтаматычна — AWS дакументуе праходжанне NAT і патрабаванні да кліенцкага шлюза, і рэальнае абмежаванне — гэта падтрыманая канфігурацыя шлюза. Праверце абмежаванні для вашай канцавой кропкі, перш чым патрабаваць злучэнняў, ініцыяваных у бок кліентаў, або перадаваць LAN за адной сесіяй. Тая ж асцярожнасць датычыцца сямействаў адрасоў: канцавая кропка, якая працуе праз IPv4, не азначае шлях IPv6, таму пацвердзіце сямейства, якое ваш кліент або шлюз фактычна будуць узгадняць.

Site-to-Site VPN дае вам два тунелі на злучэнне, і гэтая рэзервовасць — задача праектавання, а не функцыя, якую можна меркаваць. Праца кліенцкага шлюза, пераключэнне маршрутаў і пакрыццё тэстамі — усё гэта трэба планаваць; параўнанне адной сесіі ноўтбука з абстрактным VPN-серверам нічога не даказвае ні пра адно з іх.

Дзе сустракаюцца два праекты

Паслугі не выключаюць адна адну, і звычайная вытворчая форма выкарыстоўвае абедзве: супрацоўнікі на Client VPN, філіяльныя сеткі на Site-to-Site, з яўнымі маршрутамі і палітыкай доступу паміж пунктамі прызначэння, якія павінныя размаўляць. Табліца — гэта зводка чатырох праверак, а не іх замена.

Адно, чаго не замяняе ні адзін прадукт: TLS да праграмы, патрабаванне шыфравання якой выходзіць за межы канцавой кропкі VPN. Калі вашая сфера адпаведнасці заканчваецца на праграме, тунель — гэта транспарт, а сертыфікат па-ранейшаму з'яўляецца сродкам кантролю.

Запішыце чатыры адказы да агляду праекта, па адным радку кожны. Калі два з іх супярэчаць — скажам, кліенцкі праект з аўтэнтыфікацыяй карыстальніка і патрабаванне маршрутызацыі філіяльнага маштабу — гэтая супярэчнасць і ёсць выснова, і ўбачыць яе цяпер танней, чым падчас пераходу.