EC2: Как присвоить несколько эластичный дюйм/с единственному сетевому интерфейсу через SDK

Кто-либо знал бы, как связать несколько Эластичный дюйм/с к единственному экземпляру через SDK Amazon? В Ruby я попытался использовать обоих aws-sdk и драгоценные камни вуали, которые хорошо работают для единственного адреса, но ошибки, пытаясь присвоить нескольким.

Через сеть UI это было бы сделано путем добавления дополнительного частного дюйм/с и затем присвоения общедоступного IP сетевому интерфейсу + частный IP однако, я не частные IP параметры в SDK.

3
задан 27 June 2014 в 05:34
1 ответ

Упругие IP-адреса, работающие

По умолчанию, экземпляр в VPC получит IP-адрес только из частной подсети внутри VPC, обычно где-то в 10.0.0.0/8 подсети. Это означает, что в то время как эти экземпляры могут получить доступ к другим экземплярам в той же подсети, они не смогут подключиться к более широкому Интернету.

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

Альтернатива заключается в том, чтобы дать каждому компьютеру свой собственный эластичный IP-адрес, маршрутизируемый по всему миру. Amazon будет направлять трафик на эластичный ip на ваш внутренний IP. Это упрощает эту настройку с точки зрения топологии сети.

Маршрутизация в VPC работает через таблицы маршрутизации, которые настраиваются для каждой подсети. Вы можете просмотреть таблицу маршрутизации на закладке VPC консоли AWS. По умолчанию запросы внутри вашей подсети маршрутизируются локально, а запросы вне этого диапазона маршрутизируются через "интернет-шлюз".

Например, допустим, у вас есть экземпляр с IP 10.0.0.1. Он имеет эластичный IP, связанный с ним, скажем, 1.2.3.4. Теперь всякий раз, когда вы получаете доступ к другим внутренним машинам в подсети 10.0.0.0/8, ваш запрос будет исходить с вашего личного IP и с трафиком ничего не случится.

Когда вы получаете доступ к машине вне вашей подсети, пакеты направляются через интернет-шлюз, VPC устройство с именем типа igw-9d7534f2. Шлюз (который не является реальным экземпляром EC2, а просто непрозрачной AWS системой) принимает запрос, а затем просматривает внутренний IP, с которого исходит запрос, и проверяет, связан ли этот IP с какими-нибудь эластичными IP. Если да, то запрос переписывается, чтобы выглядеть так, как если бы источником был эластичный IP, а затем посылается через Интернет. Когда пакет возвращается к шлюзу с эластичным IP в качестве адресата, шлюз проверяет, связан ли этот эластичный IP с внутренним IP, и если да, то перезаписывает пакет на этот IP. Затем пакет пересылается в частную подсеть.

Вот как работает NAT "один-к-одному" эластичного IP. Преимущество такого подхода заключается в том, что машины внутри подсети не должны иметь никаких знаний о своих эластичных IP-адресах. Это облегчает переключение эластичных IP-адресов бегущей инстанции, так как единственное, что нужно обновить, это картографическая таблица на интернет-шлюзе. Внешний IP-адрес может меняться много раз; так как пакеты переписываются для использования внутренних IP-адресов до того, как они поступают к экземпляру, экземпляр никогда об этом не узнает.

Multiple Network Interfaces

В прошлом компания Amazon добавляла возможность добавления нескольких сетевых интерфейсов к экземпляру VPC. Эти интерфейсы появляются на вашей машине как отдельные ethernet-карты, и будут иметь отдельный внутренний IP. Раздельные интерфейсы также означают, что вы должны правильно настроить вашу маршрутизацию между этими интерфейсами: если вы отправите пакет через неправильный интерфейс, пакет будет просто сброшен.

Эти сетевые интерфейсы были введены, чтобы дать вам возможность соединить различные подсети вместе: вы можете иметь по одному интерфейсу в каждой подсети, а затем маршрутизировать между ними, как вам нравится. Так как каждая подсеть имеет свой собственный диапазон IP-адресов, трафик легко маршрутизировать на нужный сетевой интерфейс.

Для каждого внутреннего IP-адреса можно связать внешний эластичный IP-адрес. Хотя это и возможно, но сейчас вы попадаете в сложную ситуацию с маршрутизацией. Оба внутренних IP-адреса (на eth0 и eth1) имеют ассоциированный внешний IP-адрес и должны иметь возможность делать запросы в более широкий интернет, заставив интернет-шлюз перевести свой внутренний IP-адрес на Elastic IP. Однако, для того, чтобы сделать это правильно, запросы должны быть отправлены через правильный интерфейс. Сама компания Amazon признает, что это не так просто:

По умолчанию в Linux есть таблица маршрутизации, которая направляет весь трафик вне вашей локальной подсети в единый интерфейс. Вы можете посмотреть это с помощью маршрута:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
default         10.0.0.1        0.0.0.0         UG    100    0        0 eth0
10.0.0.0        *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.255.255.0   U     0      0        0 eth1

