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 сегмент. Приложение, което зависи от откриване чрез broadcast, има отделно изискване за оценка. Това е пропуск в дизайна, а не грешка в маршрутизацията.

Проверка 5: въпросът за криптирането

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

Дръжте твърденията за мрежовия и приложния слой отделно в бележката за дизайна, защото смесването им е начинът, по който преглед в крайна сметка твърди защита, която никой не е внедрил.

Какво да запишете

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

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