Pentru a obține adresa IP publică asociată cu o anumită interfață, mai întâi, obțineți adresa MAC de la interfață, apoi preluați informațiile pe care le căutați din Serviciul de metadate ale instanțelor (IMDS). Deci, în exemplul dvs. de mai sus, eth1 are
Adresa mac 06:a6:9a:4a:98:c6, astfel încât să puteți obține adresa IPv4 publică cu:
curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:1d:90:af:65:a3/public-ipv4s
Există mai multe informații în documentația AWS
În ceea ce privește problema dvs. de conectivitate, ca prim pas, verificați din nou rutarea VPC, ACL și configurația grupului de securitate asociate cu fiecare dintre ENI-urile dvs. Aceste detalii sunt ușor de configurat greșit și pot duce la scăderea traficului dacă pierdeți ceva. Verifică mai întâi acele detalii, apoi revino și citește restul acestei postări. Există o altă problemă mai subtilă care apare în mod special atunci când aveți mai multe ENI asociate cu o instanță și ar putea fi problema dvs.
AWS VPC implementează protecții stricte anti-spoofing. Acesta este un lucru bun, deoarece protejează AWS și clienții săi împotriva participării la diferite forme de atac de rețea în cazul în care o instanță este compromisă dintr-un anumit motiv. Cu toate acestea, este ceva de care trebuie să țineți cont atunci când atașați mai multe ENI la instanțe.
Problema este că comportamentul de bază de rutare este determinat doar de destinaţie a unui pachet de ieșire. Aceasta înseamnă că răspunsul la un pachet de intrare poate să nu fie transmis prin aceeași interfață pe care a fost primit pachetul original. Dar pentru un VPC, acesta este considerat un pachet „falsificat”, deoarece adresa sursă din pachetul de răspuns nu se potrivește cu niciuna dintre adresele IP private asociate cu ENI.
Luați în considerare următorul tabel de configurare a interfeței și de rutare:
admin@ip-10-0-0-115:~$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq stare UP grup implicit qlen 1000
altname enp0s5
inet 10.0.0.115/24 brd 10.0.0.255 scope global dynamic ens5
valid_lft 2801sec preferred_lft 2801sec
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq stare UP grup implicit qlen 1000
altname enp0s6
inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic ens6
valid_lft 2889sec preferred_lft 2889sec
admin@ip-10-0-0-115:~$ ip ro
implicit prin 10.0.0.1 dev ens5
10.0.0.0/24 dev ens5 proto kernel scope link src 10.0.0.115
10.0.0.0/24 dev ens6 proto kernel scope link src 10.0.0.8
În acest caz, 10.0.0.8 este o adresă atribuită ens6. Un pachet de intrare la această adresă IP va fi primit prin ens6 și procesat conform așteptărilor. Dar un răspuns de ieșire la acel pachet va fi direcționat conform tabelului de rutare de mai sus și va ieși prin ens5 și va fi abandonat de VPC.
Puteți testa asta astfel:
admin@ip-10-0-0-115:~$ ip pentru a obține 8.8.8.8 de la 10.0.0.8
8.8.8.8 de la 10.0.0.8 prin 10.0.0.1 dev ens5 uid 1000
cache
Rețineți că dispozitivul este ens5, chiar dacă 10.0.0.8 este atribuit ens6! VPC-ul ar reduce acest trafic!
Pentru a vă asigura că pachetele dvs. sunt livrate de VPC, trebuie să implementați rutarea politicii. În linii mari, politica de rutare se referă la situația în care sistemul dumneavoastră utilizează informații suplimentare dincolo de destinație pentru a lua decizii de rutare. În acest caz, trebuie să luați în considerare și adresa IP sursă. Ceea ce trebuie să facem aici este să ne asigurăm că orice pachet de ieșire cu o adresă sursă de 10.0.0.8 pleacă prin ens6.
Rutarea politicii în Linux este de obicei configurată folosind ip(8) comanda. Pentru a face ca instanța cu tabelul de rutare de mai sus să funcționeze, veți dori să creați un tabel de rutare secundar specific pentru ens6. Manipularea tabelelor secundare funcționează la fel ca manipularea tabelului „principal”, cu excepția faptului că specificați un ID de tabel.Deci, în acest caz, putem adăuga o rută la rețeaua locală și o rută implicită prin gateway la tabelul 10000, astfel:
admin@ip-10-0-0-115:~$ sudo ip ro add 10.0.0.0/24 dev ens6 table 10000
admin@ip-10-0-0-115:~$ sudo ip ro add default via 10.0.0.1 table 10000
admin@ip-10-0-0-115:~$ ip ro arată tabelul 10000
implicit prin 10.0.0.1 dev ens6
10.0.0.0/24 dev ens6 scope link
Și creați o regulă pentru a direcționa traficul de ieșire din 10.0.0.8 conform acestui tabel:
admin@ip-10-0-0-115:~$ sudo ip rule add from 10.0.0.8/32 table 10000 pref 10000
admin@ip-10-0-0-115:~$ regulă ip
0: din toate căutările locale
10000: de la 10.0.0.8 căutare 10000
32766: din toate căutările principale
32767: din toate căutările implicite
Observați prezența regulii 10000 care arată că traficul de la 10.0.0.8 va fi direcționat prin tabelul 10000.
Putem confirma acest lucru cu ip ro get din nou:
admin@ip-10-0-0-115:~$ ip pentru a obține 8.8.8.8 de la 10.0.0.8
8.8.8.8 de la 10.0.0.8 prin 10.0.0.1 dev ens6 table 10000 uid 1000
cache
Observați că este direcționat conform tabelului 10000, dar, mai important, că va fi trimis prin dispozitivul ens6!
Amazon Linux setează regulile de rutare a politicii în mod automat atunci când aveți mai multe ENI atașate instanței dvs. Nu știu dacă Ubuntu o face, așa că s-ar putea să fie nevoie să faci puțină cercetare în acest sens și, eventual, să implementezi propria ta automatizare pentru situația ta particulară.
