Applikationsgateways

En applikationsgateway sætter én offentlig adresse foran mange tjenester i din VPC og sender hver forespørgsel videre til den rigtige ud fra værtsnavn og URL-sti. Den terminerer TLS, kan kryptere trafikken om på vej til dine backends, og anvender en netværksfirewall — regler for kilde-CIDR, landeblokering og hastighedsgrænser — før en forespørgsel overhovedet når din applikation.

Den er en administreret appliance: en dedikeret instans i din egen VPC, med en størrelse, en version og sin egen post på din faktura.

Applikationsgateway eller lastbalancer?

Begge tager imod offentlig trafik. De svarer på forskellige spørgsmål.

	Lastbalancer	Applikationsgateway
Hvad den gør	Fordeler trafik over en pool af backends	Afgør hvor hver forespørgsel går hen, og om den må gå overhovedet
Routing	Én tjeneste per lytterport	Mange tjenester bag én adresse, ud fra vært og sti
Adresser der kræves	Én per lastbalancer	Én, til alle tjenesterne bag den
Regler per forespørgsel	—	Omskrivning af sti, indsættelse af headere, backends per rute
Beskyttelse	Tilladte CIDR'er på en lytter	CIDR-regler, landeblokering, hastighedsgrænser, forbindelseslofter

Kort fortalt: vil du fordele trafik, så brug en lastbalancer. Vil du styre den, så brug en applikationsgateway. De kan kombineres — en gateways backendpool kan pege på en lastbalancers adresse.

Opret en gateway

En gateway ligger i én VPC og ét subnet og har brug for en offentlig adresse. Lad enten platformen tildele en, eller tag en med, du allerede har.

# Adresse tildelt af platformen
fm appgw create --name edge --flavor agw.co1.medium \
  --vpc <vpc-id> --subnet <subnet-id>

# Tag din egen offentlige IP-adresse med
fm appgw create --name edge --flavor agw.co1.medium \
  --vpc <vpc-id> --subnet <subnet-id> \
  --public-ip-mode selected --public-ip <public-ip-id>

De to tilstande adskiller sig på én måde, der betyder noget senere: en adresse, som platformen har tildelt, frigives, når du sletter gatewayen; en adresse, du har taget med, gør det ikke. Den vender tilbage til dine offentlige IP-adresser og forbliver din.

Størrelser kommer fra kataloget:

fm appgw flavors

En størrelse beskriver, hvad appliancen bærer, ikke maskinen under den: angivet kapacitet, antallet af samtidige forbindelser, den holder, og hvor mange lyttere, ruter, backends og firewallregler den tager imod.

De fire grænser er hårde — at overskride en af dem afvises, den strubes ikke — så vælg en størrelse ud fra det regelsæt, du har tænkt dig at skrive, ikke kun ud fra trafikken. Antallet af forespørgsler per sekund er en angivet kapacitet frem for en garanti: hvad du faktisk får, afhænger af dine regler, dine TLS-indstillinger og dine backends.

Du vælger ingen appliance-version. Frostmoln styrer den: du forfatter ruter, backends og WAF-regler, aldrig datalagskonfigurationen under dem. Det versionsvalg, du faktisk styrer, er dit WAF-regelsæt, som har sine egne versioner, publicering og tilbagerulning.

I Terraform hedder ressourcen frostmoln_application_gateway, med frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_health_check og frostmoln_appgw_certificate under sig. En TCP-lytter er protocol = "tcp" med backend_pool_id og valgfrit port_range_end; PROXY-protokollet er proxy_protocol på poolen og på sundhedstjekket for dets sonderingsforbindelse.

Lyttere — hvor trafikken ankommer

En lytter binder en protokol og en port. HTTPS-lyttere terminerer TLS og har derfor brug for et certifikat.

fm appgw certificate upload --gateway <gw-id> --name example-com \
  --chain ./fullchain.pem --private-key ./privkey.pem

fm appgw listener create --gateway <gw-id> --name https \
  --protocol https --port 443 --certificate <certificate-id> \
  --tls-min-version 1.2 --tls-cipher-profile modern

Giv --private-key en sti, eller - for at læse fra standard input. At angive nøgleteksten direkte lægger den i din shell-historik og i proceslisten.

