Thank you for reading this post, don't forget to subscribe!

nat

Не име­ет зна­че­ния, сколь­ко у вас сер­ве­ров и каких - без сети они всё рав­но бес­по­лез­ны. В этом заня­тии мы научим­ся созда­вать вир­ту­аль­ные част­ные обла­ка и  раз­во­ра­чи­вать сете­вую инфра­струк­ту­ру для мно­го­слой­но­го проекта.

Для нача­ла перей­дём в AWS VPC - Virtual Private Cloud

Выбе­рем вклад­ку Your VPCs и нач­нём созда­ние нового:

В настрой­ках под­се­ти, в первую оче­редь, выбе­рем назва­ние и блок айпи адре­сов. Здесь я исполь­зо­вал диа­па­зон 10.42.0.0/16, для упро­ще­ния зада­чи пред­ла­гаю вам исполь­зо­вать его же. Для это­го упраж­не­ния IPv6 нам не пона­до­бят­ся, не вклю­ча­ем. В тэги не забудь­те доба­вить назва­ние про­ек­та - я исполь­зую AppDemo, а вы може­те выбрать своё.

Гото­во

Для удоб­ства рабо­ты с ресур­са­ми выбе­ри­те новую сеть в окне Filter by VPC сле­ва сверху.

Сеть есть, будем про­дол­жать! Перей­дём в под­се­ти (subnets) и созда­дим новые:

Для нача­ла, при­вя­жем их к нашей новой VPC

Затем зада­дим сле­ду­ю­щие пара­мет­ры: назва­ние (вида ПРОЕКТ AZ1 Public), зону доступ­но­сти (а), тэги и блок айпи адре­сов. Для упро­ще­ния демон­стра­ции я исполь­зо­вал диа­па­зон /24, если вы точ­но пони­ма­е­те, что дела­е­те, то може­те взять более под­хо­дя­щий к реаль­ной ситу­а­ции диа­па­зон на ваше усмот­ре­ние (напри­мер /20). Таким обра­зом, для пер­вой под­се­ти я исполь­зую адре­са 10.42.0.0/24.

Сра­зу же создам и вто­рую под­сеть для этой зоны, на этот раз уже при­ват­ную. Она будет выгля­деть точ­но так же, кро­ме име­ни (Private) и диа­па­зо­на -10.42.1.0/24

так же созда­дим ещё две под­се­ти - они будут крайне похо­жи на пер­вые две, но будут исполь­зо­вать вто­рую зону доступ­но­сти реги­о­на (b) и дру­гие диа­па­зо­ны адре­сов: 10.42.2.0/24 и 10.42.3.0/24.

Под­се­ти у нас есть, даже инстан­сы в них мож­но создать, но тол­ку от это­го пока немно­го - без досту­па в интер­нет ниче­го не зара­бо­та­ет. Для это­го нам пона­до­бит­ся internet gateway, давай­те созда­дим такой. Перей­дём в Internet Gateways и запу­стим создание:

Слож­ной зада­чей это не назо­вёшь - по сути, мы толь­ко имя да тэги можем задать.

Теперь надо при­со­еди­нить его к наше­му VPC:

Выбе­ри­те наш VPC и про­дол­жим - Attach Internet Gateway

Теперь настро­им авто­ма­ти­че­скую выда­чу пуб­лич­ных айпи-адре­сов тем сер­ве­рам, кото­рые будут запу­ще­ны в пуб­лич­ной под­се­ти. Выбе­рем первую пуб­лич­ную под­сеть в спис­ке подсетей

И, в спис­ке дей­ствий, выбе­рем Modify auto-assign IP settings. 

Вклю­чим гал­ку Enable auto-assign и сохра­ним изменения.

Так же вклю­чим эту настрой­ку для вто­рой пуб­лич­ной подсети.

Теперь настро­им таб­ли­цы марш­ру­ти­за­ции - без соот­вет­ству­ю­щих марш­ру­тов наш интер­нет-шлюз всё рав­но оста­нет­ся недо­сту­пен, а зачем мы его тогда созда­ва­ли? Перей­дём в Route Tables и созда­дим новую таблицу.

