EC2: Come assegnare più IP elastici a un'unica interface di networking tramite SDK

Qualcuno sa come associare più IP Elastici a un'unica istanza tramite l'SDK Amazon? In Ruby, ho cercato di utilizzare entrambe le gemme aws-sdk e nebbia, che funzionano bene per un singolo indirizzo, ma erronea cercando di assegnare più.

Con l'UI Web, questo verrà fatto aggiungendo ips privati ​​aggiuntivi e quindi assegnando il IP pubblico all'interface di networking + privato ip tuttavia non sono i parametri ip privati ​​in SDK.

One Solution collect form web for “EC2: Come assegnare più IP elastici a un'unica interface di networking tramite SDK”

IP funzionanti in modo elastico

Per impostazione predefinita, l'istanza in VPC riceverà un IP solo da una substring privata all'interno del VPC, di solito in qualche parte nella substring 10.0.0.0/8. Ciò significa che mentre quelle istanze possono accedere a altre istanze all'interno di quella stessa substring, non potranno connettersi a Internet più ampio.

Un modo per dare a each macchina l'accesso è quello di impostare una macchina NAT che tutte le macchine utilizzano per indirizzare il traffico. Non andremo più a fondo in questa opzione.

L'alternativa è quella di dare a each macchina il suo indirizzo IP elastico diretto a livello mondiale. Amazon avvia il traffico verso l'ip elastico al tuo IP interno. Ciò rende questo setup più semplice da una prospettiva di topologia di networking.

Il routing nel VPC funziona attraverso le tabelle di routing che vengono configurate per ciascuna substring. È ansible visualizzare la tabella di routing nella scheda VPC della console AWS. Per impostazione predefinita, le richieste all'interno della tua substring vengono instradate localmente e le richieste al di fuori di tale intervallo sono instradate tramite un 'gateway internet'.

Ad esempio, diciamo che hai un'istanza con IP 10.0.0.1. Ha un IP elastico associato ad esso, diciamo 1.2.3.4. Ora, each volta che accede ad altre macchine interne sulla substring 10.0.0.0/8, la tua richiesta verrà originata dal tuo IP privato e nulla accadrà al traffico.

Quando si accede a una macchina al di fuori della subnet, i pacchetti vengono instradati tramite il gateway Internet, un dispositivo VPC con un nome come igw-9d7534f2. Il gateway (che non è un'istanza reale EC2, solo un sistema AWS opaco) accetta la richiesta e quindi cerca l'IP interno da cui origina la richiesta e verifica se questo IP è associato a qualsiasi IP elastico. Se è così, la richiesta viene riscritta per apparire come se l'origine fosse l'IP elastico e quindi inviato via Internet. Quando un pacchetto torna al gateway con un IP elastico come destinazione, il gateway controlla se l'IP elastico è associato ad un IP interno e se così riscrive il pacchetto a quel IP. Il pacchetto viene quindi inoltrato nella substring privata.

Ecco come funziona il NAT one-to-one di IP elastici. Il vantaggio di questo approccio è che le macchine all'interno della subnet non devono avere alcuna conoscenza dei loro IP elastici. Ciò rende più facile passare l'IP elastico di un'istanza in esecuzione, dato che l'unica cosa che deve essere aggiornata è la tabella di mapping sul gateway internet. L'IP esterno può cambiare molte volte; poiché i pacchetti vengono riscritti per utilizzare IP interni prima di arrivare all'istanza, l'istanza non lo saprà mai.

Interfacce di networking multiple

In passato, Amazon ha aggiunto un'opzione per aggiungere più interfacce di networking a un'istanza VPC. Queste interfacce appaiono come tabs ethernet separate sulla vostra macchina e avranno un IP interno separato. Interfaccia separata significa anche che è necessario impostare correttamente l'interface tra queste interfacce: se si invia un pacchetto sull'interface sbagliata, il pacchetto verrà semplicemente eliminato.

Queste interfacce di networking sono state introdotte per consentire la connessione di diverse sottoreti: è ansible disporre di un'interface in ciascuna substring e quindi eseguire il traffico tra di loro come si desidera. Poiché each substring ha una propria gamma IP, è facile percorrere il traffico verso l'interface di networking corretta.

Per each IP interno è ansible associare un IP Elastico esterno. Mentre questo è ansible, si arriva in un po 'di una situazione di routing difficile. Entrambi i IP interni (su eth0 e eth1) hanno un IP esterno associato e dovrebbero essere in grado di fare richieste per internet più ampio, avendo il gateway internet tradurre il proprio IP interno all'IP elastico. Tuttavia, per farlo correttamente, le richieste devono essere inviate nell'interface corretta. Amazon ammette che questo non è semplice:

Per impostazione predefinita, Linux dispone di una tabella di routing che indirizza tutto il traffico al di fuori della substring locale a un'unica interface. Puoi guardare questo con il path:

# 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 

Qui, tutto il traffico in tutto il mondo esce dall'interface eth0. Anche i pacchetti con una sorgente ip dell'interface eth1 usciranno oltre eth0 e poi saranno scartati in silenzio invece di essere NAT al IP destro elastico. Mentre è ansible eseguire l'instradamento basato su sorgenti per risolvere questo problema, questo non è banale da configurare (è necessario eseguire dhclient dopo aver aggiunto un'altra interface a una macchina):

 # 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.xxx # 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.xxx # curl --interface 10.0.0.76 ifconfig.me 116.xxx 