Serverer du flere værtsnavne fra én lytter? Tilføj flere certifikater med --sni-certificate (kan gentages); det rigtige vælges per forbindelse.

En almindelig HTTP-lytter kan ganske enkelt sende alle videre til HTTPS:

fm appgw listener create --gateway <gw-id> --name http \
  --protocol http --port 80 --redirect-to-https

TCP-lyttere — når trafikken ikke er HTTP

Noget af det, du har brug for at publicere, taler ikke HTTP: en mailserver, en MQTT-broker til en flåde af enheder, en databasereplika, en spilserver. En TCP-lytter bærer dem gennem gatewayen uden at læse dem.

fm appgw listener create --gateway <gw-id> --name smtp \
  --protocol tcp --port 25 --backend-pool <pool-id>

Den har en anden form end en HTTP-lytter, og forskellene er afvisninger, ikke udeladelser — platformen siger nej frem for at tage imod en indstilling og stille ignorere den:

• Den angiver én backendpool. En TCP-lytter har ingen ruter, fordi routing betyder at matche et værtsnavn, en sti eller en header, og intet af det findes i en strøm af byte. --backend-pool kræves her og afvises på en HTTP- eller HTTPS-lytter, hvor hver rute angiver sin egen pool.
• Den terminerer ingen TLS. Intet certifikat, ingen mindsteversion, ingen cipher-profil, ingen omdirigering til HTTPS. TLS forbliver ende til ende mellem klienten og din backend — hvilket ofte er hele pointen: gatewayen holder aldrig nøglematerialet for den tjeneste.
• Firewallen til webapplikationer gælder ikke for den. Firewallen inspicerer forespørgsler, og der er ingen. Et regelsæt kan ikke tilknyttes en TCP-lytter, og et, der er tilknyttet gatewayen, når den ikke.
• Poolen skal være en HTTP-pool, må ikke allerede modtage trafik fra en rute, og må ikke bruge cookiebaseret sessionsbinding — en cookie er en HTTP-header, som gatewayen ikke har nogen måde at sætte på i lag 4.

Alt andet ved politikkanten gælder uændret. Regler for kilde-CIDR, landeblokering, hastighedsgrænser, forbindelseslofter og sundhedstjek virker på samme måde, som de gør på en HTTPS-lytter:

fm appgw listener create --gateway <gw-id> --name smtp \
  --protocol tcp --port 25 --backend-pool <pool-id> \
  --allowed-cidr 203.0.113.0/24 \
  --rate-limit-rps 20 --rate-limit-burst 40 \
  --max-connections 2000

Det er grunden til at vælge en applikationsgateway frem for en lastbalancer til en tjeneste, der ikke er HTTP: du får stadig én adresse, ét sted hvor reglerne bor, og én ting at revidere.

På en TCP-lytter tæller hastighedsgrænserne FORBINDELSER, ikke forespørgsler

På HTTP og HTTPS tæller --rate-limit-rps og --rate-limit-burst forespørgsler. I lag 4 er der ingen forespørgsel at tælle, så de tæller forbindelser.

Hvor én forbindelse bærer en hel session — SMTP, IMAP, MQTT — er det samme tal en langt strammere grænse, end det ville være for en weblytter. Et tal, der er kopieret fra en HTTPS-lytter, vil strube en mailserver med flere størrelsesordener. Sæt det efter de forbindelser, du faktisk forventer.

Portintervaller

En TCP-lytter kan binde et interval af porte i stedet for én:

fm appgw listener create --gateway <gw-id> --name ftp-data \
  --protocol tcp --port 30000 --port-range-end 30099 \
  --backend-pool <pool-id>

Intervallet er inklusive, skal løbe opad fra --port og må højst spænde over 512 porte. Hver forbindelse videresendes til den samme port på din backend, som klienten forbandt sig til — 30000-30099 når 30000-30099 på dine servere. Det er det, der overhovedet får et passivt FTP-dataområde, eller en blok af porte per tjeneste, til at virke.

To ting følger af det:

• En pool bag en lytter med portinterval skal give sit sundhedstjek en port af sin egen. Dens backends kontaktes på den port, hver klient ankom på, så en sondering har ellers intet at ringe op. Se Sundhedstjek.
• To lyttere på én gateway må ikke overlappe i portrummet. En anden lytter, der gør krav på en port, en eksisterende binder, afvises, uanset om sammenstødet er mellem to enkeltporte eller to intervaller.

Nogle få porte er appliancens egne og afvises for alle protokoller. Bliver et interval afvist af den grund, navngiver meddelelsen porten — flyt intervallet, eller del det i to omkring den.

At slette en lytter lukker dens port med det samme

At oprette en lytter åbner dens port på gatewayens offentlige indgang, og at slette en lukker den — begge dele uden at vente på en anvendelse. At erstatte en levende TCP-tjeneste ved at slette lytteren og oprette en ny taber derfor trafik i hullet mellem de to kald. Opret erstatningen først, hvor du kan, og for at ændre en indstilling på poolen bag den: opdater poolen frem for at bygge nogen af dem om.

Beskyt en lytter

Dette gælder hver forespørgsel på lytteren, før routing:

fm appgw listener create --gateway <gw-id> --name https \
  --protocol https --port 443 --certificate <certificate-id> \
  --allowed-cidr 203.0.113.0/24 --allowed-cidr 198.51.100.0/24 \
  --geo-block-mode allow --geo-country SE --geo-country NO \
  --rate-limit-rps 50 --rate-limit-burst 100 \
  --max-connections 4000

--max-connections begrænses af din størrelse: en lytter, der beder om mere, end størrelsen er angivet til at holde, hæver appliancens egen grænse til det samme, hvilket er en måde at udtømme den på frem for en måde at få mere kapacitet på. Kontroller den angivne kapacitet med fm appgw flavors.

--allowed-cidr og --denied-cidr kan gentages. --geo-block-mode er off, allow (kun disse lande) eller deny (alle undtagen disse), med ISO-landekoder.

Backendpools og backends

En pool er en gruppe backends, som gatewayen videresender til, plus hvordan den vælger mellem dem, og hvordan den taler med dem.

fm appgw pool create --gateway <gw-id> --name app-pool \
  --protocol http --algorithm round_robin \
  --timeout-connect-ms 2000 --timeout-response-ms 30000

--algorithm er round_robin, least_connections eller source_ip. Til klæbrige sessioner bruger du --session-affinity cookie --session-cookie <name> eller --session-affinity source_ip.

For at kryptere trafikken om på vej til din applikation gør du poolen https og angiver, hvordan backendens certifikat skal kontrolleres:

fm appgw pool create --gateway <gw-id> --name secure-pool \
  --protocol https --tls-verify-backend \
  --tls-ca-certificate ./internal-ca.pem --tls-server-name app.internal

PROXY-protokol — at fortælle dine backends, hvem der ringer

En backend bag en TCP-lytter ser gatewayens adresse som klienten, ikke den virkelige. For en mailserver er det tæt på fatalt: spamvurdering, hastighedsbegrænsning, greylisting og misbrugslogger beregnes alle op mod én enkelt adresse, vores. Der er ingen X-Forwarded-For at falde tilbage på, fordi det er en HTTP-header, og en TCP-lytter bærer ingen HTTP.

PROXY-protokollet sætter den virkelige klientadresse forrest i hver forbindelse:

fm appgw pool create --gateway <gw-id> --name mail-pool \
  --protocol http --proxy-protocol

Konfigurer FØRST backenden til at læse headeren

At slå dette til ændrer de byte, din backend modtager. En server, der ikke forventer headeren, læser den som de første byte i din protokol, og hver forbindelse mislykkes.

Rækkefølgen betyder noget, begge veje:

1. Konfigurer backenden til at tage imod PROXY-protokollet fra gatewayen — i Postfix er det smtpd_upstream_proxy_protocol, i nginx proxy_protocol på listen-linjen, i Dovecot indstillingen, der angiver, hvilke upstreams der må sende det.
2. Slå det til her.
3. Anvend gatewaykonfigurationen.

At slå det fra igen er den samme ændring i omvendt rækkefølge: fjern indstillingen på gatewayen og anvend, og lad derefter backenden holde op med at forvente den.

