EC2 кроз зоне доступности: проверите рутирање пре VPN-а
Две EC2 инстанце у истом VPC-у већ деле приватно рутирање између зона. Проверите табеле подмрежа и правила приступа пре него што додате још један тунел.
Пре него што инсталирате 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 и никада не објашњава зашто приватни захтев није успео.