AWS EC2 und Cloud-VPCs

Eine private VPC erreichen - ohne Bastion, ohne VPN-Gateway, ohne öffentliche Adresse - und den Austausch der Instanz überstehen.

Was Sie erreichen werden

Ihr Team erreicht Datenbanken und Dienste in einer privaten VPC vom Notebook aus, ohne dass irgendetwas aus dem Internet erreichbar ist.

Kein Bastion-Host, der gepatcht werden muss, keine öffentliche Adresse und keine eingehende Regel für die Routing-Instanz. Am Ende öffnet ein Notebook in engineering eine RDS-Datenbank über ihren Namen, auch nachdem die Routing-Instanz ersetzt wurde.

Wann Sie das brauchen

Nutzen Sie diese Anleitung, wenn das, was Sie brauchen, in einem Cloud-Netzwerk liegt:

Eine RDS-Datenbank, die Entwickler mit einem Desktop-Client öffnen.
Private Dienste ohne öffentlichen Endpunkt, heute über eine Bastion erreicht.
Ein internes Dashboard auf einer Instanz ohne öffentliche Adresse.
Eine VPC, die heute über ein stundenweise bezahltes Client-VPN erreicht wird.

Was Sie brauchen

Die als Erforderlich markierten Zeilen genügen, um eine Datenbank zu erreichen.

	Was	Wozu
Erforderlich	Die Rolle Owner oder Admin im Dashboard	Die Schritte 1 und 2 setzen sie voraus
Erforderlich	Die AWS CLI (AWS CloudShell bringt sie mit). AWS-Rechte, um ein Secret, eine IAM-Rolle, eine Security Group, ein Launch Template und eine Auto Scaling Group anzulegen. Dazu die Rechte, die Rolle an EC2 zu übergeben (`iam:PassRole`), einen neuen Wert im Secret abzulegen (`secretsmanager:PutSecretValue`), die Security Group der Datenbank zu ändern, eine Instanz zu beenden und eine Session-Manager-Sitzung zu starten	Schritte 3 bis 6, dann Prüfen und Fehlersuche
Erforderlich	Private Subnetze, deren Routingtabelle ausgehenden Verkehr an ein NAT-Gateway schickt	Der Agent baut nur ausgehende Verbindungen auf. Eingehend braucht er nichts
Erforderlich	Endpunkt und Port der Datenbank, etwa ein RDS-Writer-Endpunkt auf 5432	Er wird zur Ressource
Erforderlich	Ein Notebook mit der SXAccess-App oder dem CLI-Agenten, angemeldet	Zum Testen. Siehe Welchen Client brauche ich?
Optional	SSM Parameter Store statt Secrets Manager	Funktioniert genauso; ändern Sie den Befehl, der den Schlüssel liest, und die Berechtigungen der Rolle
Fortgeschritten	Private Subnetze in einer zweiten Availability Zone	Redundanz

Bevor Sie beginnen

Eine Instanz spricht für die VPC.

Der Agent auf der Instanz baut nur ausgehende Verbindungen auf, und der Tunnel entsteht von innen. Die Instanz braucht deshalb weder eine öffentliche Adresse noch eine eingehende Regel; nur die Datenbank muss die Instanz zulassen.

Einrichtung

1
Der testenden Person die Gruppe engineering zuweisen
Die Regel in Schritt 8 lässt die Gruppe engineering zu. Nehmen Sie das Mitglied, das testen wird, in diese Gruppe auf: People › Members › das Mitglied › Access. Geben Sie unter Auto-assigned groups engineering ein, drücken Sie Enter und wählen Sie dann Save Changes; die Gruppe wird beim Speichern angelegt.

Bei eingeschalteter Gruppenweitergabe, dem Standard, gilt das sofort auch für ein Notebook, auf dem das Mitglied schon angemeldet ist: siehe Gruppenweitergabe.

