Två Trafikriktningar, En Box
Välkomna
De flesta arkitekturdiskar visar trafik som går en enda väg: klienten uppifrån, servrarna nere, pil pekar nedåt. Verkligheten har trafik som går både upp och ned.
Ingress: Utomstående når dina tjänster via denna väg. En reversproxy på kanten av ditt nätverk avslutar TLS, dirigerar begäranden och upprätthåller åtkomstpolicy.
Egress: Dina tjänster når utomstående tjänster via denna väg. Anropa ett betalningsprocessors API, hämta en webhook-mål, skicka en begäran till en partner. Ofta genom en framåtproxy eller NAT-gateway med tillåtelselista.
Många arkitekturer börjar med en enda box som hanterar båda. Det fungerar, tills dagen då det inte gör det. Felmönstret är subtilt, uppträder bara efter att tillräckligt många interna tjänster finns, och lärorikt om separation av oroer.
Efter den här lektionen kommer du att förstå:
- Varför ingress och egress representerar fundamentalt olika trafikmönster med olika skalningsaxlar och olika felmönster
- Hairpin NAT och varför en proxy som försöker ansluta till sig själv misslyckas
- Arkitekturforken: en box blir två, och vad varje äger sedan uteslutande
- Säkerhetsisolationsvinster: varje sida kan stänga ner till sina verkliga tillåtna parter
- Hur man identifierar när din enskildesign har överskridit tröskeln där splittringen är nödvändig
Varför Riktningarna Kräver Skilda Verktyg
Två Skilda Arbetsbelastningar vid en Nätverksgräns
Ingress trafikegenskaper:
- Initierad av utomstående parter (internet i stort)
- Volymen skalar med ditt användarbaser
- TLS-avslutning, begäranrouting, begränsning per källa
- Försvar i djupet: DDoS, missbruk, scraping
- Offentligt IP måste acceptera anslutningar från vem som helst
Egress trafikegenskaper:
- Initierad av dina egna tjänster (ett känt, litet set av klienter)
- Volymen skalar med ditt service-till-service- och extern-API-anropsmönster
- Käll-IP tillåtlistning på avlägsna ändpunkter (du har en fast utgående IP som partners litar på)
- Försvar i djupet: datapåfyllning, kompromissade interna tjänster som ringer ut
- Bör avvisa anslutningar från någon annan än egna tjänster
Nyckelns asymmetri: ingress accepterar trafik från världen; egress accepterar trafik endast från egna tjänster. Att placera dem på samma maskin innebär att maskinen måste vara tillgänglig både från världen (för ingress) & bara från egna tjänster (för egress). Brandväggsregler som uppfyller ett arbetar mot det andra.
Utvecklingsvägen: ett litet projekt kan dölja både bakom en IP och en enda verktyg, eftersom volymen är liten och partners IP-allowlist är kort. När projektet växer ökar spännvidden mellan de två rollerna, och en dag tvingas en specifik felaktighet (hairpin NAT) till en delning.
Buggen som tvingar till en delning
En desinficerad uttagsberättelse
Bilda er om en riktig arkitekturgång som inträffar i produktionsflottan. Namnen nedan har ändrats; formen är identisk med vad som träffar i det fria.
En organisation kör en enda proxyserver på 203.0.113.5. Den hanterar ingress (port 443 för användare) & egress (port 1080 SOCKS5 för interna tjänster som ringer ut). Interna tjänster finns i privata undernät & dirigerar alla utgående trafik genom den här SOCKS5-proxy på 203.0.113.5:1080.
En av tjänsterna som är värd för samma 203.0.113.5 är api.example.com. Offentlig DNS resolverar api.example.com till 203.0.113.5.
Nu behöver en annan intern tjänst ringa api.example.com. Den utgående vägen:
1. Intern tjänst resolverar api.example.com → 203.0.113.5
2. Intern tjänst skickar begäran genom den SOCKS5 utgående proxy på 203.0.113.5:1080
3. Proxy försöker öppna en anslutning från sig själv till 203.0.113.5:443
4. Avslagen anslutning. Paketet skulle ha måste gå ut & återinträda samma NAT, vilket de flesta nätverksstaplar avvisar. Proxy kan inte ansluta till sig själv via sin egen offentliga IP.
Denna är hårsken-NAT: ett paket som lämnar en NAT och måste återinträda samma NAT för att nå dess destination. Utan speciell hårsken-stöd i rutnätslagret faller paketet.
Varför Det Upptäcks Sent
I början av projektets liv pratade alla interna tjänster antingen med andra interna tjänster via privat värdnamn (internal-api.local) eller ringde inte tillbaka till sina egna organisations publika tjänster. Hårsken-passen existerade enkelt laget.
Då en ny funktion krävde att tjänst A skulle ringa api.example.com (en publik värdnamn) aktiverades hårsken-passen. Anslutningsneks. Utbrott.
Lösningen lade locket på symptomet (tvinga upplösaren att ge api.example.com's privata IP i stället för publik). Rotorsaken: en enda box gjorde för många jobb.
Den Arkitektoniska Gaveln
En Box blir Två
Den rena lösningen: skilj proxy:n i två maskiner.
Ingress-server (publik IP 203.0.113.5):
- Caddy / omvänd proxy på portarna 80, 443
- Publika DNS-poster pekar hit
- Värdar api.example.com, app.example.com, etc.
Egress-server (annan publik IP 203.0.113.99):
- SOCKS5 / framåt proxy på port 1080
- Brandvägg begränsar inkommande anslutningar till interna subnet-IP:er endast
- Interna tjänster dirigerar alla utgående genom denna adress
Vad Detta Köper:
1. Hårsken löst. En intern tjänst som ringer api.example.com dirigerar utgående via 203.0.113.99 (egress), som sedan ansluter normalt till 203.0.113.5 (ingress, en annan IP). NAT-loopet försvinner eftersom de två IP:erna lever på olika maskiner.
2. Säkerhetsisolation. Egress-servrarns brandvägg kan låsa ner till ett litet set av interna IP:er. Ingress-servrarns brandvägg står öppen för världen. Två separata regeluppsättningar, var och en uttrycker en ren roll.
3. Oberoende skalning. Ingress-bandbredd skalar med användare; egress-bandbredd skalar med intern-tjänstaktivitet. Uppgradera en utan att röra den andra.
4. Isolering vid fel. En felkonfigurerad egress påverkar inte längre den publika sidan. En DDoS mot den publika sidan påverkar inte längre egress-bandbredd.
5. Klartare mentalmodell. Varje maskin har en uppgift. Ingenjörer tänker på ingressbekymmer utan att tänka på egress, & vice versa.
Två axlar, två storleksbeslut
Oberoende skalning
Före delningen påverkades tillväxt i båda riktningarna samma maskin. Efter delningen har varje riktning sin egen provisionering.
Ingressstorlek: skalas med användare. Kapacitetsbeslut ligger i den offentligt framträdande skiktet (fler omvänd proxyreplicer, större VM:er, CDN framför). Bandbreddsbudget beräknas mot användartrafik under toppen.
Egressstorlek: skalas med intern tjänst-till-extern API-anrop. Ofta domineras av webhookleveranser, betalningsprocessoranslutningar eller hämtningar av tredjepartsdatabaser. Bandbreddsbudget beräknas mot interna anropsmönster.
Felsisolation: en DDoS mot den offentliga ingressen äter inte egressbandbredd (de betalningsprocessoranslutningarna går igenom i alla fall). En egressproxykrasch äter inte ner den offentliga sidan (användarna fortsätter att nå sidan; bara interna utgående anrop misslyckas).
Skilda SLOs: ingressföråtlighetsgrad är viktig för användare (synlig sidavbrott); egressföråtlighetsgrad är viktig för operatörer (bakgrundsmisslyckanden som kan ta längre tid att upptäcka). Varje sida kan bära sin egen SLO.
Flera egressserver
När egressrollen är sin egen maskin är nästa uppenbara drag att köra flera egressmaskiner bakom en lastbalanserare för HA. Varje ny intern tjänst anger egress-värdnamnet (vilket resolverar till poolen bakom lastbalanseraren) i stället för en enda IP.
Samma läxa som för resten av distribuerade system: när ett skikt blir stateless och har sin egen roll multipliceras det billigt.
En ny partners integrering
Ditt företag kör ingress / egress-delningen som designad. Egressservern har en fast offentlig IP (203.0.113.99) som du har allowlistat med tre befintliga partners API:er (en betalningsprocessor, en SMS-gateway och en e-postleverantör).
Ett produktteam vill lägga till en fjärde integrering: en webhook-leveranssystem som ringer tillbaka till kundens slutpunkter världen över. Volymprognos: 10 000 samtal per minut, med burst upp till 30 000.
Designa en nätgräns för ett växande service
Sammanfogning
Du har lärt dig varför ingress och egress kräver olika verktyg, den hairpin NAT-fel som tvingar uppdelningen i verkliga flottor, och hur självständigt skala, säkerhetsisolering och felisolering ackumuleras en gång splittras.
Använd alla fyra.
En mellanstor SaaS-företag kör tre produktunderdomäner (app, api, admin) för deras användare, plus fyra utgående integreringar (Stripe, Twilio, SendGrid, ett kund-webhook-system). Idag finns allt bakom en enda proxy-maskin vid en enda offentlig IP-adress. De har börjat få rapporter om intermittenta hairpin-fel när interna tjänster försöker anropa api.example.com. De vill designa en permanent lösning.
Vart denna kurs går vidare
Vart denna kurs går vidare
Du har nu sett en av de renaste separation-of-concerns refactor i distribuerade system: en skåp blir två, var och en med en tydlig roll, och systemet får skalfördelar, säkerhetsfördelar och isolering av felisolering.
Nästa lektion (cs_distsys_failure_modes_and_blast_radius) utvidgar isoleringsresonemanget. Du kommer att läsa en sanerad DNS-SERVFAIL-postmortem, identifiera mönstret för kaskaderande fel och skriva skuldfrisk handlingar som riktar system istället för människor.
Kompletterande lektion: geometry_of_ingress_egress_separation omformulerar skiljandet som ett bipartit graf och utforskar knutpunkter, nätverkspartitioner och vad grafteori säger om en nätverksgräns.
Bra jobbat. Vidare.