Twee Verkeersrichtingen, Een Kast
Welkom
Meeste architectuurdiagrammen tonen verkeer in één richting: de client bovenaan, de server beneden, pijl naar beneden. De werkelijkheid heeft verkeer in beide richtingen.
Ingress: buitenpartijen komen via deze weg bij uw services. Een omgekeerde proxy aan de rand van uw netwerk eindigt TLS, routeert verzoeken en dwingt toegangsbeleid.
Egress: uw services komen via deze weg bij buitenste services. Een beller API van een betalingsverwerker, het ophalen van een webhook-doel, het verzenden van een verzoek naar een partner. Vaak via een voorwaarts proxy of NAT-gateway met toegangslijst.
Veel architecturen beginnen met één kast die zowel taken verzet. Het werkt, totdat de dag dat het niet meer doet. De faalmodus is subtiel, manifesteert alleen naarmate er genoeg interne services zijn, en leert een belangrijke les over de afbakening van zorgen.
Na het volgen van deze les zult u begrijpen:
- Waarom ingress & egress fundamenteel verschillende verkeerspatronen zijn met verschillende schaalvlakken en verschillende faalmodi
- Hairpin NAT en waarom een proxy die probeert zichzelf te verbinden faalt
- De architecturale splitsing: één kast wordt twee, en wat elk vervolgens uitsluitend bezit
- Beveiligingsisolatievoordelen: elke kant kan zich afschermen tegen zijn echte toegestane peers
- Hoe u kunt vaststellen wanneer uw enkelvoudige ontwerp de drempel heeft overschreden waarbij de splitsing nodig is
Waarom De Richtingen Andere Hulpmiddelen Vereisen
Twee Verschillende Belastingen Op Een Netwerkgrens
Ingress verkeerskenmerken:
- Geïnitieerd door buitenpartijen (het internet in het algemeen)
- Volume schaalt met uw gebruikersbasis
- TLS-afhandeling, verzoekroteren, beperking per bron
- Defensie-in-de-diepte: DDoS, misbruik, scraping
- Publieke IP moet verbindingen van iedereen accepteren
Egress verkeerskenmerken:
- Geïnitieerd door uw eigen services (een bekende, beperkte set clients)
- Volume schaalt met uw service-naar-service- en externe-API-aanroeppatronen
- Bron-IP toegangslijst op afstand (u heeft één vaste uitgaande IP die partners vertrouwen)
- Zorgen voor defensie-in-depth: gegevenslekken, verstoorde interne services die uitgaan
- Zou verbindingen van derden moeten weigeren, behalve van uw eigen services
De sleutelasymmetrie: ingress accepteert verkeer vanuit de wereld; egress accepteert verkeer alleen van uw eigen services. Plaatsen van hen op dezelfde machine betekent dat die machine tegelijkertijd bereikbaar moet zijn vanuit de wereld (voor ingress) & alleen bereikbaar moeten zijn vanuit uw services (voor egress). De firewallregels die voldoen aan een werken tegen de andere.
De groeipad: een klein project kan zowel ingress als egress verbergen achter één IP & één tool, omdat het volume klein is & de partner-IP-allowlist kort is. Naarmate het project groeit, neemt de frictie tussen de twee rollen toe, & op een dag dwingt een specifieke falende modus (hairpin NAT) de splitsing.
De Mislukking Die De Splitting Forceert
Een Gezouterd Porrekesverhaal
Beeld u een echte architecturale splitsing die zich voordoet in productiefleets. De namen hieronder zijn veranderd; de vorm is identiek aan wat teams in het wild raken.
Een organisatie draait een enkele proxyserver op 203.0.113.5. Het handelt ingress (poort 443 voor gebruikers) & egress (poort 1080 SOCKS5 voor interne services die uitgaand verkeer aanroepen). Interne services leven in private subnetten & sturen alle uitgaande verkeer via die SOCKS5-proxy op 203.0.113.5:1080.
Eén van de services die achter dezelfde 203.0.113.5 draait, is api.example.com. Publieke DNS resolutie voor api.example.com naar 203.0.113.5.
Nu een andere interne service api.example.com moet aanroepen. Zijn uitgaande pad:
1. Interne service resolutie api.example.com → 203.0.113.5
2. Interne service stuurt de aanvraag via de SOCKS5 egress-proxy op 203.0.113.5:1080
3. De proxy probeert een verbinding te openen vanuit zichzelf naar 203.0.113.5:443
4. Verboden verbinding. Het pakket zou uit en weer terug hetzelfde NAT moeten passeren, wat de meeste netwerkstacks weigeren. De proxy kan niet verbinden met zichzelf via zijn eigen openbare IP.
Dit is haarspeld NAT: een pakket dat een NAT verlaat en weer naar dezelfde NAT moet om zijn bestemming te bereiken. Zonder speciale haarspeldondersteuning op laag van de routing, valt het pakket.
Waarom het laat opduikt
Aan het begin van het leven van het project spraken alle interne services zichzelf of niet met andere interne services via een privé-hostnaam (internal-api.local). De haarspeldpad bestond gewoon niet.
Toen een nieuw feature vereiste dat service A api.example.com (een publieke hostnaam) moest bellen, activeerde de haarspeldpad. Weigeren van de verbinding. Outage.
De oplossing sloot het symptoom (dwang om de resolver een privé-IP te geven in plaats van een publieke IP voor api.example.com). De oorzaak: een enkele box deed te veel banen.
De Architectonische Vork
Een Enkele Box Wordt Twee
De schone oplossing: de proxy splitsen in twee machines.
Ingress server (publieke IP 203.0.113.5):
- Caddy / omgekeerde proxy op poorten 80, 443
- Publieke DNS records wijzen hier naar
- Hosts api.example.com, app.example.com, etc.
Egress server (een andere publieke IP 203.0.113.99):
- SOCKS5 / voorwaartse proxy op poort 1080
- Firewall beperkt inkomende verbindingen tot alleen interne subnet-IP's
- Interne services sturen alle uitgaande verkeer via deze adres
Wat dit koopt:
1. Haarspeld opgelost. Een interne service die api.example.com belt, stuurt uitgaand verkeer via 203.0.113.99 (egress), die vervolgens normaal verbindt met 203.0.113.5 (ingress, een andere IP). De NAT-lus verdwijnt omdat de twee IPs leven op verschillende machines.
2. Isolatie van de beveiliging. De firewall van de egress server kan worden geblokkeerd op een klein set interne IP's. De firewall van de ingress server blijft open voor de wereld. Twee aparte sets regels, elk expressend een duidelijke rol.
3. Afzonderlijke schaling. Bandbreedte van ingress schaalt met gebruikers; bandbreedte van egress schaalt met interne-service-activiteit. Upgraden van één zonder aanraking van de andere.
4. Isolatie van fouten. Een verkeerd geconfigureerde egress doet de publieke site niet meer kapot. Een DDoS tegen de publieke site doet de bandbreedte van egress niet langer ophouden.
5. Duidelijker mentaal model. Elk apparaat heeft één taak. Ingenieurs denken na over ingress-zorgen zonder na te denken over egress, & vice versa.
Twee Assen, Twee Beslissingen Over Grootte
Onafhankelijke Schaling
Voordat het split was, werd de groei in beide richtingen op dezelfde machine belast. Na het split had elke richting zijn eigen inrichting.
Ingress-grootte: schaalt met gebruikers. Capaciteitsbeslissingen leven in de publieke laag (meer omgekeerde proxy-replica's, grotere VM's, CDN voorop). Bandbreedtebudget berekend tegen gebruikersverkeer op piek.
Egress-grootte: schaalt met interne service-naar-externe API-aanroepvolume. Vaak beheerst door webhook-afleveringen, betalingsverwerkercalls of het opvragen van derde-partijgegevens. Bandbreedtebudget berekend tegen interne aanroeppatronen.
Foutafhankelijke isolatie: een DDoS tegen de publieke ingress eet de egress-bandbreedte niet op (die betalingsverwerkercalls gaan gewoon door). Een egress-proxy-crash neemt de publieke site niet meer down (gebruikers kunnen de site nog bereiken; alleen interne uitgaande calls mislukken).
Verschillende SLO's: ingress-beschikbaarheid is van belang voor gebruikers (zichtbare siteuitval); egress-beschikbaarheid is van belang voor operators (achtergrondfouten die langer kunnen worden gedetecteerd). Elke kant kan zijn eigen SLO dragen.
Meerdere Egress-servers
Zodra de egressrol zijn eigen machine is, is de volgende duidelijke stap om er meerdere egress-machines achter een load balancer uit te voeren voor HA. Elk nieuw interne service wijst naar de egress-hostnaam (die resolutie heeft naar de belaste pool) in plaats van naar een enkele IP.
Zelfde les als bij de rest van de distribueerde systemen: zodra een laag staatloos is en zijn eigen rol heeft, vermenigvuldigt het zich voordelig.
Een Nieuwe Partnerintegratie
Uw organisatie voert het ingress / egress-split uit zoals ontworpen. De egress-server heeft een vaste publieke IP-adres (203.0.113.99) die u met drie bestaande partner-API's (een betalingsverwerker, een SMS-gateway, een e-mailprovider) heeft toegelaten.
Een productteam wil een vierde integratie toevoegen: een webhookbeheersysteem dat terugbelt naar klantendestincties over de hele wereld. Voorspeld volume: 10.000 oproepen per minuut, met pieken tot 30.000.
Ontwerp een Netwerkgrens voor een Groeiend Dienst
Samenvatting
Je hebt geleerd waarom ingress & egress verschillende hulpmiddelen nodig hebben, het hairepin NAT-fout dat de splitsing in de praktijk dwingt, & hoe onafhankelijke schaling, beveiligingsisolatie & foutisolatie toekomen nadat de splitsing is gerealiseerd.
Gebruik alle vier.
Een middenformaat SaaS-bedrijf draait drie productsubdomeinen (app, api, admin) voor hun gebruikers, plus vier uitgaande integraties (Stripe, Twilio, SendGrid, een klant-webhook-systeem). Allemaal leven er vandaag achter een enkele proxy-machine op één openbare IP. Ze krijgen sinds kort berichten over onderbroken hairepin-fouten wanneer interne services proberen om naar api.example.com te bellen. Ze willen een duurzame oplossing ontwerpen.
Waar Dit Cursus Volgende Gaat
Waar Dit Cursus Volgende Gaat
Je hebt nu één van de schone herverdelingen van zorgen in de verdeling van systemen gezien: één doos wordt twee, elk met een duidelijke rol, & het systeem erfde schaalvoordelen, beveiliging & foutisolatie.
De volgende les (cs_distsys_failure_modes_and_blast_radius) breidt de redenering over foutisolatie uit. Je zult een gesaniteerde DNS-SERVFAIL-postmortem lezen, de patroon van de kettingfout identificeren & schuldloze actiepunten schrijven die systemen richten in plaats van mensen.
Bijschriftles: geometry_of_ingress_egress_separation verzet de splitsing om in een bipartiel graf en onderzoekt knooppunten, netwerkdelingen en wat grafentheorie je vertelt over de grens van een netwerk.
Goed gedaan. Verder.