EC2 низ зони на достапност: проверете го рутирањето пред VPN

Пред да инсталирате VPN софтвер меѓу две EC2 инстанци, одговорете на едно прашање: дали се во истиот VPC? Ако се, приватната патека веќе постои и поставувањето во различни зони тоа не го менува. Поголемиот дел од работата во оваа ситуација е да потврдите која табела за рутирање ја користи секоја подмрежа всушност, а потоа да откриете дали дефектот воопшто бил проблем со рутирањето. Тунелот е обично погрешен одговор на ова конкретно прашање.

Проверка 1: ист VPC или различни VPC

VPC е регионален и опфаќа зони на достапност, додека секоја подмрежа припаѓа на точно една зона. Две инстанци во различни зони на еден VPC сѐ уште се во истиот домен на приватно рутирање.

Различните VPC никогаш не добиваат приватна рута само затоа што делат регион или ознака на зона. Тој случај бара поддржана врска и сопствена работа на рути и дозволи, што е одделна одлука.

Проверка 2: што велат табелите за рутирање на подмрежите

Запишете го распоредот со вистински вредности. VPC на адреса 10.60.0.0/16 со подмрежи 10.60.1.0/24 и 10.60.2.0/24 им дава на инстанците 10.60.1.10 и 10.60.2.20 пат низ локалната рута на VPC.

Потоа прегледајте ги табелите поврзани со двете подмрежи, а не само таа што прво ја најдовте. Порелевантна рута за инспекција или уред може да ја надмине основната, а целта на локалната рута самата може да биде заменета во понови конфигурации. Локална рута видлива некаде во конзолата не докажува дека двете работни оптоварувања ја користат.

Користете ги приватните адреси и имиња што VPC навистина ги доделува. Приватната адреса не мора да започнува со 10, а измислувањето од меморија е начинот на кој функционална околина се дијагностицира погрешно.

Проверка 3: рутирање или авторизација

Рутирањето само го доведува пакетот до мрежниот интерфејс на целта. Безбедносната група на целта сѐ уште мора да ги прими изворот и услугата, излезните правила на изворот мора да го дозволат барањето, а секој мрежен ACL мора да дозволи двата правци затоа што ACL не памтат состојба.

Зад тоа стојат гостинскиот огнено ѕид, врзувањето на слушателот и сопствениот идентитет на апликацијата. Секој од нив може да одбие барање што рутирањето го доставило беспрекорно.

Прифаќањето мора да биде вистинската операција на апликацијата. Успешен ping не дава пристап до апликацијата и не докажува дека името TLS и акредитивите се точни, а блокиран ping не докажува дека секоја приватна услуга е исклучена.

Проверка 4: дали навистина е потребна одделна врска

VPN може сѐ уште да припаѓа на дизајнот, но од наведена причина: поврзување на овој VPC со канцеларија, примање лаптопи или исполнување на барање за слој над. Таа причина е различна од вообичаената комуникација во истиот VPC.

Запомнете и што VPC не е. Тоа не е продолжување на домашен Ethernet сегмент. Апликацијата што зависи од откривање преку емитување има одделно барање за проценка. Тоа е празнина во дизајнот, а не грешка во рутирањето.

Проверка 5: прашањето за шифрирање

Приватната адреса и правилото за дозвола не кажуваат ништо за криптографска заштита на апликацискиот слој. Ако податоците бараат заштита од крај до крај, таа доаѓа од протоколот и моделот на идентитет што услугата навистина го поддржува.

Држете ги тврдењата за мрежниот и апликацискиот слој одделно во белешката за дизајн, зашто нивното спојување е начинот на кој прегледот на крајот тврди заштита што никој не ја спровел.

Што да се запише

Запишете ги двата идентификатори на подмрежите, табелата за рутирање поврзана со секоја, референците на безбедносните групи и операцијата на апликацијата што ја тестиравте. Тоа се четири факти и тие решаваат повеќето идни расправии за оваа патека.

Самото поставување во зона никогаш не ви кажува да додадете VPN и никогаш не објаснува зошто приватно барање не успеало.