Applikationsgatewayer

En applikationsgateway sätter en enda publik adress framför många tjänster i ditt VPC och skickar varje förfrågan vidare till rätt tjänst utifrån värdnamn och URL-sökväg. Den terminerar TLS, kan kryptera om trafiken på väg till dina backends, och tillämpar en nätverksbrandvägg — regler för käll-CIDR, blockering per land och hastighetsbegränsning — innan en förfrågan ens når din applikation.

Den är en hanterad appliance: en dedikerad instans i ditt eget VPC, med en storlek, en version och en egen post på din faktura.

Applikationsgateway eller lastbalanserare?

Båda tar emot publik trafik. De svarar på olika frågor.

	Lastbalanserare	Applikationsgateway
Vad den gör	Fördelar trafik över en pool av backends	Avgör vart varje förfrågan går, och om den alls får gå
Routing	En tjänst per lyssnarport	Många tjänster bakom en adress, per värdnamn och sökväg
Adresser som krävs	En per lastbalanserare	En, för alla tjänster bakom den
Regler per förfrågan	—	Omskrivning av sökväg, headers, backend per rutt
Skydd	Tillåtna CIDR på en lyssnare	CIDR-regler, landsblockering, hastighetsgränser, anslutningstak

Kort sagt: vill du fördela trafik, använd en lastbalanserare. Vill du styra den, använd en applikationsgateway. De går att kombinera — en gatewaypool kan peka på en lastbalanserares adress.

Skapa en gateway

En gateway ligger i ett VPC och ett subnät, och behöver en publik adress. Låt antingen plattformen tilldela en, eller ta med en du redan har.

# Adress tilldelad av plattformen
fm appgw create --name edge --flavor agw.co1.medium \
  --vpc <vpc-id> --subnet <subnet-id>

# Ta med en egen publik IP
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 två lägena skiljer sig på ett sätt som spelar roll senare: en adress som plattformen tilldelat frigörs när du tar bort gatewayen; en adress du tagit med gör det inte. Den återgår till dina publika IP-adresser och förblir din.

Storlekar kommer från katalogen:

fm appgw flavors

En storlek beskriver vad applianceen klarar, inte maskinen under den: angiven kapacitet, antalet samtidiga anslutningar den håller, och hur många lyssnare, rutter, backends och brandväggsregler den tar emot.

De fyra gränserna är hårda — att överskrida en av dem avvisas, den stryps inte — så välj storlek utifrån det regelverk du tänker skriva, inte bara utifrån trafiken. Antalet förfrågningar per sekund är en angiven kapacitet, inte en garanti: vad du faktiskt får beror på dina regler, dina TLS-inställningar och dina backends.

Du väljer ingen appliance-version. Frostmoln sköter den: du skapar rutter, backends och WAF-regler, aldrig datalagerkonfigurationen under dem. Det versionsval du styr är ditt WAF-regelverk, som har egna versioner, publicering och återställning.

I Terraform heter resursen frostmoln_application_gateway, med frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_health_check och frostmoln_appgw_certificate under sig. En TCP-lyssnare är protocol = "tcp" med backend_pool_id, och valfritt port_range_end; PROXY-protokollet är proxy_protocol på poolen, och på hälsokontrollen för dess sonderingsanslutning.

Lyssnare — där trafiken kommer in

En lyssnare binder ett protokoll och en port. HTTPS-lyssnare terminerar TLS och behöver därför ett 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

Ge --private-key en sökväg, eller - för att läsa från standard input. Att skicka nyckeltexten direkt lägger den i din shell-historik och i processlistan.

Serverar du flera värdnamn från en lyssnare? Lägg till fler certifikat med --sni-certificate (kan upprepas); rätt certifikat väljs per anslutning.

En vanlig HTTP-lyssnare kan helt enkelt skicka alla vidare till HTTPS:

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

TCP-lyssnare — när trafiken inte är HTTP

En del av det du behöver publicera talar inte HTTP: en e-postserver, en MQTT-mäklare för en flotta enheter, en databasreplika, en spelserver. En TCP-lyssnare bär dem genom gatewayen utan att läsa dem.

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

