Zwei Verkehrsrichtungen, Eine Box
Willkommen
Die meisten Architekturdiagramme zeigen Verkehr in einer Richtung: Client oben, Server unten, Pfeil zeigt nach unten. Die Realität hat Verkehr in beide Richtungen.
Ingress: Außenclients erreichen Ihre Dienste über diesen Weg. Ein Reverse-Proxy am Rand Ihres Netzwerks beendet TLS, leitet Anforderungen und erzwingt Zugriffspolitik.
Egress: Ihre Dienste erreichen externe Dienste über diesen Weg. Aufruf eines Zahlungsverarbeiters-API, Abrufen eines Webhook-Ziels, Senden einer Anfrage an einen Partner. Oft über einen Forward-Proxy oder NAT-Gateway mit einer Erlaubnisliste.
Viele Architekturen beginnen mit einer Box, die beide Aufgaben übernimmt. Es funktioniert, bis der Tag anbricht, an dem es nicht mehr funktioniert. Das Versagensmuster ist subtil, zeigt sich erst, wenn genug interne Dienste existieren, und lehrt eine wichtige Lektion zur Trennung von Sorgenpflichten.
Nach Abschluss dieses Unterrichts werden Sie verstehen:
- Warum Ingress und Egress grundlegend verschiedene Verkehrsmustern mit unterschiedlichen Skalierungsachsen und unterschiedlichen Versagensmustern repräsentieren
- Hairpin NAT und warum eine Proxy-Box, die versucht, sich selbst zu verbinden, versagt
- Die architektonische Gabelung: Eine Box wird zu zwei, und was jede dann ausschließlich besitzt
- Sicherheitsisolierungsgewinne: Jede Seite kann sich auf ihre echten erlaubten Peer beschränken
- Wie Sie erkennen, wenn Ihr Einzel-Box-Design den Schwellenwert überschritten hat, an dem der Splitting notwendig ist
Warum Die Richtungen Andersartige Werkzeuge Verlangen
Zwei Verschiedene Arbeitslasten an Einer Netzwerkgrenze
Ingress-Verkehrsmerkmale:
- Initiiert von außen (das Internet im Großen und Ganzen)
- Volumen skaliert mit Ihrer Benutzerbasis
- TLS-Beendigung, Anforderungsrouting, Geschwindigkeitsbegrenzung pro Quelle
- Verteidigung-in-Tiefe-Bedenken: DDoS, Missbrauch, Scraping
- Öffentliche IP-Adresse muss Verbindungen von jedem akzeptieren
Egress-Verkehrsmerkmale:
- Initiiert von Ihren eigenen Diensten (ein bekanntes, kleines Set von Clients)
- Volumen skaliert mit Ihrer Service-zu-Service- und externen-API-Aufrufmustern
- Quell-IP-Zulassungsliste für remote Endpunkte (Sie haben eine feste Ausgangs-IP, auf die Partner vertrauen)
- Sicherheitsbedenken im Hinblick auf den Tiefenschutz: Datenverlust, interne Dienste, die aufgrund eines Verstoßes aufrufen
- Soll Verbindungen von allen anderen als Ihren eigenen Diensten ablehnen
Die Schlüsselasymmetrie: Eingang akzeptiert Verkehr aus der Welt; Ausgang akzeptiert Verkehr nur von Ihren eigenen Diensten. Wenn Sie beide auf demselben Gerät installieren, muss dieses Gerät gleichzeitig von der Welt erreichbar sein (für Eingang) und nur von Ihren Diensten erreichbar sein (für Ausgang). Die Firewall-Regeln, die einer Rolle gerecht werden, arbeiten gegen die andere.
Der Wachstumspfad: Ein kleines Projekt kann beide hinter einer IP-Adresse und einem Tool verstecken, weil der Volumen klein ist und die Partner-IP-Liste kurz. Wenn das Projekt wächst, erhöht sich der Widerstand zwischen den beiden Rollen, und eines Tages zwingt eine spezifische Fehlerbedingung (Hairpin NAT) die Trennung.
Der Fehler, der die Trennung erzwingt
Eine Desinfektionsausfallgeschichte
Bilden Sie sich ein echtes architektonisches Trennungsverfahren vor, das in Produktionsflotten auftritt. Die Namen wurden geändert; die Form ist identisch mit dem, was Teams in der Wildnis treffen.
Eine Organisation betreibt einen einzelnen Proxy-Server unter 203.0.113.5. Er handhabt Eingang (Port 443 für Benutzer) und Ausgang (Port 1080 SOCKS5 für interne Dienste, die auswärts rufen). Interne Dienste befinden sich in privaten Subnetzen und leiten alle auswärtige Verbindung über den SOCKS5-Proxy auf 203.0.113.5:1080.
Einer der hinter dem gleichen 203.0.113.5 gehosteten Dienste ist api.example.com. Die öffentliche DNS-Resolution führt api.example.com auf 203.0.113.5.
Jetzt benötigt eine andere interne Dienst api.example.com aufrufen. Sein auswärtiger Weg:
1. Interne Dienst löst api.example.com auf 203.0.113.5
2. Interne Dienst sendet die Anfrage über den SOCKS5-Ausgangsproxy auf 203.0.113.5:1080
3. Der Proxy versucht, eine Verbindung von sich zu 203.0.113.5:443 herzustellen
4. Verbindung abgelehnt. Das Paket müsste aus- und erneut in den gleichen NAT eintreten, was die meisten Netzwerk-Stacks ablehnen. Der Proxy kann sich nicht über seine eigene öffentliche IP-Adresse über seinen eigenen Proxy verbinden.
Dies ist Hairpin NAT: ein Paket, das ein NAT verlässt und zum Erreichen seiner Zieladresse erneut in das gleiche NAT eintreten muss. Ohne besondere Hairpin-Unterstützung auf der Routing-Ebene fällt das Paket.
Warum es spät auftaucht
Im frühen Leben des Projekts sprachen alle internen Dienste entweder über private Hostnamen (internal-api.local) miteinander oder riefen nicht in die eigenen öffentlichen Dienste zurück. Der Hairpin-Pfad existierte einfach nicht.
Dann war ein neues Feature erforderlich, damit Dienst A api.example.com (ein öffentlicher Hostnamen) aufrufen musste. Der Hairpin-Pfad wurde aktiviert. Verweigerung des Zugangs. Ausfall.
Der Ausgleichspatch hat das Symptom behoben (die Resolver haben api.example.com's private IP statt der öffentlichen gegeben). Die Ursache: Eine einzelne Box hat zu viele Aufgaben gemacht.
Der architektonische Gabel
Eine Box wird zu zwei
Der saubere Fix: Trennen Sie den Proxy in zwei Maschinen.
Eingangsserver (öffentliche IP 203.0.113.5):
- Caddy / Reverse Proxy auf Ports 80, 443
- Öffentliche DNS-Einträge verweisen hierher
- Hostet api.example.com, app.example.com, usw.
Ausgangsserver (eine andere öffentliche IP 203.0.113.99):
- SOCKS5 / Forward Proxy auf Port 1080
- Firewall beschränkt eingehende Verbindungen auf interne Subnetz-IPs nur
- Interne Dienste leiten alle ausgehenden Verbindungen über diese Adresse
Was das kauft:
1. Hairpin gelöst. Ein interner Dienst, der api.example.com aufruft, leitet ausgehend via 203.0.113.99 (ausgang), der dann normal zu 203.0.113.5 (eingang, eine andere IP) verbindet. Die NAT-Schleife verschwindet, weil die beiden IPs auf verschiedenen Maschinen leben.
2. Sicherheitsisolation. Die Firewall des Ausgangsservers kann auf einen kleinen Satz von internen IPs eingeschränkt werden. Die Firewall des Eingangsservers bleibt für die Welt offen. Zwei separate Regelsets, jedes ausdrückt einen einzigen Rolle sauber.
3. Unabhängige Skalierung. Eingangsbänderbreite skaliert sich mit Benutzern; ausgehende Bandbreite skaliert sich mit internedienstaktivität. Aktualisieren Sie eines ohne das andere zu berühren.
4. Isolierung von Fehlerquellen. Ein falsch konfiguriertes Ausgangsgerät bricht nicht mehr die öffentliche Site. Ein DDoS-Angriff gegen die öffentliche Site führt nicht mehr zu einer Erschöpfung der ausgehenden Bandbreite.
5. Kläreres mentalisches Modell. Jeder Maschine gibt es eine Aufgabe. Ingenieure denken über Eingangsbewegungen nach, ohne über Ausgangsbewegungen nachzudenken, und umgekehrt.
Zwei Achsen, zwei Größenentscheidungen
Unabhängige Skalierung
Bevor der Split durchgeführt wurde, wurde das Wachstum in beiden Richtungen auf derselben Maschine belastet. Nachdem der Split durchgeführt wurde, hat jede Richtung ihre eigene Bereitstellung.
Eingangsskalierung: Skaliert sich mit den Benutzern. Kapazitätsentscheidungen befinden sich im öffentlichen sichtbaren Bereich (mehr Reverse-Proxy-Instanzen, größere VMs, CDN vorne). Bandbreitenbudget berechnet gegenüber Benutzertrafik im Spitzenwert.
Ausgangsskalierung: Skaliert sich mit interner Service-externer API-Aufrufvolumen. Wird häufig durch Webhook-Übertragung, Zahlungsverarbeitungsanrufe oder Abrufe von Drittanbietedaten bestimmt. Bandbreitenbudget berechnet gegenüber internen Aufrufmustern.
Isolierung von Fehlern: Ein DDoS-Angriff gegen die öffentliche ingress führt nicht dazu, dass die egress-Bandbreite verzehrt wird (diese Zahlungsverarbeitungsanrufe laufen trotzdem weiter). Ein egress-Proxy-Sturz führt nicht dazu, dass der öffentliche Site runtergeht (Benutzer erreichen immer noch die Site; nur interne ausgehende Anrufe scheitern).
Verschiedene SLOs: Verfügbarkeit von Eingangseinheiten ist für die Benutzer wichtig (sichtbare Siteausfall); Verfügbarkeit von Ausgangseinheiten ist für die Betreiber wichtig (Hintergrundfehler, die möglicherweise länger zum Erkennen benötigen). Jede Seite kann ihren eigenen SLO tragen.
Mehrere egress-Servers
Einmal in der Rolle des egress-Maschinen, ist der nächste offensichtliche Schritt, mehrere egress-Maschinen hinter einem Lastausgleich zu betreiben, um HA zu gewährleisten. Jedes neue interne Service zeigt auf den egress-Hostnamen (der sich auf den Lastausgleich gepoolten Pool auflöst) anstatt auf eine einzelne IP.
Das gleiche Lernergebnis wie bei den meisten verteilten Systemen: Sobald ein Tiers stateless ist und seine eigene Rolle hat, multipliziert es sich günstig.
Ein neuer Partnerintegration
Ihre Organisation führt den ingress / egress-Split wie geplant durch. Der egress-Server hat eine feste öffentliche IP-Adresse (203.0.113.99), die Sie mit drei bestehenden Partner-APIs (einem Zahlungsverarbeitungsanbieter, einem SMS-Gateway und einem E-Mail-Anbieter) zugelassen haben.)
Ein Produktteam möchte eine vierte Integration hinzufügen: ein Webhook-Übertragungssystem, das in Kunden-Endpunkte weltweit zurückruft. Volumenprognose: 10.000 Anrufe pro Minute, mit Spitzen bis zu 30.000.
Entwerfen eines Netzwerk-Grenzbereichs für ein wachsendes Service
Synthese
Sie haben gelernt, warum Ingress und Egress unterschiedliche Werkzeuge benötigen, das Hairpin-NAT-Fehlertreten, das die Trennung in realen Flotten erzwingt, und wie unabhängige Skalierung, Sicherheitsisolation und Fehlerisolation sich ergeben, sobald die Trennung wirksam wird.
Anwenden Sie alle vier.
Ein mittelgroßes SaaS-Unternehmen betreibt drei Produkt-Subdomains (app, api, admin) für ihre Benutzer, plus vier ausgehende Integrationen (Stripe, Twilio, SendGrid, ein Kunden-Webhook-System). Heute leben alles hinter einer einzelnen Proxy-Maschine unter einer öffentlichen IP-Adresse. Sie erhalten seitdem Berichte über gelegentliche Hairpin-Fehler, wenn interne Dienste versuchen, api.example.com aufzurufen. Sie möchten eine dauerhafte Lösung entwerfen.
Wohin diese Lehrveranstaltung weitergeht
Wohin diese Lehrveranstaltung weitergeht
Sie haben jetzt einen der saubersten Trennungsrefinements in verteilten Systemen gesehen: Eine Box wird zu zwei, jede mit einer klaren Rolle, und das System erbt Skalierung, Sicherheit und Fehlerisolationseigenschaften auf dem Weg.
Das nächste Kapitel (cs_distsys_failure_modes_and_blast_radius) erweitert die Fehlerisolation. Lesen Sie einen zensierten DNS-SERVFAIL-Postmortem, identifizieren Sie das Muster der kaskadierenden Fehler und schreiben Sie schuldunabhängige Maßnahmen, die Systeme anstelle von Personen ansprechen.
Kommunikationsunterricht: geometry_of_ingress_egress_separation stellt die Trennung als bipartites Graph dar & untersucht Schnittpunkte, Netzwerkpartitionen & was die Graphentheorie über eine Netzwerkgrenze aussagt.
Gut gemacht. Weiter so.