Эта таб­ли­ца пред­на­зна­че­на для пуб­лич­ных под­се­тей наше­го обла­ка. Так её и назо­вём: AppDemo Public RT. Обя­за­тель­но выбе­ри­те нуж­ный VPC (не дефолт­ный, а новый)

Теперь под­ре­дак­ти­ру­ем маршруты:

Добавь­те новый: Он дол­жен идти ПОСЛЕ локаль­но­го и захва­ты­вать все адре­са назна­че­ния (0.0.0.0/0). Точ­кой назна­че­ния выбе­ри­те наш новый интер­нет-шлюз. Затем сохра­ни­те маршруты.

Срав­ни­те вашу новую таб­ли­цу марш­ру­тов с при­ве­дён­ной на кар­тин­ке отли­чать­ся дол­жен толь­ко айди шлюза.

Таб­ли­ца гото­ва, но ей, увы, никто не поль­зу­ет­ся. Доба­вим её под­се­тям, кото­рым нужен доступ к интер­нет-шлю­зу (то есть пуб­лич­ным). При назна­че­нии таб­ли­цы, она “вытес­нит” дефолт­ную, заме­стив её.

Выбе­ри­те в этом окне обе пуб­лич­ные (но не при­ват­ные) сети и сохра­ни­те изменения.

Ну что, пуб­лич­ные сети гото­вы! Давай­те доба­вим пару сер­ве­ров: перей­ди­те в служ­бу EC2.

Преж­де чем добав­лять сер­ве­ра, при­дёт­ся доба­вить груп­пы без­опас­но­сти - это упро­стит нам рабо­ту с серверами.

Создай­те груп­пу для веб-сер­ве­ров доступ­ных снаружи:

Их пра­ви­ла пре­дель­но про­сты: HTTP отку­да угод­но. Для упро­ще­ния зада­чи доба­вим так­же SSH и ICMP, при­го­дят­ся. Разу­ме­ет­ся, в реаль­ной жиз­ни SSH доступ дол­жен быть огра­ни­чен, но пока оста­вим так.

Затем доба­вим груп­пу для сер­ве­ров бэкен­да, рас­по­ло­жен­ных в при­ват­ной подсети.

Здесь офор­мим пра­ви­ла по дру­го­му - весь тра­фик, но толь­ко из пер­вой груп­пы без­опас­но­сти (в теку­щем при­мер - AppDemo Web). Исхо­дя­щий тра­фик в обо­их слу­ча­ях раз­ре­шим куда угодно.

Создай­те kep pair, фор­ма­та - pem, если его ещё нет. Исполь­зуй­те его при созда­нии инстансов.

Теперь мож­но и сер­ве­ра доба­вить, всё готово.

Выбе­рем  Amazon Linux 2

и T2.Micro

Поме­ня­ем настрой­ки: во-пер­вых, выбе­рем пра­виль­ную сеть и под­сеть (AZ1 Public)

Во-вто­рых, доба­вим user data:

Ну и груп­пу без­опас­но­сти, конечно.

Про тэги тоже не забываем!

И key pair нуж­ный, кото­рый созда­ва­ли мы.

Пока этот инстанс созда­ёт­ся, запу­стим следующий:

Выде­лив пер­вый, нажми­те на Actions - Image and templates - launch more like this

Созда­дим ещё один сер­вер со схо­жи­ми настрой­ка­ми, но раз­ме­сти­те его в дру­гой пуб­лич­ной под­се­ти (что­бы эти два веб-сер­ве­ра были раз­ме­ще­ны в раз­ных зонах доступ­но­сти). Имя тоже при­дёт­ся поме­нять, а вот осталь­ное будет при­мер­но таким же.

Открой­те в бра­у­зе­ре пуб­лич­ные айпи-адре­са этих сер­ве­ров - они оба долж­ны вас при­вет­ство­вать радост­ным “Hello!” - когда запу­стят­ся, конечно

Что­бы завер­шить эту часть рабо­ты, убе­ди­тесь, что вы може­те под­клю­чить­ся к ним по SSH. 

 

 

NAT Gateway

