AWS Client VPN или VPN върху EC2: работен наръчник

И двата варианта дават на екипа VPN за отдалечен достъп, затова интересният въпрос не е кой съществува, а кой можете да експлоатирате. Разликата е кой притежава крайната точка в 3 часа през нощта и до какви средства за контрол имате достъп, когато нещо се счупи. Изпълнете петте стъпки по-долу по ред, защото всяка може да прекрати сравнението рано. Именно пропускането на стъпката с инвентара води до това екипите да мигрират два пъти.

Стъпка 1: напишете изискването преди сметката

Трябват ви пет факта на една страница: кой се автентикира и срещу какво, кои клиентски платформи трябва да работят, кои частни дестинации са достъпни, каква наличност сте обещали и как всъщност изглежда трафикът. Без тях всяко следващо сравнение се превръща в спор за списък с функции.

Бъдете конкретни за дестинациите. «Достъп до VPC» обикновено означава три различни неща: CIDR на VPC, свързана мрежа и локален диапазон зад Transit Gateway. Управляваната крайна точка може да достигне и трите, но всяко от тях се нуждае от маршрут и правило за оторизация, и всяко е отделен ред в изискването ви.

Стъпка 2: избројте какво вече работи

Преди да проектирате каквото и да е, избројте съществуващите крайни точки и всеки сървър, хостван на EC2, заедно с групите му за сигурност. Тези извиквания са само за четене и са безопасни за изпълнение от акаунт с права describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Четете изхода като карта на това до какво клиентите вече имат достъп. Липсващо правило за оторизация обяснява отказ, който изглежда като проблем с маршрутизацията, а крайна точка, свързана с една подмрежа, обяснява защо отказ на зона свали цялата услуга.

Запишете и групите за сигурност, прикачени към всеки самостоятелно хостван инстанс. Тези правила са част от модела за достъп и са първото, което тихо се чупи, когато някой пресъздаде инстанс от шаблон.

Стъпка 3: разделете отговорностите

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

Самостоятелното хостване обръща това. Вие притежавате гостевата операционна система, демона на VPN и конфигурацията му, сертификатите и ключовете, резервните копия, мониторинга и възстановяването. Моделът за сигурност на EC2 възлага сигурността на госта и приложението на клиента, а VPN сървърът е гост като всеки друг.

Запишете разделението като таблица с имена в дясната колона. Ако до подновяването на сертификати не застане ничие име, това е констатацията и тя е по-важна от разликата в цената за час.

Стъпка 4: сравнявайте спрямо натоварване, което можете да опишете

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

Сравненията на производителността изискват същата дисциплина. Една интерактивна сесия на работен плот, един голям трансфер и петдесет едновременни малки заявки натоварват различни части от пътя: процесора за криптиране, мрежовите възможности на инстанса, собствения стек на клиента и дестинацията. Тествайте с представителни клиенти и същата задача при двата дизайна.

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

Стъпка 5: преминете с връщане назад, което вече сте изпълнявали

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

Проверявайте в този ред: автентикацията минава, клиентът получава очакваните маршрути, оторизирана дестинация отговаря, неоторизирана дестинация се проваля, а журналите показват и двете събития. Ако някоя стъпка се провали, спрете и поправете тази стъпка, вместо да минавате към следващата група клиенти. Записвайте резултата от всяка проверка, защото преминаване, запомнено само като «проработи», не може да се отстрани месец по-късно.

След преминаването планирайте скучните проверки: срок на сертификатите, брой свързвания, правила за оторизация, които вече не отговарят на група, и броя връзки спрямо очакванията ви. Ръководството за администриране на Client VPN е справката за частите за крайна точка, автентикация и маршрутизация, които сте конфигурирали.