☰

AWS NIC-Konfiguration

tag-icon • tag-icon linux ubuntu networking amazon-web-services amazon-ec2
AWS NIC-Konfiguration

Ich versuche, eine EC2-Instanz für einen bestimmten Anwendungsfall einzurichten. Dazu benötige ich 2 ENI mit öffentlich zugänglichen IP-Adressen. (Beide sollten pingbar sein)

Ich habe bisher folgende Schritte durchgeführt:

  • Angeschlossene 2 Netzwerkschnittstellen aus demselben Subnetz
  • Instanz ausführen
  • Es wurden 2 elastische IP-Adressen erstellt, die mit jeder ENI-Karte der Instanz verknüpft sind.

Ich kann das folgende Ergebnis im Abschnitt „Netzwerkschnittstellen der EC2-Instanz“ sehen.

Öffentlich

Aber ich konnte keinen Ping senden 3.104.193.180.

Also meins ip addressergibt folgendes Ergebnis...

ubuntu@ip-172-31-37-139:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:ce:dd:28:5b:b8 brd ff:ff:ff:ff:ff:ff
    inet 172.31.37.139/20 brd 172.31.47.255 scope global dynamic eth0
       valid_lft 3460sec preferred_lft 3460sec
    inet6 fe80::4ce:ddff:fe28:5bb8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:a6:9a:4a:98:c6 brd ff:ff:ff:ff:ff:ff
    inet 172.31.41.29/20 brd 172.31.47.255 scope global dynamic eth1
       valid_lft 3460sec preferred_lft 3460sec
    inet6 fe80::4a6:9aff:fe4a:98c6/64 scope link
       valid_lft forever preferred_lft forever

Meine Fragen sind also ...

  • Was muss ich tun, um eine andere IP verfügbar/pingbar zu machen?
  • Wie erfahre ich vom Server aus meine beiden elastischen IPs?

Antwort1

Um die öffentliche IP-Adresse zu erhalten, die einer bestimmten Schnittstelle zugeordnet ist, müssen Sie zunächst die MAC-Adresse von der Schnittstelle abrufen und dann die gewünschten Informationen vom Instance Metadata Service (IMDS) abrufen. In Ihrem obigen Beispiel hat eth1 also die MAC-Adresse 06:a6:9a:4a:98:c6, sodass Sie die öffentliche IPv4-Adresse folgendermaßen erhalten können:

curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:1d:90:af:65:a3/public-ipv4s

Weitere Informationen finden Sie unterdie AWS-Dokumentation

Überprüfen Sie in Bezug auf Ihr Verbindungsproblem als ersten Schritt die VPC-Routing-, ACL- und Sicherheitsgruppenkonfiguration, die mit jedem Ihrer ENIs verknüpft ist. Diese Details können leicht falsch konfiguriert werden und können zu Datenverkehrsabbrüchen führen, wenn Sie etwas übersehen. Überprüfen Sie zuerst diese Details und kommen Sie dann zurück und lesen Sie den Rest dieses Beitrags. Es gibt ein weiteres, subtileres Problem, das insbesondere dann auftritt, wenn Sie mehrere ENIs mit einer Instanz verknüpft haben, und das könnte Ihr Problem sein.

AWS VPC implementiert strenge Anti-Spoofing-Schutzmaßnahmen. Das ist eine gute Sache, denn es schützt AWS und seine Kunden vor der Teilnahme an verschiedenen Formen von Netzwerkangriffen, falls eine Instanz aus irgendeinem Grund kompromittiert wird. Dies müssen Sie jedoch berücksichtigen, wenn Sie mehrere ENIs an Instanzen anhängen.

Das Problem besteht darin, dass das grundlegende Routingverhalten nur durch dieZieleines ausgehenden Pakets. Dies bedeutet, dass die Antwort auf ein eingehendes Paket möglicherweise nicht über dieselbe Schnittstelle übertragen wird, über die das ursprüngliche Paket empfangen wurde. Für eine VPC gilt dies jedoch als „gefälschtes“ Paket, da die Quelladresse im Antwortpaket keiner der mit der ENI verknüpften privaten IP-Adressen entspricht.