Det er slået fra som standard og forbliver slået fra, indtil du beder om det.

Ændr en pool uden at bygge den om

Alt på en pool undtagen dens navn kan ændres på stedet:

fm appgw pool update <pool-id> --gateway <gw-id> --proxy-protocol
fm appgw pool update <pool-id> --gateway <gw-id> \
  --algorithm least_connections --timeout-response-ms 60000

En indstilling, du ikke nævner, lades urørt, og ændringen træder i kraft ved næste anvendelse ligesom alt andet i gatewaykonfigurationen.

Det er sådan, PROXY-protokollet slås til for en pool, der allerede findes. Uden det ville den eneste vej være at slette poolen — hvilket først betyder at slette den TCP-lytter, der holder den, og lukke den offentlige port i samme øjeblik du gør det — og bygge dem begge igen: et nedbrud for at ændre én indstilling, hvis hele formål er at blive ændret, når backenden har lært at læse headeren.

To ændringer afvises, mens en TCP-lytter videresender til poolen, af de samme grunde, som de afvises, når den lytter oprettes: cookie som sessionsbinding er en HTTP-cookie, som gatewayen ikke kan sætte i lag 4, og https som poolprotokol ville kryptere byte om, der allerede er præcis det, klienten sendte.

Backends angives med IP-adresse inde i gatewayens VPC og en port:

fm appgw backend add --gateway <gw-id> --pool <pool-id> \
  --address 10.0.1.10 --port 8080 --weight 1

En adresse uden for gatewayens egen VPC afvises. Det er med vilje: uden den ville gatewayen videresende hvorhen som helst, du angav.

Sundhedstjek

En pool uden et sundhedstjek sender trafik til backends, der er nede.

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --expected-status 200-299 \
  --interval 10 --timeout 5 --healthy-threshold 2 --unhealthy-threshold 3

--timeout skal være kortere end --interval.

--protocol tcp åbner en forbindelse til porten og lukker den igen. Den sender ingen forespørgsel og sammenligner ingen status, så --path og --expected-status gælder ikke og afvises på den. Brug den til alt, der ikke svarer med HTTP.

health-check set ERSTATTER tjekket — det flettes ikke ind i det

Kommandoen angiver hele tjekket. En indstilling, du udelader, bliver ikke stående, som den var: den vender tilbage til platformens standard. --port går tilbage til at sondere hver backends egen port, og --proxy-protocol går tilbage til fra.

At justere ét tal betyder altså, at du angiver resten på ny. Et tjek, der sonderer 8080 med PROXY-protokollet slået til, sat på ny med kun --protocol, --path og --interval, mister stille og roligt begge dele — og en sondering, der holder op med at sende headeren til en port, der kræver den, mislykkes hver gang og markerer hver backend i poolen som usund, mens backendsene har det fint. Se PROXY-protokol på sonderingen.

Læs tjekket med fm appgw health-check get først, og send tilbage, hvad det havde. For slet ikke at have noget tjek bruger du health-check delete frem for et tomt set.

Sondering af en anden port

Som standard ringer sonderingen op til hver backends egen port. --port sender den et andet sted hen:

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --port 8080

To tilfælde vil have dette. Det første er en tjeneste, hvis sundhedsendepunkt ligger et andet sted — en mailserver, der svarer SMTP på 25 med et lille HTTP-sundhedsendepunkt på 8080. Uden det er den eneste tilgængelige sondering "åbn en forbindelse til 25", hvilket en belastet mailserver vil tage imod og derefter udsætte, så backenden læses som sund, mens den afviser hver eneste besked.

Det andet er ikke valgfrit: en pool bag en TCP-lytter med portinterval skal sætte --port. Dens backends kontaktes på den port, hver klient ankom på, så der er ingen fast port for en sondering at nå, og et tjek uden en sådan afvises.

PROXY-protokol på sonderingen

En pool, der sender PROXY-protokollet, kan lade sit sundhedstjek sende det på sonderingsforbindelsen også:

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --port 8080 --proxy-protocol

