AWS Insight: Virtual Private Cloud

    Привет, хабрасообщество! image

    Сегодня я, наконец, набрался смелости и имею время рассказать вам о замечательном сервисе, который предоставляет Amazon Web Services: Virtual Private Cloud — VPC.

    VPC — это сервис, позволяющий создавать приватные изолированные сети в публичном облаке Amazon. Что же предоставляет VPC?
    • Подсети серых адресов
    • Полный контроль над адресами
    • Динамическое и удобное управление сетевыми устройствами и маршрутизацией
    • Поддерживает EC2, RDS, SQS, ElastiCache и другие сервисы
    • Многое другое..

    У VPC есть много внутренних понятий и терминов, давайте я буду их описывать по мере настройки. И сегодня я вместе с вами настрою кроссзонную сеть для VPC для большей отказоустойчивости.

    VPC


    Итак, в консоли перейдём в VPC и создадим новое приватное облако:
    image

    Для примера я выбрал шестнадцатую подсеть 10.50.0.0, которая включает в себя 256*256 = 65536 адресов. Кстати, мы можем выбрать параметр Tenancy:
    • по умолчанию
    • отдельно

    По умолчанию это как обычно — ваши инстансы поднимаются где-попало. А вот отдельная «квартирка» даёт возможность запускать инстансы близко, но за отдельную плату.

    Subnetworks


    Создали облако, теперь нужно создать подсети. Наше облако привязано к региону и может иметь множество подсетей (куда ж распихать 65к адресов-то?), а сами подсети уже привязаны к регионам.

    Так же подсети бывают:
    • приватные — не имеют прямого доступа в Интернет, только через публичные сети и NAT
    • публичные — могут иметь доступ в Интернет через Elastic IP и Internet Gateway

    Итак, давайте создадим в одной зоне 2 подсети: приватную и публичную, а в другом только приватную, чтоб получилось так:
    image

    Приватной и публичной подсеть станет впоследствии, посему создём 3 простых подсети:
    image

    И в последствии имеем то, что хотели:
    image

    Internet Gateway


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

    Интернет Шлюз представляет из себя виртуальный девайс, который пускает в интернет хосты, у которых есть Elastic IP (EIP). Давайте создадим шлюз и прицепим его к нашему облаку, чтоб было так:
    image

    Собственно, создаём шлюз:
    image

    Цепляем шлюз к облаку:
    image

    Route Tables


    Как же теперь направить нашу публичную сеть на только что созданный шлюз? Для этого существуют маршруты.

    Маршруты — это виртуальные маршруты, которые распространяются на одну или несколько подсетей, и дающие информацию, как должен распределяться трафик. Со стороны хостов, это никак не отображается. У них простой основной маршрут на первый (например 10.50.1.1) хост в подсети. VPC сама разруливает через Маршруты, куда пойдёт трафик.

    По умолчанию при создании подсети создётся таблица маршрутизации, оставим её для приватных сетей и создадим новую:
    image

    Выделив новую таблицу, внизу страницы мы можем увидеть её составляющие. Давайте создадим роут на Интернет 0.0.0.0/24, который будет идти через наш Интернет Шлюз:
    image

    Ну и ассоциируем нашу публичную подсеть с этой таблицей:
    image

    Итак, давайте поднимем в нашей публичной подсети EC2 инстанс и дадим ему EIP, а приватный адрес поставим 10.50.3.254 (мы же можем их контролировать!!!), чтоб было так:
    image

    Начнём с создания инстанса в EC2. Собственно говоря, нужно поставить галку VPC и выбрать нужную подсеть:
    image

    Пока запускается инстанс, получим EIP для VPC.Там же где и обычно, только выбираем не EC2:
    image

    Network Interfaces


    При создании нового инстанса в VPC автоматически создаётся сетевой интерфейс.

    Сетевой интерфейс — это виртуальное устройства, с помощью которого можно управлять физическими интерфейсами инстанса. Управление сетевыми интерфесами проводится из консоли EC2.

    Итак, посмотрим, что же у нас там появилось:
    image

    Теперь попробуем приассайнить интерфейсу новый приватный адрес:


    Теперь у интерфейса виртуально есть 2 адреса. Ну и давайте приассайним к интерфейсу EIP:
    image

    Вот и всё, наш инстанс доступен снаружи:
    $ telnet 107.23.210.139 22
    Trying 107.23.210.139...
    Connected to 107.23.210.139.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_5.3
    


    NAT Instance


    Как говорилось ранее, приватные подсети должны иметь доступ в интернет только через NAT. Так давайте наш новый инстанс сделаем таковым. Так же, я ставлю обычно OpenVP на этот инстанс, чтоб иметь доступ в VPC.

    1. Разрешим форвардинг в /etc/sysctl.conf:
    net.ipv4.ip_forward = 1
    

    2. Разрешим форвардинг в iptables:
    iptables -t filter -A FORWARD -s 10.50.0.0/16 -j ACCEPT 
    iptables -t filter -A FORWARD -d 10.50.0.0/16 -j ACCEPT 
    iptables -t nat -A POSTROUTING -s 10.50.0.0/16 -o eth0 -j MASQUERADE
    


    Далее установим и настроим OpenVPN server. Итак, предположим, что мы всё сделали и можем законнектиться в сеть.

    Private Networks


    Как же приватные подсети смогут понять как им идти в интернет. Да легко! Всё те же маршруты. Возьмём оставшуюся таблицу и сделаем в ней изменения: выберем шлюзом наш NAT инстанс для Интернета 0.0.0.0/0:
    image

    Ну и проассоциируем эту таблицу с двумя оставшимися подсетями:
    image

    Закоючение


    Вот и всё, теперь мы можем создавать инстансы в наших приватных подсетях, которые будут доступны только через OpenVPN. Напрямую к ним доступ можно открыть через Elastic Load Balancer, который выставлен наружу. Подсеть в последствии может принять вот такой вот простенький, но интересный вид:
    image

    В VPC есть ещё много нюансов, например VPN до вашего датацентра, который ментейнит сам AWS и ещё куча мелких деталей, но в общем вывод очевиден. С помощью VPC вы можете создать отказоустойчивое приватное облако на базе AWS.

    Вопросы?
    EPAM
    Компания для карьерного и профессионального роста

    Comments 14

      0
      Какое практическое применение этой технологии?
        0
        Мы используем VPC для построения приватных облаков над публичным AWS.
          0
          Для передачи данных между узлами системы общая задача которой работать с пользователями через интернет?
          Например чтобы нельзя было подключиться к базе данных, так?
            +1
            Да не важно в принципе. В EC2 мы не имеем доступа к настройкам приватных адресов и они доступны всем желающим. Здесь же — мы всё рулим сами. БД — то же самое. Не просто невозможно, а вообще никак.
              +1
              и они доступны всем желающим
              


              Что вы имели ввиду?
                0
                Имеется в виду, что приватные адреса EC2 доступны всему региону. Да, Security Groups, но всё же…
                  0
                  Разве, что успокоить собственную параною:) Но в целом, из другой Security Group мои приватные адреса разве, что видны, но на них все закрыто, что я пожелал. Просто в VPC по умолчанию не нужно об этом думать.
        0
        [deleted]
          0
          Прочел немаловажную особенность. В VPC возможно прикреплять несколько приватных и EIP к одному инстансу. Вот думаю, что лучше будет: делать отдельные ELB для SSL, или вытаскивать фронтенды в VPС…
            0
            На самом деле эта проблема легко разруливается через ELB. Но да, сетевые интерфейсы так могут.
              0
              Не так что бы и легко. Во первых смена IP на балансере, во вторых, аварии с EBS могут доставить вам счастья с ELB. А летом параллельно не работал API, соотвественно можно оказаться в ловушке, что ELB не работает, а новый не поднять, т.к API не отвечает и т.д. Такие не контролируемые процессы меня и пугают в ELB для критических сервисов.
                0
                Тут вы несомненно правы. Но… Волков бояться — в лес не ходить :-)
            0
            На всякий случай дополню — у NAT Instance надо убрать source/destination check, иначе nat не заработает.
              0
              А NAT можно из своего AMI сделать? Он может еще какую то работу делать? Например на него свой лоад балансер поставить?

              Only users with full accounts can post comments. Log in, please.