Здесь весь интернет трафик будет выходить через интерфейс eth0. Даже пакеты с исходным ip интерфейсом eth1 будут выходить через eth0, а затем будут бесшумно отбрасываться вместо того, чтобы быть NAT'ом на правильный эластичный IP. Хотя можно сделать маршрутизацию на основе исходников, чтобы исправить это, это не тривиально (обратите внимание, что вам нужно запустить dhclient после добавления другого интерфейса к машине):

# ifconfig | grep eth\\\|inet\ 
eth0      Link encap:Ethernet  HWaddr 02:86:10:77:7f:fe  
          inet addr:10.0.0.76  Bcast:10.0.0.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 02:86:10:65:fd:31  
          inet addr:10.0.0.226  Bcast:10.0.0.255  Mask:255.255.255.0

# curl --interface 10.0.0.76 ifconfig.me
116.x.x.x
# curl --interface 10.0.0.226 ifconfig.me
<< TIMEOUT >>>

# ip rule add from 10.0.0.226 table out2
# ip route add default via 10.0.0.1 dev eth1 table 2
# ip route flush cache

# curl --interface 10.0.0.226 ifconfig.me
116.x.x.x
# curl --interface 10.0.0.76 ifconfig.me
116.x.x.x

Multiple IP Addresses

Таким образом мы можем избежать некоторых неприятностей с маршрутизацией сверху: все пакеты будут отправляться по eth0, независимо от того, какой IP у вас есть. Из-за сопоставления публичных и приватных адресов один к одному, вам сначала нужно добавить несколько новых приватных адресов к одному из ваших экземпляров.

API Amazon был обновлен для поддержки назначения вторичных приватных IP, но для этого примера проще простого перейти в AWS Console. Во вкладке EC2 перейдите в Instances. Найдите экземпляр, который вы хотите обновить, щелкните правой кнопкой мыши и выберите "Manage Private IP Adresses"

enter image description here

enter image description here

Теперь вы увидите, что этот экземпляр имеет два частных IP-адреса в вашей подсети (поскольку интерфейс заблокирован на определенную подсеть, все IP-адреса на этом интерфейсе должны находиться в одной подсети). Здорово! Однако, если вы теперь проверите ваш экземпляр:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 02:86:10:7b:e4:f5  
          inet addr:10.0.0.34  Bcast:10.0.0.255  Mask:255.255.255.0

Он еще не будет иметь нового IP. Давайте попробуем получить его через DHCP!

root@ip-10-0-0-34:/# dhclient -d eth0
Listening on LPF/eth0/02:86:10:7b:e4:f5
Sending on   LPF/eth0/02:86:10:7b:e4:f5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPREQUEST of 10.0.0.34 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 10.0.0.34 from 10.0.0.1
DHCPACK of 10.0.0.34 from 10.0.0.1

Нет, мы получаем только наш первичный частный ip! С помощью DHCP вы можете получить только один адрес. В будущем, возможно, Amazon добавит поддержку нескольких IP-адресов, используя какой-нибудь идентификатор клиента или другой механизм, но пока вам придётся добавлять адрес вручную. Надеюсь, что в будущем облачный модуль Ubuntu добавит поддержку для этого, так что нам не придется делать это самим.

Amazon предлагает создать новый виртуальный интерфейс, а затем поднять эту тему. Хотя это сработает, это означает, что вы сохраняете состояние интерфейса на жёстком диске, и любые изменения, которые вы вносите в AWS, вам придётся распространять на эти файлы.

Для тестирования мы можем сделать кое-что попроще:

MAC_ADDR=$(ifconfig eth0 | sed -n 's/.*HWaddr \([a-f0-9:]*\).*/\1/p')
IP=($(curl http://169.x.x.x/latest/meta-data/network/interfaces/macs/$MAC_ADDR/local-ipv4s))
for ip in ${IP[@]:1}; do
    echo "Adding IP: $ip"
    ip addr add dev eth0 $ip/24
done

Это позволит проверить мета-данные экземпляра EC2 на все внутренние IP-адреса, связанные с eth0, и добавить все вторичные IP-адреса.

Теперь вы можете подключить другой эластичный ip к вторичному IP в консоли AWS:

enter image description here

И теперь у вас есть несколько внешних IP!

root@ip-10-0-0-34:/# curl --interface 10.0.0.58 ifconfig.me
116.x.x.x
root@ip-10-0-0-34:/# curl --interface 10.0.0.34 ifconfig.me
116.x.x.x

Пока это работает для тестирования, это не является постоянным при перезагрузке. Вы можете создать скрипт upstart или cloud-init, чтобы сделать это за вас. Даже в этом случае ip-адреса не добавляются автоматически при добавлении через EC2. Я не уверен, что есть хороший способ сделать это. Наконец, этот скрипт также не будет удалять локальные адреса, которые вы, возможно, удалили за это время.

Надеюсь, это поможет вам.

.
4
ответ дан 3 December 2019 в 06:07

Теги

Похожие вопросы