Om du vil have det, afhænger af, hvilken port sonderingen ringer op til, og kun du ved svaret. En sonderingsport findes netop for at nå en anden tjeneste end den, der bærer trafikken — en mailserver, der svarer SMTP på 25 med et lille sundhedsendepunkt på 8080 — og et sådant sundhedsendepunkt har sjældent nogen grund til at tale PROXY-protokollet. Det almindelige tilfælde vil ikke have headeren.

Sender du den til en port, der ikke forventer den, læser den port headeren som de første byte i din protokol. Sonderingen mislykkes, og en mislykket sondering markerer hver backend i poolen som usund, mens backendsene selv har det fint — poolen svarer 503 for servere, der fungerer helt fint. Som resten af gatewayens konfiguration sker det ved næste anvendelse, ikke når du sætter det.

Fra betyder IKKE "sonderingen sender ingen header"

En sondering uden sin egen --port ringer op til hver backends egen adresse og port, så den arver poolens forbindelsesindstillinger — PROXY-protokollet iblandt. En sådan sondering bærer allerede headeren, hver gang poolens eget PROXY-protokol er slået til, med denne indstilling slået fra.

At give sonderingen en --port fravælger de indstillinger og tager headeren med sig. Denne indstilling er den måde, du sætter den tilbage på.