Sie sehen: engineering im Reiter Access des Mitglieds.
2
Den Registrierungsschlüssel anlegen
Access › Enrollment keys › Create enrollment key. Danach lassen sich nur noch die Gruppen ändern; richten Sie den Schlüssel also jetzt für die Auto Scaling Group ein:
- Name - vpc-routers.
- Make this key reusable - an, für jede Instanz, die die Gruppe startet.
- Expires in - so lange, wie das Launch Template funktionieren soll, etwa 365 Tage; leer heißt nie.
- Usage limit - die Registrierungen, die Sie über die Lebensdauer des Schlüssels erwarten, etwa 50. Jede neue Instanz zählt, ebenso jede, die sich nach einem langen Ausfall erneut registriert.
- Temporary devices - an, damit beendete Instanzen nach 10 Minuten offline aus Devices verschwinden. Schritt 5 holt eine entfernte, aber noch laufende Instanz zurück.
- Allow Extra DNS Labels - aus.
- Auto-assigned groups - geben Sie vpc-routers ein und drücken Sie Enter. Schritt 9 fügt diese Gruppe hinzu.
Wählen Sie Create enrollment key, und kopieren Sie den Schlüssel sofort: Er wird nicht noch einmal angezeigt.
3
Den Schlüssel als Klartext-Secret ablegen
Der Block braucht die AWS CLI; ersetzen Sie darin eu-central-1 durch Ihre Region. Führen Sie den Block in bash oder zsh aus (macOS, Linux, WSL oder AWS CloudShell). Fügen Sie den ganzen Block ein und drücken Sie einmal Enter. Sobald Enrollment key: erscheint, fügen Sie den Schlüssel ein, und nur ihn, und drücken Sie Enter. Der Schlüssel wird nicht angezeigt, und bei einer leeren Zeile fragt der Block erneut.

Der Block legt den Schlüssel als Klartext ab; ein Secret aus Schlüssel-Wert-Paaren würde der Instanz JSON statt eines Schlüssels liefern.

Sie sehen: den ARN des Secrets, für Schritt 4.
shell
```
{  KEY=''  until [ -n "$KEY" ]; do printf 'Enrollment key: '; read -rs KEY || break; echo; done  [ -n "$KEY" ] && aws secretsmanager create-secret --region eu-central-1 \    --name sxaccess/enrollment-key --secret-string "$KEY" --query ARN --output text  unset KEY}
```
4
Die Instanzrolle anlegen
Legen Sie eine IAM-Rolle für EC2 mit den Berechtigungen unten an, mit dem ARN aus Schritt 3 unter Resource. Die Instanz kann dann dieses eine Secret lesen und kein anderes.

Hängen Sie außerdem AmazonSSMManagedInstanceCore an, das AWS bereitstellt. Damit öffnen Sie über Session Manager eine Shell auf der Instanz, ganz ohne öffentliche Adresse; die Fehlersuche nutzt sie.
shell
```
{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "secretsmanager:GetSecretValue",      "Resource": "arn:aws:secretsmanager:eu-central-1:111122223333:secret:sxaccess/enrollment-key-AbCdEf"    }  ]}
```
5
Die Routing-Instanz über eine Auto Scaling Group starten
Legen Sie ein Launch Template an und eine Auto Scaling Group, die es nutzt:
- Launch Template - Amazon Linux 2023, das die AWS CLI mitbringt, auf einem kleinen Instanztyp. Wählen Sie die Rolle aus Schritt 4 als IAM-Instanzprofil, keine öffentliche IP-Adresse und eine neue Security Group ohne eingehende Regeln, und tragen Sie das Skript unten als User-Data ein.
- Auto Scaling Group - die privaten Subnetze der VPC; gewünschte, minimale und maximale Kapazität 1. Sie ersetzt eine Instanz, die bei der Zustandsprüfung durchfällt oder beendet wird.
Das Skript installiert den Agenten und einen systemd-Timer, der ein Registrierungsskript sofort ausführt, eine Minute nach jedem Start und danach alle 5 Minuten. Solange die Instanz verbunden ist, tut das Registrierungsskript nichts. Hat SXAccess die Instanz nach mehr als 10 Minuten offline entfernt, registriert das Skript sie neu: EC2 hielte diese Instanz weiter für gesund und würde sie nie ersetzen.

Der Timer verbindet die Instanz auch nach einem manuellen sxaccess stop innerhalb von 5 Minuten wieder. Halten Sie ihn für Wartungsarbeiten zuerst mit sudo systemctl disable --now sxaccess-enrol.timer an, und schalten Sie ihn danach mit sudo systemctl enable --now sxaccess-enrol.timer wieder ein.