Più indirizzi IP

In questo modo possiamo evitare alcuni dei nasties di routing dall'alto: tutti i pacchetti saranno inviati su eth0, a prescindere da quale IP avete. A causa della mapping one-to-one di indirizzi pubblici e privati, è necessario aggiungere nuovi indirizzi privati ​​a una delle tue istanze.

L'API di Amazon è stata aggiornata per supportre l'assegnazione di IP privati ​​secondari, ma per questo esempio è più facile andare alla console AWS. Nella scheda EC2, passare a Istanze. Individuare l'istanza che si desidera aggiornare, fare clic con il button destro del mouse e scegliere "Gestisci indirizzi IP privati".

immettere qui la descrizione dell'immagine

immettere qui la descrizione dell'immagine

Vedrai ora che l'istanza dispone di due IP privati ​​nella tua substring (dato che un'interface è bloccata a una substring specifica, tutti gli IP di tale interface devono rientrare in quella stessa substring). Bello! Tuttavia, se controlla ora l'istanza:

 # 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 

Non avrà ancora il nuovo IP. Proviamo a recuperarlo tramite 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 

No, abbiamo solo il nostro ip privato privato! Con DHCP è ansible get un solo indirizzo. In futuro, forse Amazon aggiunge il supporto per più IP utilizzando un identificatore client o un altro meccanismo, ma per ora dovrai aggiungere l'indirizzo manualmente. Speriamo che il cloud-init di Ubuntu aggiungerà un supporto in futuro, quindi non dobbiamo farlo da soli.

Amazon suggerisce la creazione di una nuova interface virtuale e poi l'avvicinamento. Mentre functionrà, significa che memorizzi il tuo stato dell'interface sul disco rigido e tutte le modifiche apportte a AWS dovrai diffondere a questi file.

Per il test, possiamo fare qualcosa di più semplice:

 MAC_ADDR=$(ifconfig eth0 | sed -n 's/.*HWaddr \([a-f0-9:]*\).*/\1/p') IP=($(curl http://169.xxx/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 

Questo verifica i meta-dati dell'istanza EC2 per tutti gli IP interni associati a eth0 e aggiunge tutti i IP secondari.

Ora è ansible associare un altro IP elastico all'IP secondario nella console AWS:

immettere qui la descrizione dell'immagine

E adesso hai più IP esterni!

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

Mentre questo funziona per il test, non è persistente durante il riavvio. È ansible creare uno script upstart o cloud-init per farlo per te. Anche allora, gli indirizzi IP non vengono aggiunti automaticamente quando li aggiungete tramite EC2. Non sono sicuro se c'è un buon modo per farlo. Infine, anche questo script non rimuove gli indirizzi locali che puoi eliminare nel frattempo.

Spero che questo ti aiuterà.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.