Den har en annan form än en HTTP-lyssnare, och skillnaderna är avslag, inte utelämnanden — plattformen säger nej i stället för att ta emot en inställning och tyst ignorera den:

• Den anger en backendpool. En TCP-lyssnare har inga rutter, eftersom ruttning betyder att matcha ett värdnamn, en sökväg eller ett huvud, och inget av det finns i en ström av byte. --backend-pool krävs här, och avvisas på en HTTP- eller HTTPS-lyssnare där varje rutt anger sin egen pool.
• Den terminerar ingen TLS. Inget certifikat, ingen lägsta version, ingen cipherprofil, ingen omdirigering till HTTPS. TLS förblir ände till ände mellan klienten och din backend — vilket ofta är hela poängen: gatewayen håller aldrig nyckelmaterialet för den tjänsten.
• Brandväggen för webbapplikationer gäller inte för den. Brandväggen inspekterar förfrågningar, och det finns inga. En regeluppsättning kan inte kopplas till en TCP-lyssnare, och en som är kopplad till gatewayen når den inte.
• Poolen måste vara en HTTP-pool, får inte redan ta emot trafik från en rutt, och får inte använda cookie-baserad sessionsbindning — en cookie är ett HTTP-huvud som gatewayen inte kan sätta på lager 4.

Allt annat i skyddet gäller oförändrat. Källadressregler, landsblockering, hastighetsgränser, anslutningstak och hälsokontroller fungerar likadant som på en HTTPS-lyssnare:

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 är skälet att välja en applikationsgateway framför en lastbalanserare för en tjänst som inte är HTTP: du får fortfarande en adress, ett ställe där reglerna bor och en sak att granska.

På en TCP-lyssnare räknar gränserna ANSLUTNINGAR, inte förfrågningar

På HTTP och HTTPS räknar --rate-limit-rps och --rate-limit-burst förfrågningar. På lager 4 finns ingen förfrågan att räkna, så de räknar anslutningar.

Där en anslutning bär en hel session — SMTP, IMAP, MQTT — är samma siffra en långt hårdare gräns än den vore för en webblyssnare. En siffra som kopierats från en HTTPS-lyssnare strypar en e-postserver med flera storleksordningar. Sätt den efter de anslutningar du faktiskt förväntar dig.

Portintervall

En TCP-lyssnare kan binda ett intervall av portar i stället för en:

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

Intervallet är inklusive, måste räknas uppåt från --port och får omfatta högst 512 portar. Varje anslutning vidarebefordras till samma port på din backend som klienten anslöt till — 30000-30099 når 30000-30099 på dina servrar. Det är vad som över huvud taget får ett passivt FTP-dataintervall, eller ett block av portar per tjänst, att fungera.

Två saker följer av det:

• En pool bakom en intervallyssnare måste ge sin hälsokontroll en egen port. Dess backends nås på den port varje klient kom in på, så en sondering har annars ingenting att ringa upp. Se Hälsokontroller.
• Två lyssnare på samma gateway får inte överlappa i portrymden. En andra lyssnare som gör anspråk på någon port en befintlig binder avvisas, oavsett om krocken är mellan två enskilda portar eller två intervall.

Några portar är appliancens egna och avvisas för alla protokoll. Om ett intervall avvisas av det skälet namnger meddelandet porten — flytta intervallet eller dela det i två runt den.

Att ta bort en lyssnare stänger dess port omedelbart

Att skapa en lyssnare öppnar dess port i gatewayens publika ingång, och att ta bort en stänger den — båda utan att vänta på en verkställning. Att ersätta en levande TCP-tjänst genom att ta bort lyssnaren och skapa en ny tappar därför trafik under glappet mellan de två anropen. Skapa ersättaren först där du kan, och för att ändra en inställning på poolen bakom den: uppdatera poolen i stället för att bygga om något av dem.

Skydda en lyssnare

Det här gäller varje förfrågan på lyssnaren, före 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änsas av din storlek: en lyssnare som begär mer än storleken är angiven att klara höjer appliancens egen gräns till samma värde, vilket är ett sätt att överbelasta den snarare än att få mer kapacitet. Kontrollera värdet med fm appgw flavors.

