Två Trafikriktningar, En Box
Välkomna
De flesta arkitekturdiodagar visar trafik som går en enda väg: klient ovanför, server under, pil neråt. Verkligheten har trafik som går både upp och ner.
Ingress: Utomhusklienter når dina tjänster via denna väg. En reversproxy på kanten av ditt nätverk avslutar TLS, väger upp begäranden och enforcerar åtkomstpolicy.
Utskopning: Dina tjänster når utomhus-tjänster via denna väg. Anropa ett betalningsprocessors API, hämta en webhooks-mål, skicka en begäran till en partner. Ofta via en forwardproxy eller NAT-gateway med en tillåten lista.
Många arkitekturer börjar med en box som hanterar både inkommande och utgående trafik. Det fungerar tills den dagen det inte gör. Felsökningsläget är subtilt, upptäcks bara efter att tillräckliga interna tjänster finns, och läror det en viktig lektion om separation av bekymmer.
Efter detta lektion kommer du att förstå:
- Varför ingress & utskopning representerar grundläggande olika trafikmönster med olika skalningsaxlar & olika felmodus
- Hairpin NAT & varför en proxy som försöker ansluta till sig själv misslyckas
- Den arkitektoniska gaveln: en box blir två, och vad var och en sedan äger exklusivt
- Säkerhetsisoleringens vinster: varje sida kan stänga in sig till sina verkliga tillåtna parter
- Hur man identifierar när din enskildesign har överskridit tröskeln där splittring är nödvändig
Varför Riktningarna Kräver Skilda Verktyg
Två Skilda Arbetsbelastningar vid Samma Nätverksgräns
Ingress-trafikens egenskaper:
- Initierad av utomstående (internet i stort)
- Mängden skalas med ditt användarbasis
- TLS-avslutning, begäran vägning, begränsning per källa
- Försvar i djupet: DDoS, missbruk, skrapning
- Offentlig IP måste acceptera anslutningar från vem som helst
Utskopningens egenskaper:
- Initieras av dina egna tjänster (ett känt, litet uppsättning kunder)
- Mängden skalas med ditt service-to-service- & extern-API-anropsschema
- Klient-IP tillåtelse på avlägsna ändpunkter (du har en fast utgående IP som partners litar på)
- Försvar i djupet: datapåfyllning, komprometterade interna tjänster som ringer ut
- Bör avvisa anslutningar från någon annan än dina egna tjänster
Nyckens asymmetri: ingång accepterar trafik från världen; utgång accepterar trafik endast från dina 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 ingång) och bara från dina tjänster (för utgång). Brandväggsregler som uppfyller ett arbetar mot varandra.
Utvecklingsvägen: ett litet projekt kan dölja både bakom en och en tool eftersom volymen är liten och partner-IP-allowlist är kort. När projektet växer ökar spännvidden mellan de två rollerna och en dag tvingas splittras av en specifik felaktighet (hairpin NAT).
Felaktigheten som tvingar splittringen
En Desinficerad Utbrott Berättelse
Bilda er om en verklig arkitektonisk gavel som inträffar i produktionsflottorna. Namnen nedan har ändrats; formen är identisk med vad som träffar i det fria.
En organisation köper en enda proxy-server på 203.0.113.5. Den hanterar ingång (port 443 för användare) och utgång (port 1080 SOCKS5 för interna tjänster som ringer ut). Interna tjänster finns i privata undernät och dirigerar alla utgående trafik genom den SOCKS5-proxy på 203.0.113.5:1080.
En av tjänsterna som är värd bakom samma 203.0.113.5 är api.example.com. Offentlig DNS löser api.example.com till 203.0.113.5.
Nu behöver en annan intern tjänst anropa api.example.com. Dess utgående väg:
1. Intern tjänst löser api.example.com → 203.0.113.5
2. Intern tjänst skickar begäran genom SOCKS5 utgångsproxy 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åstexit & re-enter samma NAT, vilket de flesta nätverksstackarna avvisar. Proxy kan inte ansluta sig till sig själv via sin egen publika IP.
Det här är hålsnurr-NAT: en paket som går ut från NAT och behöver återinträda samma NAT för att nå destinationen. Utan specialstöd för hålsnurr i routningslagret faller paketet.
Varför Det Yttrar Sig Sent
Tidigt i projektets liv pratade alla interna tjänster antingen med andra interna tjänster via privat värdnamn (internal-api.local) eller kallade inte tillbaka till sina egna organisations publika tjänster. Hålsnurrsöden fanns enbart inte.
Då en ny funktion krävde att tjänst A skulle ringa api.example.com (ett publikt värdnamn) aktiverades hålsnurrsöden. Avvisat anslutning. Utbrott.
Lösningen lade locket på symptomet (tvingade resolvert att ge api.example.com's privata IP i stället för den publika). Rotorsaken: en enda box gjorde för många jobb.
Den Arkitektoniska Gaffeln
En Box blir Två
Den rena lösningen: skiljorna proxy i två maskiner.
Ingress-server (publikt IP 203.0.113.5):
- Caddy / omvänd proxy på portarna 80, 443
- Publika DNS-anteckningar pekar hit
- Här finns api.example.com, app.example.com, etc.
Egress-server (ett annat publikt 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 rutter alla utgående via denna adress
Vad det köper:
1. Hålsnurr löstes. En intern tjänst som ringer api.example.com rutter utgående via 203.0.113.99 (egress), som sedan kopplar normalt till 203.0.113.5 (ingress, ett annat IP). NAT-loopen försvinner eftersom de två IP:erna lever på olika maskiner.
2. Säkerhetsisolerad. Egress-servicens brandvägg kan stängas av för en liten uppsättning interna IP:er. Ingress-servicens brandvägg står öppen för världen. Två separata regeluppsättningar, var och en uttrycker en ren sida.
3. Oberoende skalbarhet. Ingress-bandbredd skalas med användare; egress-bandbredd skalas med inneservice-aktivitet. Uppgradera en utan att beröra den andra.
4. Isolerad felhantering. En felkonfigurerad egress gör inte längre bråkets offentliga plats. En DDoS mot den offentliga platsen riskerar inte att torka ut egress-bandbredd.
5. Klart förstånd om systemet. Varje maskin har en uppgift. Ingenjörer tänker på ingående- eller utgående problem utan tvärtom.
Två axlar, två storleksbeslut
Oberoende skalning
Innan splittringen växte i både riktningarna stressade samma maskin. Efter splittringen har varje riktning sin egen tilldelning.
Ingress storlek: skalas med användare. Kapacitetsbeslut ligger i det offentliga skiktet (fler omvänd proxyreplicer, större virtuella datorer, CDN framför). Bandbreddsbudget räknas ut mot användartrafik under toppen.
Egress storlek: skalas med intern tjänst- till extern API-anrop. Ofta domineras av webhooks, betalningsprocessoranrop eller upphämtande av tredjepartsdata. Bandbreddsbudget räknas ut mot interna anropssätt.
Isolering vid fel: en DDoS mot den offentliga ingressen äter inte längre egress-bandbredd (de betalningsprocessoranropen går igenom ändå). En egress-proxykrasch tar inte längre ner den offentliga sidan (användarna når fortfarande sidan; bara de interna utgående anropena blir påverkade).
Skilda SLOs: ingress-tillgänglighet är viktig för användare (synlig sidstorning); egress-tillgänglighet är viktig för operatörer (bakgrundsfel som kan ta längre tid att upptäcka). Varje sida kan bära sitt eget SLO.
Flera egress-servrar
När egress-rollen är sin egen maskin är nästa logiska steg att köra flera egress-maskiner bakom en lastbalanserare för HA. Varje ny intern tjänst anger egress-värdet (vilket löser till poolen av lastbalanserade servrar) i stället för en enda IP.
Samma lektion som för resten av distribuerade system: När ett skikt blir stateless och har sin egen roll multipliceras det billigt.
En ny partners integration
Ditt företag kör ingress / egress splittringen så som det är designat. Egress-servern har en fast offentlig IP (203.0.113.99) som du har allowlistat med tre befintliga partner-API:er (en betalningsprocessor, en SMS-gateway och en e-postleverantör).
Ett produktteam vill lägga till en fjärde integrering: en webhookleveranssystem som ringer tillbaka till kundens slutpunkter runt om i världen. Volymförväntning: 10 000 samtal per minut, med burst till 30 000.
Designa en nätgräns för ett växande system
Sammanfattning
Du har lärt dig varför ingress och egress kräver olika verktyg, att hairpin NAT-fel tvingar splittringen i verkliga flottar och hur oberoende skalning, säkerhetsisolering och felisolering förmåns får en gång splittras.
Använd alla fyra.
En mellstor SaaS-företag kör tre produktunderdomäner (app, api, admin) för sina användare, plus fyra utgående integreringar (Stripe, Twilio, SendGrid, ett kund-webhook-system). Idag finns allt bakom en enda proxy-dator vid en publik IP. De har börjat få rapporter om intermittenta hairpin-fel när interna tjänster försöker ringa till api.example.com. De vill designa en permanent lösning.
Vart denna kurs tar sig
Vart denna kurs tar sig
Du har nu sett en av de renaste separation-of-concerns-omorganiseringarna i distribuerade system: en box blir två, var och en med en tydlig roll, och systemet får förmåner i skalning, säkerhet och felisolering på vägen.
Nästa lektion (cs_distsys_failure_modes_and_blast_radius) förlänger felisoleringens resonemang. Du kommer att läsa en sanerad DNS-SERVFAIL-postmortem, identifiera det kaskaderande felet och skriva skuldlösa åtgärder som riktar system istället för människor.
Kompletterande lektion: geometry_of_ingress_egress_separation omformulerar splittringen som en bipartit graf och undersöker skiljeköer, nätverksdelningar och vad grafteori kan berätta om en nätverksgräns.
Mycket bra. Fört.