ниче­го не будет рабо­тать если сер­ве­ра из при­ват­ной под­се­ти не смо­гут под­клю­чит­ся к интер­не­ту - ведь и им быва­ет нуж­но обнов­ле­ние ска­чать. Для того, что­бы помочь им это сде­лать, мы доба­вим два NAT Gateway - по одно­му в каж­дую пуб­лич­ную под­сеть. В прин­ци­пе, хва­ти­ло бы и одно­го, но тогда при раз­ры­ве сете­во­го соеди­не­ния меж­ду зона­ми доступ­но­сти вто­рая зона (без NAT) оста­лась бы без интернета.

Итак, нач­нём: перей­дём в VPC, NAT Gateways и при­сту­пим к созданию.

Назна­чим имя, под­сеть (AZ1 Public) и запро­сим Elastic IP - без него NAT шлюз не заработает.

Под­клю­че­ние NAT шлю­за зай­мёт время

под­ни­мем ещё один NAT шлюз в дру­гой пуб­лич­ной сети

Как и в слу­чае с обыч­ны­ми интер­нет-шлю­за­ми, поль­зо­вать­ся сер­ве­ра ими не смо­гут, пока мы не рас­ска­жем, как их най­ти, а зна­чит - при­шло вре­мя таб­лиц марш­ру­ти­за­ции, да не одной, как в про­шлый раз, а сра­зу двух - по одной на част­ную подсеть.

Созда­дим первую из них:

Назо­вём AppDemo Private AZ1 RT и при­вя­жем к VPC

Отре­дак­ти­ру­ем таб­ли­цу маршрутизации

И доба­вим новый марш­рут: идея точ­но такая же, весь тра­фик (0.0.0.0/0), кото­рый не попа­да­ет в local, дол­жен идти в NAT Gateway этой под­се­ти (имен­но этой, не соседней)

Сохра­ни­ли изме­не­ния? Тогда давай­те при­вя­жем эту таб­ли­цу к соот­вет­ству­ю­щей при­ват­ной подсети

Выбе­ри­те при­ват­ную сеть соот­вет­ству­ю­щей зоны доступности:

Для завер­ше­ния настрой­ки нам при­дёт­ся повто­рить эти дей­ствия, создав вто­рую при­ват­ную таб­ли­цу марш­ру­ти­за­ции, доба­вив новый марш­рут и под­клю­чив её к остав­шей­ся под­се­ти. Обра­ти­те вни­ма­ние - и NAT-шлюз, и под­сеть долж­ны быть из вто­рой зоны доступности.

В кон­це убе­ди­тесь, что ваш спи­сок ваших таб­лиц марш­ру­тов выгля­дит при­мер­но так же:

• Пуб­лич­ная RT при­вя­за­на к обе­им пуб­лич­ным подсетям
• При­ват­ная RT AZ1 при­вя­за­на к при­ват­ной под­се­ти AZ1
• При­ват­ная RT AZ2 при­вя­за­на к при­ват­ной под­се­ти AZ2

Теперь всё гото­во и мож­но запу­стить уже и бэкенд-сервера:

Важ­но: запу­сти­те его в нуж­ной под­се­ти (Private AZ1)

Задай­те нуж­ные тэги:

Секью­ри­ти группы:

И key pair нуж­ный, кото­рый созда­ва­ли мы.

И под­клю­чи­те секью­ри­ти груп­пу бэкен­да.

создай­те сер­вер для вто­рой при­ват­ной сети, исполь­зуя те же настрой­ки (кро­ме самой под­се­ти и назва­ния, они долж­ны быть AZ2 Private)

Для про­вер­ки настро­ек, давай­те выпол­ним два действия:

Зало­ги­нив­шись на пуб­лич­ный сер­вер (как в про­шлой части), выпол­ни­те ping исполь­зуя при­ват­ные адре­са сер­ве­ров бэкенда.

Если всё про­шло бла­го­по­луч­но и сете­вое соеди­не­ние есть, вто­рым шагом завер­ша­ем про­вер­ку и запра­ши­ва­ем HTTP соеди­не­ние на эти сер­ве­ра посред­ством curl

Ответ вида “Hello from ip-10-42-…” одно­знач­но гово­рит нам что всё ок