--allowed-cidr och --denied-cidr kan upprepas. --geo-block-mode är off, allow (bara dessa länder) eller deny (alla utom dessa), med ISO-landskoder.

Backendpooler och backends

En pool är en grupp backends som gatewayen skickar vidare till, plus hur den väljer mellan dem och hur den pratar 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 är round_robin, least_connections eller source_ip. För klibbiga sessioner, använd --session-affinity cookie --session-cookie <namn> eller --session-affinity source_ip.

För att kryptera om trafiken på väg till din applikation, gör poolen https och ange hur backendens certifikat ska kontrolleras:

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-protokoll — att tala om för dina backends vem som ringer

En backend bakom en TCP-lyssnare ser gatewayens adress som klient, inte den verkliga. För en e-postserver är det nästan förödande: skräppostbedömning, hastighetsbegränsning, greylisting och missbruksloggar beräknas alla mot en enda adress, vår. Det finns inget X-Forwarded-For att falla tillbaka på, eftersom det är ett HTTP-huvud och en TCP-lyssnare bär ingen HTTP.

PROXY-protokollet sätter den verkliga klientadressen först i varje anslutning:

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

Ställ FÖRST in backenden att läsa huvudet

Att slå på detta ändrar de byte din backend tar emot. En server som inte väntar sig huvudet läser det som de första byten i ditt protokoll, och varje anslutning misslyckas.

Ordningen spelar roll, åt båda hållen:

1. Ställ in backenden att ta emot PROXY-protokollet från gatewayen — i Postfix är det smtpd_upstream_proxy_protocol, i nginx proxy_protocol på listen-raden, i Dovecot inställningen som anger vilka uppströms som får skicka det.
2. Slå på det här.
3. Verkställ gatewaykonfigurationen.

Att slå av det igen är samma förändring i omvänd ordning: ta bort inställningen på gatewayen och verkställ, sluta sedan låta backenden vänta sig det.

Det är avstängt som standard och förblir avstängt tills du ber om det.

Att ändra en pool utan att bygga om den

Allt på en pool utom namnet kan ändras på plats:

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 inställning du inte namnger lämnas orörd, och ändringen träder i kraft vid nästa verkställning som all annan gatewaykonfiguration.

Det är så PROXY-protokollet slås på för en pool som redan finns. Utan det vore enda vägen att ta bort poolen — vilket först betyder att ta bort TCP-lyssnaren som håller den, och stänga den publika porten i samma stund — och bygga båda igen: ett avbrott för att ändra en inställning vars hela syfte är att ändras när backenden väl har lärt sig läsa huvudet.

Två ändringar avvisas medan en TCP-lyssnare vidarebefordrar till poolen, av samma skäl som de avvisas när den lyssnaren skapas: cookie som sessionsbindning är en HTTP-cookie som gatewayen inte kan sätta på lager 4, och https som poolprotokoll skulle kryptera om byte som redan är vad klienten skickade.

Backends anges med IP-adress inuti gatewayens VPC, och en port:

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

En adress utanför gatewayens eget VPC avvisas. Det är avsiktligt: utan den regeln skulle gatewayen skicka trafik vart du än pekade den.

Hälsokontroller

En pool utan hälsokontroll skickar trafik till backends som är nere.

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 måste vara kortare än --interval.

--protocol tcp öppnar en anslutning till porten och stänger den igen. Den skickar ingen förfrågan och jämför ingen status, så --path och --expected-status gäller inte och avvisas på den. Använd den för allt som inte svarar med HTTP.

health-check set ERSÄTTER kontrollen — den slås inte ihop med den

Kommandot anger hela kontrollen. En inställning du utelämnar står inte kvar som den var: den återgår till plattformens standard. --port går tillbaka till att sondera varje backends egen port, och --proxy-protocol går tillbaka till avstängt.

Att justera om ett enda värde betyder alltså att du anger resten på nytt. En kontroll som sonderar 8080 med PROXY-protokollet påslaget, omställd med bara --protocol, --path och --interval, tappar tyst båda — och en sondering som slutar skicka huvudet till en port som kräver det misslyckas varje gång, och markerar varje backend i poolen som sjuk fastän backendsen mår bra. Se PROXY-protokoll på sonderingen.