Sie sehen: nach einigen Minuten ein Gerät wie vpc-router-ip-10-0-1-23 unter Devices, in vpc-routers.
shell
```
#!/bin/sh# EC2-User-Data. Läuft einmal, beim ersten Start.set -eucurl -fsSL https://pkgs.sxaccess.com/install.sh | sh# Das Registrierungsskript. Ihre Region verwenden.cat > /usr/local/sbin/sxaccess-enrol <<'EOF'#!/bin/shset -eusxaccess info | grep -qx Connected && exit 0KEY=$(aws secretsmanager get-secret-value --region eu-central-1 \  --secret-id sxaccess/enrollment-key --query SecretString --output text)SX_ENROLLMENT_KEY="$KEY" sxaccess start --hostname "vpc-router-$(hostname -s)"EOFchmod 700 /usr/local/sbin/sxaccess-enrol# Sofort ausführen, 1 Minute nach jedem Start und danach alle 5 Minuten.cat > /etc/systemd/system/sxaccess-enrol.service <<'EOF'[Service]Type=oneshotExecStart=/usr/local/sbin/sxaccess-enrolEOFcat > /etc/systemd/system/sxaccess-enrol.timer <<'EOF'[Timer]OnBootSec=1minOnUnitActiveSec=5min[Install]WantedBy=timers.targetEOFsystemctl daemon-reloadsystemctl enable --now sxaccess-enrol.timersystemctl start sxaccess-enrol.service
```
6
Die Routing-Instanz in die Datenbank lassen
Mit eingeschaltetem Masquerade (Schritt 9) sieht die Datenbank die eigene Adresse der Routing-Instanz. Ergänzen Sie in der Security Group der Datenbank eine eingehende Regel für TCP 5432 mit der Security Group der Instanz aus Schritt 5 als Quelle. Sie gilt auch für jede Ersatzinstanz und ist die einzige eingehende Regel, die dieser Aufbau braucht.
7
Das Netzwerk und die Ressource anlegen
Networks › Internal networks › Add internal network. Tragen Sie unter Network Name VPC und Region ein, etwa prod-vpc eu-central-1, und wählen Sie Add Network. Als Nächstes öffnet sich Add Resource:
- Name - orders-db, der Name, den Notebooks sehen, etwa in sxaccess reach list.
- Address - der Writer-Endpunkt, etwa my-db.cluster-abc123.eu-central-1.rds.amazonaws.com. Als Domain folgt er der Adresse, wenn AWS sie ändert, und die Routing-Instanz löst ihn auf.
- Destination Groups - geben Sie vpc-databases ein und drücken Sie Enter; eine Ressource braucht eine Gruppe.
Wählen Sie Add Resource. Beschränken Sie Platzhalter auf Ihre eigenen Endpunkte, etwa *.cluster-abc123.eu-central-1.rds.amazonaws.com; mit *.rds.amazonaws.com liefe jeder RDS-Name, den ein Notebook auflöst, durch Ihre VPC.
8
Engineering die Datenbank erreichen lassen
Als Nächstes öffnet sich das Formular für die Zugriffsregel, mit orders-db bereits als Ziel.

Allow engineering to reach orders-db over TCP on ports 5432.
- Access rule name - ersetzen Sie den Vorschlag orders-db access rule durch die Absicht, etwa Engineering erreicht die Bestelldatenbank.
- Allow - wählen Sie engineering.
- over - wählen Sie TCP. Eine neue Regel beginnt mit any protocol, was jeden Port öffnet.
- on ports - klicken Sie in das Feld, geben Sie 5432 ein und drücken Sie Enter: Das Feld zeigt 5432 statt All. Bleibt es leer, ist jeder Port offen.
Direction bleibt auf One-way festgelegt. Wählen Sie Create access rule.
9
Die Routing-Instanzen als Gruppe hinzufügen
Zuletzt öffnet sich Add Routing Device. Wechseln Sie zu Device group, wählen Sie vpc-routers und dann Continue. Die Gruppe nimmt jede Instanz auf, die der Schlüssel registriert, auch Ersatzinstanzen; ein Eintrag für eine einzelne Instanz funktioniert nicht mehr, sobald diese weg ist.

Lassen Sie unter Settings Enable Routing Device und Masquerade eingeschaltet und Metric auf 9999, und wählen Sie Add Routing Device. Mit Masquerade bleiben Routingtabellen und Source/Destination Check unverändert. Die Datenbank ist jetzt erreichbar.

Für jede weitere Datenbank öffnen Sie das Netzwerk über seinen Namen unter Networks › Internal networks und wählen Add Resource. Wählen Sie dann in der Spalte Access rules dieser Ressource Add Access rule, füllen Sie die Regel wie in Schritt 8 aus und wählen Sie Create access rule. Lassen Sie die Instanz wie in Schritt 6 zu.

