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 і ніколі не тлумачыць, чаму прыватны запыт не ўдаўся.