Läs kontrollen med fm appgw health-check get först och skicka tillbaka det den hade. För att inte ha någon kontroll alls, använd health-check delete snarare än ett tomt set.

Att sondera en annan port

Som standard ringer sonderingen upp varje backends egen port. --port skickar den någon annanstans:

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

Två fall vill ha detta. Det första är en tjänst vars hälsoslutpunkt ligger någon annanstans — en e-postserver som svarar SMTP på 25 med en liten HTTP-hälsoslutpunkt på 8080. Utan det är enda tillgängliga sonderingen "öppna en anslutning till 25", vilket en belastad e-postserver tar emot och sedan skjuter upp, så backenden läses som frisk medan den avvisar varje meddelande.

Det andra är inte valfritt: en pool bakom en TCP-lyssnare med portintervall måste sätta --port. Dess backends nås på den port varje klient kom in på, så det finns ingen fast port för en sondering att nå, och en kontroll utan port avvisas.

PROXY-protokoll på sonderingen

En pool som skickar PROXY-protokollet kan låta sin hälsokontroll skicka det på sonderingsanslutningen också:

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

Om du vill ha det beror på vilken port sonderingen ringer upp, och bara du vet svaret. En sonderingsport finns just för att nå en annan tjänst än den som bär trafiken — en e-postserver som svarar SMTP på 25 med en liten HTTP-hälsoslutpunkt på 8080 — och en sådan hälsoslutpunkt har sällan någon anledning att tala PROXY-protokollet. Det vanliga fallet vill inte ha huvudet.

Skickar du det till en port som inte väntar sig det läser den porten huvudet som de första byten i ditt protokoll. Sonderingen misslyckas, och en misslyckad sondering markerar varje backend i poolen som sjuk fastän backendsen själva mår bra — poolen svarar 503 för servrar som fungerar utmärkt. Som resten av gatewayens konfiguration sker det vid nästa verkställning, inte när du ställer in det.

Avstängt betyder INTE "sonderingen skickar inget huvud"

En sondering utan egen --port ringer upp varje backends egen adress och port, så den ärver poolens anslutningsinställningar — PROXY-protokollet bland dem. En sådan sondering bär redan huvudet så snart poolens eget PROXY-protokoll är påslaget, med den här inställningen avstängd.

Att ge sonderingen en --port väljer bort de inställningarna, och tar huvudet med sig. Den här inställningen är hur du sätter tillbaka det.