Der Bereich „Edit Resource“: Name, Beschreibung, ein Adressfeld für eine einzelne IP, einen CIDR-Block oder einen Domainnamen, „Destination Groups“ und „Enable Resource“. — Das Ressourcenformular, hier zum Bearbeiten einer bestehenden Ressource geöffnet. Ein verwalteter Endpunkt wird als Domain eingetragen und folgt so der Adresse, wenn AWS sie ändert.

Prüfen

Prüfen Sie auf dem Notebook der testenden Person aus Schritt 1, über den Endpunktnamen.

Erwartetes Ergebnis

Die SXAccess-App führt orders-db unter Resources, und die Datenbank nimmt eine Verbindung auf 5432 an, etwa von psql mit demselben Endpunkt wie innerhalb der VPC. Der Befehl unten für Ihr System prüft den Port: Er muss gelingen, in PowerShell erkennbar an TcpTestSucceeded : True.

Mit dem CLI-Agenten zeigt sxaccess reach list den Eintrag orders-db mit state: Selected, und sxaccess info -d führt ein vpc-router-Gerät auf, dessen Zeile Reaches den Endpunkt nennt.

Dann prüfen, dass die Regel den Zugang gewährt

Ein geschlossener Port beweist hier nichts, denn die Security Group der Datenbank verwirft andere Ports ohnehin. Schalten Sie stattdessen die Regel in ihrer Spalte Status unter Access › Access rules aus. Innerhalb von Sekunden verliert das Notebook orders-db: sxaccess reach list gibt There are no networks to show. aus, und die Verbindung schlägt fehl. Schalten Sie die Regel wieder ein.

Dann belegen, dass es einen Austausch übersteht

Beenden Sie die Routing-Instanz in der EC2-Konsole. Die Auto Scaling Group startet eine neue, die sich registriert und vpc-routers beitritt, und der Zugriff kommt innerhalb weniger Minuten von selbst zurück. Das alte Gerät verschwindet etwa 10 Minuten später aus Devices.

shell - vom Notebook prüfen, unter macOS

nc -vz -G 5 my-db.cluster-abc123.eu-central-1.rds.amazonaws.com 5432

shell - vom Notebook prüfen, unter Linux

nc -vz -w 5 my-db.cluster-abc123.eu-central-1.rds.amazonaws.com 5432

PowerShell - vom Notebook prüfen, unter Windows

Test-NetConnection my-db.cluster-abc123.eu-central-1.rds.amazonaws.com -Port 5432

Fehlersuche

Die ersten vier Zeilen sind AWS-spezifisch und decken die meisten Fälle ab.

Symptom	Wahrscheinliche Ursache	Abhilfe
Die Instanz erscheint nie unter Devices	Kein ausgehender Weg, etwa ein privates Subnetz ohne NAT-Gateway. Oder die Instanz konnte den Schlüssel nicht lesen: Prüfen Sie Rolle, Region und Namen des Secrets.	Korrigieren Sie die Standardroute des Subnetzes; ergänzen Sie keine eingehende Regel. Lesen Sie in einer Session-Manager-Shell auf der Instanz `/var/log/cloud-init-output.log` und `journalctl -u sxaccess-enrol`
Erreicht die Instanz, nicht die Datenbank	Die Security Group der Datenbank lässt die Instanz nicht zu, oder die IP-Weiterleitung wurde abgeschaltet, nachdem der Agent sie eingeschaltet hatte.	Schritt 6. In einer Session-Manager-Shell muss `sysctl net.ipv4.ip_forward` 1 ausgeben
Eine Domain-Ressource wird nicht aufgelöst	Die Instanz kann den Endpunkt nicht auflösen, etwa weil in der VPC die DNS-Auflösung oder die DNS-Hostnamen ausgeschaltet sind.	In einer Session-Manager-Shell muss `getent hosts <endpunkt>` eine private Adresse ausgeben
Neue Instanzen registrieren sich nicht mehr, oder eine bleibt nach einem Ausfall offline	Der Schlüssel ist abgelaufen oder hat sein Usage limit aufgebraucht, sodass sich eine entfernte Instanz nicht neu registrieren kann. `sxaccess info` gibt auf ihr `This device is not signed in (NeedsLogin).` aus.	Ersetzen Sie den Schlüssel wie unter Den Registrierungsschlüssel ersetzen beschrieben. Die Einstellungen eines Schlüssels lassen sich nicht bearbeiten
Es funktionierte, nach einem Deployment nicht mehr	Der Routing-Geräte-Eintrag nennt eine einzelne Instanz, oder das Image enthielt einen registrierten Zustand, sodass zwei Maschinen dieselbe Identität beanspruchen.	Fügen Sie die Gruppe als Device group hinzu (Schritt 9). Bauen Sie `/var/lib/sxaccess/` nie in ein AMI ein
An einem Ort funktioniert es, an einem anderen nicht	Das lokale Netz dort nutzt Adressen aus dem Bereich der VPC, und das lokale Netz hat Vorrang. Einzelne Endpunkte zu veröffentlichen, umgeht das nicht.	Geben Sie neuen VPCs einen Bereich, den diese Netze nicht nutzen
Beendete Instanzen sammeln sich unter Devices	Der Schlüssel wurde ohne Temporary devices angelegt, und das lässt sich nicht nachträglich einschalten.	Ersetzen Sie den Schlüssel durch einen mit eingeschalteter Option, wie unter Den Registrierungsschlüssel ersetzen beschrieben
Kommen Sie immer noch nicht weiter?	Zerlegen Sie die Verbindung Stufe für Stufe.	Nachvollziehen, warum eine Verbindung blockiert wird

