Die Adresse des VPN-Clients bis zur Anwendung durchzureichen sorgt dafür, dass jede Logzeile und jeder Eintrag in der Allowlist dasselbe bedeuten. Sie am Cloud-Rand umzuschreiben macht die Routing-Tabelle einfacher und die Logs weniger nützlich. Keine der beiden Entscheidungen ist für sich falsch, und das Argument, das sie entscheidet, hat selten mit Performance zu tun. Drei Bedingungen geben den Ausschlag: ob die Anwendung wissen muss, welcher Mensch verbunden war, ob die Cloud-Fabric die Quelle akzeptiert, die Sie senden wollen, und wer anschließend die Rückroute verantworten will.

Drei Bedingungen entscheiden

Beginnen Sie mit der Anforderung der Anwendung, nicht mit dem Netzwerkdiagramm. Hängt Autorisierung oder Audit von der individuellen Clientadresse ab, dann ist deren Erhalt eine funktionale Anforderung und die Übersetzung eine Regression. Muss die Anwendung nur wissen, dass Verkehr über den Fernzugriffspfad angekommen ist, genügt eine übersetzte Adresse und ist deutlich billiger zu betreiben.

Die zweite Bedingung ist technisch. Ein virtuelles Netzwerk vertraut einem Paket nicht automatisch, das eine Adresse angibt, die der sendenden Schnittstelle nicht zugewiesen wurde. Die meisten Cloud-Fabrics erzwingen das, auf unterschiedliche Weise und unter unterschiedlichen Namen, und ein Design, das es ignoriert, sieht im Diagramm korrekt aus und verwirft in der Produktion stillschweigend.

Die dritte ist organisatorisch. Quellen zu erhalten bedeutet, dass die Routing-Tabelle des Anwendungssubnetzes für das Client-Präfix auf das Gateway zurückzeigen muss, und jedes Team, das später ein Subnetz hinzufügt, muss diese Route konsistent halten. Das ist einmal ein kleiner Aufwand und über Dutzende von Konten hinweg ein wiederkehrender. Entscheiden Sie, wer ihn trägt, bevor Sie das Verhalten versprechen.

Eine Route ist keine Erlaubnis zu spoofen

Eine Rückroute hinzuzufügen sagt Ihrem Subnetz, wohin Antworten gehen sollen. Sie sagt der Fabric nicht, dass die Instanz, die diese Pakete weiterleitet, sie mit einer fremden Quelle senden darf. Bei AWS ist die relevante Kontrolle die Quell- und Zielprüfung, und sie ist pro Instanz sichtbar:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Schalten Sie das nur für die Instanz ab, deren dokumentierte Aufgabe das Weiterleiten ist, und für nichts sonst. Jede Anwendungs-VM, die die Prüfung aktiv lässt, ist eine Maschine weniger, die genutzt werden kann, um Verkehr mit einer geliehenen Quelle zu senden. Wenn Ihre Plattform nicht AWS ist, suchen Sie die entsprechende Anti-Spoofing- oder Allowed-Address-Einstellung, statt anzunehmen, dass das Verhalten übertragen wird.

Ein kurzer Paketmitschnitt klärt die Frage schneller als das Lesen der Konsole. Wenn Antworten hinausgehen und der Client sie nie sieht, verwirft die Fabric die gefälschte Quelle, statt dass die Anwendung versagt.

Was Übersetzung bringt und was sie kostet

Die Quelle am Gateway umzuschreiben beseitigt das Rückwegproblem. Die Anwendung sieht eine Adresse, die sie bereits zu erreichen weiß, und das Client-Präfix muss nie in einer Cloud-Routing-Tabelle erscheinen. Unter Linux ist die Regel eine Zeile, und es lohnt sich, die engste Version zu schreiben, die Sie hinbekommen:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Beachten Sie, was die Anwendung nun erfasst: 10.40.3.10 für jeden Nutzer, bei jeder Verbindung, für immer. Jede Adress-Allowlist, die auf diesem Wert aufbaut, gewährt nun Zugriff auf die gesamte Fernzugriffspopulation, und jede Incident-Review muss zum Gateway zurückgehen, um zu beantworten, wer das war.

Die Lösung ist nicht, die Übersetzung aufzugeben, sondern aufzuhören, die Adresse für eine Identität zu halten. Tragen Sie die Client-Identität in einem authentifizierten Feld, protokollieren Sie sie am Gateway zusammen mit dem übersetzten Tupel, und lassen Sie die Anwendung darauf joinen. Ohne den Join-Schlüssel verwandelt die Übersetzung ein Netzwerkproblem in ein dauerhaftes forensisches.

Der Relay ist eine andere Schnittstelle

Ein Reverse-Proxy vor der Anwendung umgeht die Frage des gerouteten Pfads vollständig. Der Proxy öffnet seine eigene Backend-Verbindung, sodass das Client-Präfix innerhalb des virtuellen Netzwerks nie routbar sein muss, und die Anwendung kann die Identität in einem Header empfangen, den der Proxy setzt.

Dieser Header ist nur dann vertrauenswürdig, wenn das Backend ihn vom Proxy und von nichts anderem akzeptiert. In nginx-Begriffen heißt das, den vertrauenswürdigen Peer ausdrücklich zu benennen, statt zu glauben, was auch immer ankommt:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Jeder Client, der das Backend direkt erreichen kann, kann denselben Header fälschen, also muss das Backend außer über den Proxy unerreichbar sein. Das ist eine Firewall-Tatsache, keine Konfigurationsmeinung, und es ist die Annahme, die Leute überspringen, wenn sie den Snippet kopieren.

Der Relay ändert auch, was Sie kaufen. Sie bekommen eine Identität auf Anwendungsebene und einen natürlichen Ort, sie zu protokollieren; Sie geben Allgemeinheit auf, weil jedes neue Protokoll seine eigene Proxy-Unterstützung braucht. Für HTTP-Dienste ist dieser Tausch meist gut, und für alles, was nicht HTTP ist, ist er meist gar nicht verfügbar.

Schreiben Sie auf, was jede Grenze sieht

Was immer Sie wählen, die Design-Review sollte mit einer Tabelle enden, die an jedem Hop die Quelladresse und die belegbare Identität nennt. Ohne sie bringt der erste Vorfall drei Teams hervor, die jeweils einen anderen Client beschreiben.

BoundarySource the next hop seesWhat is actually proven
Client to gateway172.20.8.14A certificate or credential was presented
Gateway to app subnet, preserved172.20.8.14The same session, if the return route exists
Gateway to app subnet, translated10.40.3.10Only that traffic came through the gateway
Proxy to backend10.40.3.10 plus a headerThe proxy asserted an identity it authenticated

Dann wählen Sie. Erhalten Sie die Quelle, wenn die Autorisierung der Anwendung wirklich von der Clientadresse abhängt und Sie die Route verantworten können. Übersetzen Sie, wenn das nicht der Fall ist und Sie die Identität out of band tragen können, und nutzen Sie die AWS-Anleitung für Forwarding-Instanzen für die plattformspezifischen Forwarding-Einstellungen. Greifen Sie zum Relay, wenn der Dienst HTTP spricht und Sie wollen, dass Identität überhaupt keine Adresse mehr ist.

Ähnliche Artikel