fm appgw health-check get rapporterer de to sammen netop af den grund: uden en sonderingsport lyder rækken PROXY protocol on probe no (the probe follows the pool's setting) frem for et blankt nej.

Poolens eget PROXY-protokol skal være slået til først. At slå det til for sonderingen i en pool, der ikke sender nogen header, afvises — der ville ikke være nogen header at sende. Det omvendte afvises også: at slå poolens fra afvises, så længe sonderingen stadig sender den. Rækkefølgen er poolen til, derefter sonderingen til, og sonderingen fra, derefter poolen fra.

At slå det til, mens sonderingen ikke har nogen port af sin egen, accepteres og gemmes og ændrer intet — den sondering arver allerede poolens indstilling. Det begynder at betyde noget i samme øjeblik, sonderingen angiver en port.

I portalen er det en kontakt i poolens sundhedstjekpanel. I Terraform er det proxy_protocol på frostmoln_appgw_health_check, hvor rækkefølgen ovenfor har endnu en konsekvens: en enkelt terraform apply, der slår både denne og poolens fra, mislykkes på poolen, fordi Terraform opdaterer poolen før det tjek, der refererer til den. Slå sonderingens fra i én anvendelse og poolens i en senere.

Fjernelse af et sundhedstjek

fm appgw health-check delete --gateway <gw-id> --pool <pool-id>

Fra den næste anvendelse holder gatewayen op med at sondere denne pool og behandler hver aktiveret backend som tilgængelig.

Det er det rigtige svar, når backendsene selv afgør deres tilgængelighed — en overvåget tjeneste, eller en der sidder bag sin egen lastbalancer — og en sondering fra gatewayen kun ville tilføje endnu en holdning. Til alt andet: behold et tjek. Uden et sådant bliver en backend, der er holdt op med at svare, ved med at få sin del af trafikken.

Hvad gatewayen har observeret

fm appgw backend list og portalen viser begge en status per backend, med tidspunktet for hvornår den sidst blev observeret.

Backendsundhed rapporteres ikke endnu

Den rapportering, der udfylder dette, er stadig under opbygning, så hver backend læses lige nu som ikke observeret, uanset dens virkelige tilstand. Det er en udtalelse om vores rapportering, ikke om dine servere — en uobserveret backend er hverken sund eller usund, så vidt platformen ved, og intet holdes tilbage fra trafik på grund af det. Denne side siger til, når det ændrer sig.

Godkend hver backend — dette trin er ikke valgfrit

At tilføje en backend fortæller gatewayen, hvor den skal videresende til. Det giver den ikke tilladelse til at komme derhen: dine backends' sikkerhedsgrupper afgør det, og gatewayen er ikke i dem.

Godkend den udtrykkeligt:

fm appgw backend authorize --gateway <gw-id> --pool <pool-id> \
  --backend <backend-id> --security-group <security-group-id>

Dette tilføjer én ingress-regel til din sikkerhedsgruppe, der lukker gatewayen ind på den port. Intet åbnes for dig — platformen redigerer ikke dine sikkerhedsgrupper i stilhed.

To følger er værd at kende:

• Springer du det over, svarer din første gateway 503, fordi forbindelsen til backenden nægtes.
• Reglen er delt. Den skrives per sikkerhedsgruppe, protokol og port, så hver backend bag den gruppe på den port kan nås gennem den — og at tilbagekalde den lukker vejen for dem alle sammen, ikke kun den, du nævnte.

fm appgw authorization list --gateway <gw-id>
fm appgw authorization revoke --gateway <gw-id> <authorization-id>

Ruter — hvilken tjeneste der svarer

En rute matcher et værtsnavn og en sti på en lytter og videresender til en pool.

fm appgw route create --gateway <gw-id> --listener <listener-id> \
  --name api --host api.example.com --path /v1 --match-type prefix \
  --pool <pool-id>

--match-type er prefix, exact eller regex. --host tager imod et jokertegn (*.example.com).

Ruter evalueres efter prioritet, laveste først — et udtrykkeligt tal, aldrig gættet ud fra, hvor specifik stien ser ud. En ny rute havner sidst, medmindre du siger andet. Ændr rækkefølgen uden at oprette noget på ny:

fm appgw route reorder --gateway <gw-id> --listener <listener-id> \
  --route <route-id>=10 --route <other-route-id>=20

At prioriteten er udtrykkelig, er det, der forhindrer, at én tilføjet rute i stilhed ændrer, hvor eksisterende trafik går hen.

En rute kan også skrive forespørgslen om, før den videresendes:

fm appgw route create --gateway <gw-id> --listener <listener-id> \
  --name legacy --host example.com --path /old --match-type prefix \
  --pool <pool-id> --rewrite-path-prefix /new \
  --set-header X-Tenant=acme --remove-header X-Debug \
  --set-response-header Strict-Transport-Security="max-age=31536000"

Anvend — intet er live, før du gør det

Lyttere, ruter, pools, backends og certifikater er forfattede. De gemmes, så snart du skriver dem, og gatewayen bliver ved med at servere det, den allerede havde, indtil du anvender:

fm appgw apply <gateway-id>

Gatewayen validerer den nye konfiguration, skifter til den, genindlæser og kontrollerer sig selv, før den rapporterer tilbage. Mislykkes noget af det, gendanner den det, den serverede, og fortæller dig hvorfor — en dårlig konfiguration tager ikke dit websted ned for nogen.

fm appgw get <gateway-id> viser, om det, du har forfattet, er det, der kører. Portalen viser det samme som et banner, og begge gengiver appliancens egen begrundelse, når en anvendelse afvises.

Anvendelse kræver, at gatewayen er running, og der kører kun én anvendelse ad gangen.

Firewall til webapplikationer

Hver applikationsgateway inkluderer en firewall til webapplikationer uden ekstra omkostning — der er intet separat produkt at købe og intet tilvalg at aktivere. Regler forfattes per gateway, oven på en vedligeholdt baseline, som Frostmoln holder aktuel.

Ikke tilgængelig endnu

At forfatte regler er endnu ikke åbent for kunder. Denne side dokumenterer det, når det er; intet i din gateways konfiguration ændrer sig i mellemtiden.

Sletning af en gateway

fm appgw delete <gateway-id>

Trafikken stopper med det samme. Om den offentlige adresse overlever, afhænger af, hvordan gatewayen fik den: en adresse, platformen tildelte, frigives, og en adresse, du tog med, beholdes og vender tilbage til dine offentlige IP-adresser.

Fakturering

En applikationsgateway faktureres per time ud fra sin størrelse, som enhver anden administreret instans, og firewallen til webapplikationer er inkluderet i den pris. Hvis gatewayens offentlige adresse blev tildelt af platformen, faktureres den som en offentlig IP-adresse, separat og kun én gang; en adresse, du allerede har, står allerede på din faktura og faktureres ikke to gange.

Tilgængelighed

En standardapplikationsgateway er en enkelt administreret appliance. Går dens vært ned, bygges den op igen, hvilket ikke sker med det samme. Planlæg for det, som du ville gøre for enhver enkelt instans — og er en kort afbrydelse uacceptabel for den trafik, du sætter den foran, så sig det, før du lægger produktion bag en.