Den Registrierungsschlüssel ersetzen

Legen Sie den neuen Schlüssel wie in Schritt 2 an, und ersetzen Sie im Block unten eu-central-1 durch Ihre Region. Führen Sie den Block in bash oder zsh aus (macOS, Linux, WSL oder AWS CloudShell). Fügen Sie den ganzen Block ein und drücken Sie einmal Enter. Sobald Enrollment key: erscheint, fügen Sie den Schlüssel ein, und nur ihn, und drücken Sie Enter. Der Schlüssel wird nicht angezeigt, und bei einer leeren Zeile fragt der Block erneut.

Sie sehen: die ID der neuen Version des Secrets. Instanzen lesen das Secret bei jeder Registrierung, die nächste nutzt also den neuen Schlüssel.

Widerrufen Sie dann den alten Schlüssel: Wählen Sie unter Access › Enrollment keys im Zeilenmenü des Schlüssels Revoke und bestätigen Sie mit Revoke key.

shell - dort, wo Sie Schritt 3 ausgeführt haben

{  KEY=''  until [ -n "$KEY" ]; do printf 'Enrollment key: '; read -rs KEY || break; echo; done  [ -n "$KEY" ] && aws secretsmanager put-secret-value --region eu-central-1 \    --secret-id sxaccess/enrollment-key --secret-string "$KEY" --query VersionId --output text  unset KEY}

Erweiterte Konfiguration

Eine Availability Zone überstehen

Geben Sie der Auto Scaling Group private Subnetze in zwei Zonen und eine Kapazität von 2. Alle Instanzen im Eintrag vpc-routers teilen sich eine Metric; Clients bevorzugen eine Instanz, mit der sie verbunden sind, und wechseln, wenn sie nicht mehr antwortet.

Soll eine Zone bevorzugt werden, bekommt jede Zone einen eigenen Schlüssel, eine eigene Gruppe und ein eigenes Launch Template, und jede Gruppe wird als eigener Eintrag hinzugefügt. Geben Sie dann dem bevorzugten Eintrag eine Metric unter 9999.

Eine Instanz mit Elastic IP

Der Agent erfährt die öffentliche Adresse, unter der er gesehen wird, bereits über STUN und bietet sie anderen Geräten als Verbindungskandidaten an. Das deckt die meisten Instanzen mit Elastic IP ab. Entsteht trotzdem kein direkter Pfad, hat sxaccess start eine Option für den Support, --external-ip-map (siehe die Befehlsreferenz), die die öffentliche Adresse ausdrücklich ankündigt; setzen Sie sie gemeinsam mit dem Support ein.

Doch den CIDR-Bereich der VPC veröffentlichen

Manchmal gibt es zu viele Endpunkte, um sie einzeln zu benennen. Legen Sie dann den Bereich der VPC als eine Ressource an, gleichen Sie ihn vorher mit den Netzen der Arbeitsorte ab, und bedenken Sie, dass er alles in der VPC freigibt, auch das, was nächsten Monat hinzukommt.

Andere Clouds

Azure und GCP funktionieren genauso: eine kleine Instanz im Netzwerk, nur ausgehende Verbindungen, Endpunkte als Domain-Ressourcen veröffentlicht.