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. Ако обхватът ви за съответствие завършва при приложението, тунелът е транспорт, а сертификатът все още е контролът.

Запишете четирите отговора преди прегледа на проекта, по един ред всеки. Когато два от тях си противоречат — да речем, клиентски проект с удостоверяване на потребителя и изискване за маршрутизация с мащаб на филиал — това противоречие е констатацията и е по-евтино да го видите сега, отколкото при преминаването.