fm appgw health-check get visar de två tillsammans just därför: utan sonderingsport lyder raden PROXY protocol on probe no (the probe follows the pool's setting) i stället för ett blankt nej.

Poolens eget PROXY-protokoll måste vara påslaget först. Att slå på det för sonderingen i en pool som inte skickar något huvud avvisas — det finns inget huvud att skicka. Det omvända avvisas också: att slå av poolens avvisas så länge sonderingen fortfarande skickar det. Ordningen är poolen på, sedan sonderingen, och sonderingen av, sedan poolen.

Att slå på det medan sonderingen saknar egen port tas emot och lagras, och ändrar ingenting — den sonderingen ärver redan poolens inställning. Det börjar betyda något i samma stund som sonderingen anger en port.

I portalen är det en växlare i poolens hälsokontrollpanel. I Terraform är det proxy_protocol på frostmoln_appgw_health_check, där ordningen ovan får en följd till: en enda terraform apply som slår av både den här och poolens misslyckas på poolen, eftersom Terraform uppdaterar poolen före kontrollen som refererar till den. Slå av sonderingens i en verkställning och poolens i en senare.

Att ta bort en hälsokontroll

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

Från och med nästa verkställning slutar gatewayen sondera den här poolen och behandlar varje aktiverad backend som tillgänglig.

Det är rätt svar när backendsen själva avgör sin tillgänglighet — en övervakad tjänst, eller en som sitter bakom sin egen lastbalanserare — och en sondering från gatewayen bara skulle lägga till en andra åsikt. För allt annat: behåll en kontroll. Utan den fortsätter en backend som slutat svara att få sin del av trafiken.

Vad gatewayen har observerat

fm appgw backend list och portalen visar båda en status per backend, med tidpunkten då den senast observerades.

Backendhälsa rapporteras inte ännu

Rapporteringen som fyller i detta byggs fortfarande, så varje backend visas just nu som ej observerad, oavsett verkligt tillstånd. Det är ett påstående om vår rapportering, inte om dina servrar — en icke observerad backend är varken frisk eller sjuk så vitt plattformen vet, och ingenting undanhålls trafik på grund av det. Den här sidan säger till när det ändras.

Godkänn varje backend — det steget är inte valfritt

Att lägga till en backend talar om för gatewayen vart den ska skicka trafiken. Det ger den inte tillstånd att ta sig dit: dina backends säkerhetsgrupper avgör det, och gatewayen finns inte i dem.

Godkänn den uttryckligen:

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

Det lägger till en ingress-regel i din säkerhetsgrupp som släpper in gatewayen på den porten. Ingenting öppnas åt dig — plattformen ändrar inte dina säkerhetsgrupper i tysthet.

Två följder värda att känna till:

• Hoppar du över det svarar din första gateway 503, eftersom anslutningen till backenden nekas.
• Regeln är delad. Den skrivs per säkerhetsgrupp, protokoll och port, så varje backend bakom den gruppen på den porten nås genom den — och att återkalla den stänger vägen för allihop, inte bara den du namngav.

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

Rutter — vilken tjänst som svarar

En rutt matchar ett värdnamn och en sökväg på en lyssnare och skickar vidare till 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 är prefix, exact eller regex. --host tar emot ett jokertecken (*.example.com).

Rutter utvärderas efter prioritet, lägst först — ett uttryckligt tal, aldrig gissat utifrån hur specifik sökvägen ser ut. En ny rutt hamnar sist om du inte säger något annat. Ändra ordning utan att skapa om något:

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

Att prioriteten är uttrycklig är det som hindrar att en ny rutt i tysthet ändrar vart befintlig trafik går.

En rutt kan också skriva om förfrågan innan den skickas vidare:

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"

Verkställ — ingenting är live förrän du gör det

Lyssnare, rutter, pooler, backends och certifikat är författade. De sparas så fort du skriver dem, och gatewayen fortsätter servera det den redan hade tills du verkställer:

fm appgw apply <gateway-id>

Gatewayen validerar den nya konfigurationen, byter till den, laddar om och kontrollerar sig själv innan den rapporterar tillbaka. Misslyckas något av det återställer den det den serverade och berättar varför — en trasig konfiguration tar inte ner din sajt för någon.

fm appgw get <gateway-id> visar om det du författat är det som körs. Portalen visar samma sak som en banner, och båda återger appliancens egna ord när en verkställning nekas.

Verkställning kräver att gatewayen är running, och bara en verkställning körs åt gången.

Brandvägg för webbapplikationer

Varje applikationsgateway inkluderar en brandvägg för webbapplikationer, utan extra kostnad — det finns ingen separat produkt att köpa och inget tillägg att aktivera. Regler författas per gateway, ovanpå en underhållen baslinje som Frostmoln håller aktuell.

Inte tillgängligt ännu

Att författa regler är ännu inte öppet för kunder. Den här sidan dokumenterar det när det är; ingenting i din gateways konfiguration ändras under tiden.

Ta bort en gateway

fm appgw delete <gateway-id>

Trafiken upphör omedelbart. Om den publika adressen överlever beror på hur gatewayen fick den: en adress plattformen tilldelat frigörs, och en adress du tagit med behålls och återgår till dina publika IP-adresser.

Fakturering

En applikationsgateway faktureras per timme utifrån sin storlek, som vilken annan hanterad instans som helst, och brandväggen för webbapplikationer ingår i det priset. Om gatewayens publika adress tilldelades av plattformen faktureras den som en publik IP, separat och bara en gång; en adress du redan har ligger redan på din faktura och faktureras inte två gånger.

Tillgänglighet

En standardapplikationsgateway är en enda hanterad appliance. Om dess värd går ner byggs den om, vilket inte sker omedelbart. Planera för det som du skulle göra för vilken enskild instans som helst — och om ett kort avbrott är oacceptabelt för trafiken du sätter den framför, säg det innan du lägger produktion bakom en.