Beachten Sie die folgende Schnittstellenkonfiguration und Routingtabelle:

admin@ip-10-0-0-115:~$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default 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 state UP group default 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
default via 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

In diesem Fall ist 10.0.0.8 eine Adresse, die ens6 zugewiesen ist. Ein eingehendes Paket an diese IP-Adresse wird über ens6 empfangen und wie erwartet verarbeitet. Eine ausgehende Antwort auf dieses Paket wird jedoch gemäß der obigen Routing-Tabelle weitergeleitet, tritt über ens5 aus und wird vom VPC gelöscht.

Du kannst das folgendermaßen testen:

admin@ip-10-0-0-115:~$ ip ro get 8.8.8.8 from 10.0.0.8
8.8.8.8 from 10.0.0.8 via 10.0.0.1 dev ens5 uid 1000
    cache

Beachten Sie, dass das Gerät ens5 ist, obwohl 10.0.0.8 ens6 zugewiesen ist! Die VPC würde diesen Datenverkehr löschen!

Um sicherzustellen, dass Ihre Pakete vom VPC zugestellt werden, müssen Sie Folgendes implementieren:Richtlinienrouting. Allgemein gesagt bezieht sich Policy Routing auf die Situation, in der Ihr System neben dem Ziel noch weitere Informationen verwendet, um Routing-Entscheidungen zu treffen. In diesem Fall müssen Sie auch die Quell-IP-Adresse berücksichtigen. Was wir hier tun müssen, ist sicherzustellen, dass jedes ausgehende Paket mit der Quelladresse 10.0.0.8 über ens6 abgeht.

Das Richtlinienrouting in Linux wird normalerweise mit dem ip(8)Befehl konfiguriert. Damit die Instanz mit der obigen Routingtabelle funktioniert, müssen Sie eine sekundäre Routingtabelle speziell für ens6 erstellen. Die Manipulation sekundärer Tabellen funktioniert genauso wie die Manipulation der „Haupttabelle“, außer dass Sie eine Tabellen-ID angeben. In diesem Fall können wir also eine Route zum lokalen Netzwerk und eine Standardroute über das Gateway zur Tabelle 10000 wie folgt hinzufügen:

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 show table 10000
default via 10.0.0.1 dev ens6
10.0.0.0/24 dev ens6 scope link

Und erstellen Sie eine Regel zum Weiterleiten des ausgehenden Datenverkehrs von 10.0.0.8 gemäß dieser Tabelle:

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:~$ ip rule
0:      from all lookup local
10000:  from 10.0.0.8 lookup 10000
32766:  from all lookup main
32767:  from all lookup default

Beachten Sie das Vorhandensein von Regel 10000, die zeigt, dass der Datenverkehr von 10.0.0.8 über Tabelle 10000 geleitet wird.

Wir können dies noch einmal bestätigen mit ip ro get:

admin@ip-10-0-0-115:~$ ip ro get 8.8.8.8 from 10.0.0.8
8.8.8.8 from 10.0.0.8 via 10.0.0.1 dev ens6 table 10000 uid 1000
    cache

Beachten Sie, dass die Weiterleitung gemäß Tabelle 10000 erfolgt, aber noch wichtiger, dass die Übermittlung über das Gerät ens6 erfolgt!

Amazon Linux richtet solche Routing-Richtlinien automatisch ein, wenn Sie mehrere ENIs an Ihre Instanz angehängt haben. Ich weiß nicht, ob Ubuntu das tut, also müssen Sie diesbezüglich vielleicht ein wenig recherchieren und möglicherweise Ihre eigene Automatisierung für Ihre spezielle Situation implementieren.

verwandte Informationen