Skip to content

Gateway

En Gateway är en VPC:s förbindelse med internet. Den är en egen resurs, inte en inställning på VPC:n: en VPC har högst en, och en VPC utan någon har ingen väg till internet alls.

Den bär båda riktningarna. Trafik från instanser som saknar egen publik IP går ut via gatewayens källadress, och trafik som är adresserad till en instans egen publika IP kommer tillbaka samma väg — det är därför en VPC utan gateway får en så snart du kopplar en publik IP i den.

Vad gatewayen inte avgör är vem som får nå in: det gör reglerna i säkerhetsgruppen på resursen, plus en publik IP på den instans du vill göra nåbar.

De tre anslutningstillstånden

En VPC befinner sig alltid i exakt ett av dem. En VPC som har en gateway går ut från en publik adress; det du väljer är var den adressen kommer ifrån.

Utgående internetKälladress som motparten serPublika IP-adresser som används
Ingen GatewayNej — isolerad0
Gateway, standardadressenJaEn adress som plattformen väljer. Syns ingenstans, och lottas om ifall gatewayen byggs upp på nytt0
Gateway, en publik IP du angerJaDen publika IP du angav — fast, och din1, från din tenants kvot

"Ingen Gateway" är frånvaron av resursen, inte ett läge och inte en knapp du stänger av. Det finns ingen gateway utan adress: antingen har VPC:n en gateway, eller så har den ingen.

Vilket vill du ha

  • Standardadressen — rätt val så snart ingenting på motpartens sida bryr sig om vilken adress du kommer från: paketspeglar, publika API:er, webhooks du skickar, programuppdateringar. Du får den genom att be om en gateway utan att ange någon adress. Den kostar dig ingenting: den använder ingen av din kvot för publika IP-adresser, den syns i ingen av dina listor, den har inget id, och den når aldrig en faktura. Det den inte kan är att förbli oförändrad — se varningen nedan.
  • En publik IP du anger — välj det när en motpart tillåtelistar din källadress, eller när adressen ska in i DNS: ett partner-API, en kunds brandvägg, en SFTP-slutpunkt som bara accepterar kända adresser. Adressen är en egen publik IP som du väljer. Den syns bland dina publika IP-adresser, den räknas mot din tenants kvot för publika IP-adresser, den debiteras som en publik IP, och den är fastnålad — den behåller sin adress även om gatewayen eller VPC:n tas bort och byggs upp igen. Se Välj adressen gatewayen använder.
  • Ingen gateway — rätt svar för en VPC som inte ska prata med internet alls: ett isolerat backend-skikt, ett databehandlingsnätverk som bara nås från andra resurser i samma VPC. Det kostar ingenting.

Bara en adress du själv angett är trygg att publicera eller låta tillåtelistas

Standardadressen är inte din och den är inte fast. Den lottas fram av plattformen, den är inte en resurs du äger, den syns i ingen lista över publika IP-adresser, och den lottas om varje gång gatewayen eller VPC:n byggs upp på nytt. Den överlever inte heller gatewayen.

Den får därför aldrig ges till en partner för en tillåtelista, aldrig läggas in i en kunds brandvägg och aldrig publiceras i en DNS-post. När adressen ändras — och ingenting varnar dig innan det sker — slutar den trafiken helt enkelt att accepteras.

Om någon utanför din VPC behöver veta vilken adress din trafik kommer från, ange en egen publik IP. Det är den enda adressen på den här sidan som har ett löfte knutet till sig.

Att ta bort en Gateway kostar mer än internetåtkomsten

VPC:ns namnuppslag (DNS) och dess anslutning till hanterade tjänster går samma väg. Tar du bort Gateway förlorar VPC:n alla tre på en gång: ingen utgående internetåtkomst, inget DNS och ingen anslutning till hanterade tjänster. Resurser inuti VPC:n fortsätter att köra och fortsätter prata med varandra över privata adresser — men allt som slår upp ett värdnamn eller når en hanterad tjänst slutar fungera.

Därför kräver varje yta att du uttrycker avsikten explicit: en bekräftelse i portalen, en flagga på CLI:t, en godkänd plan i Terraform.

Välj anslutning när du skapar en VPC

När du skapar en VPC kan du välja anslutning — none eller public-ip. Utelämnar du valet betyder det none: ingenting provisioneras, så en VPC får aldrig utgående anslutning bara för att ett fält utelämnades.

I portalen frågar Nätverk → VPC:er → Skapa efter valet och förväljer ingenting.

bash
fm network vpc create --name my-vpc --cidr 10.0.0.0/16 --gateway public-ip
fm network vpc create --name my-vpc --cidr 10.0.0.0/16 --gateway none

CLI:t stavar det anslutna valet public-ip och accepterar även public_ip. Det ger VPC:n en gateway på standardadressen; att ange en egen publik IP gör du på själva gatewayen, nedan.

Kontrollera gatewayen efter att VPC:n skapats

Valet vid skapandet tillämpas så gott det går, och efter att VPC:n själv finns. VPC:n skapas först; gatewayen provisioneras i ett efterföljande steg, och ett fel där är medvetet inte dödligt för VPC:n — en kapacitetsgräns hos plattformen, ett fel när den utgående vägen sätts upp eller ett misslyckat registreringsanrop lämnar dig med den VPC du bad om, utan gateway, och skapandet rapporterar ändå att det lyckades.

Bekräfta det alltså efteråt i stället för att anta:

bash
fm network gateway get --vpc-id vpc-abc123

eller titta på VPC:ns anslutningspanel i portalen — den kontrollerar det åt dig och varnar om det val du gjorde inte tillämpades. Om VPC:n hamnade utan gateway är ingenting förbrukat och ingenting trasigt: lägg till en med fm network gateway create (nedan).

Terraform är medvetet annorlunda. frostmoln_vpc har inget anslutningsargument, eftersom en VPC som skapade en gateway vid sidan om skulle äga ett objekt som Terraform inte hanterar. I Terraform är anslutningsvalet förekomsten eller frånvaron av den resursen.

Det spelar roll för en VPC som inte började i Terraform, och felläget är tystare än man väntar sig. Om VPC:n redan har en gateway — vald vid skapandet, eller påkopplad av plattformen när en publik IP kopplades på — misslyckas det inte nödvändigtvis att deklarera frostmoln_gateway för den. En resurs som inte anger något public_ip_id tar över den gateway som redan finns: Terraform rapporterar ett skapande den inte utförde, och VPC:n fortsätter gå ut via den adress gatewayen redan hade — den plattformen lottade fram, eller en som valts tidigare från portalen eller CLI:t, men inte en som den här konfigurationen anger. Deklarationen avvisas normalt med GATEWAY_EXISTS bara när resursen anger ett public_ip_id som den befintliga gatewayen inte har. För att hantera en gateway som redan finns, importera den i stället för att deklarera en ny.

Hur VPC:n än börjar är gateway-resursen nedan sättet att lägga till, ändra eller ta bort anslutningen efteråt — valet vid skapandet kan inte anges på nytt för en VPC som redan finns.

Lägg till en Gateway på en befintlig VPC

Att lägga till en är icke-destruktivt: instanser fortsätter köra och behåller sina adresser, de får helt enkelt en väg ut.

I portalen

Öppna Nätverk → VPC:er och sedan VPC:n. Panelen Gateway visar om VPC:n har en och vilken adress dess utgående trafik ser ut att komma från. När du lägger till en får du frågan var den adressen ska komma ifrån: plattformens standardadress, eller en av dina egna publika IP-adresser, som du sedan väljer ur en lista. När gatewayen finns erbjuder panelen Ta bort Gateway, och — så länge gatewayen använder standardadressen — Gör adressen till min, som beskrivs under Gör gatewayens adress till din.

Från CLI:t

fm network gateway hanterar en VPC:s gateway:

bash
# Alla gateways i tenanten. En VPC utan gateway saknas helt enkelt i listan.
fm network gateway list

# En VPC:s gateway
fm network gateway get --vpc-id vpc-abc123

# Ge en VPC utgående åtkomst på standardadressen — --mode är obligatoriskt och
# har aldrig något standardvärde
fm network gateway create --vpc-id vpc-abc123 --mode public-ip

# ...eller ut via en publik IP du redan har
fm network gateway create --vpc-id vpc-abc123 --mode public-ip --public-ip-id pip-xyz789

# Peka en befintlig gateway på en annan av dina publika IP-adresser — --yes
# bekräftar avbrottet
fm network gateway set-mode --vpc-id vpc-abc123 \
  --mode public-ip --public-ip-id pip-xyz789 --yes

# Ta bort den — --yes bekräftar förlusten av internet, DNS och hanterade tjänster
fm network gateway delete --vpc-id vpc-abc123 --yes

--mode tar public-ip (public_ip accepteras också) och har aldrig något standardvärde: anslutning är ett uttalat val, aldrig något en VPC får bara för att en flagga utelämnades.

--public-ip-id anger vilken publik IP VPC:n ska gå ut via, och den är valfri:

  • Utelämnar du den tar gatewayen plattformens standardadress. Ingenting tilldelas dig, ingenting dyker upp i fm network public-ip list, och ingenting debiteras. Adressen är inte fast.
  • Anger du en blir den publika IP-adressen VPC:ns källadress — listad, räknad mot din kvot, debiterad som en publik IP, och fastnålad.

Att utelämna --public-ip-id tilldelar inte en adress åt dig

Det gjorde det förut. Det gör det inte längre: en utelämnad --public-ip-id betyder nu "använd plattformens standardadress", som är dold och inte debiteras — inte "tilldela en publik IP åt mig". Ingenting dyker upp i din lista över publika IP-adresser för att du skapade en gateway utan att ange någon, och ingenting där är tryggt att tillåtelista.

Skript som skrevs mot det gamla beteendet fungerar vidare och håller VPC:n ansluten; det som ändras är att de inte längre ger dig en adress du kan slå upp, publicera eller lämna till en partner. Om ditt skript förlitade sig på det: allokera en publik IP och ange den explicit.

Bra att veta när du skriptar:

  • get -o json ger alltid en lista med noll eller en gateway — samma form som list ger — så samma jq fungerar oavsett svar:

    bash
    fm network gateway get --vpc-id vpc-abc123 -o json | jq -r '.[0].mode // empty'
  • create mot en VPC som redan har en gateway är en idempotent upprepning: den rapporterar den befintliga gatewayen, och ingenting skapas eller förbrukas. Att inte ange någon adress är också en upprepning — en utelämnad adress betyder "behåll den adress gatewayen har", så den ger aldrig en befintlig gateway en ny. Bara en create som anger en annan adress avvisas (GATEWAY_EXISTS); använd set-mode till det. Det är samma regel som får Terraform att ta över en gateway den inte skapat.

  • set-mode som ber om det gatewayen redan har gör ingenting och kräver inget --yes.

  • set-mode utan --public-ip-id tar aldrig bort en adress. Att utelämna den betyder "behåll den adress gatewayen har", inte "gå tillbaka till standardadressen" — annars skulle varje verktyg som aldrig hört talas om flaggan lossa fastnålningen av din valda adress bakom ryggen på dig. Att lämna tillbaka en vald adress är avsiktligt, och beskrivs under Lämna tillbaka en vald adress.

  • delete avslutas med nollskild kod för ett --vpc-id som inte kan bekräftas finnas. En tom gateway-sökning ser likadan ut för "denna VPC har ingen", "okänt id" och "en annan tenants VPC" — så ett avvecklingsskript som pekar på ett gammalt eller feltypat id får veta att det inte gjorde något, i stället för att få höra att gatewayen är borta medan den fortfarande sitter kvar.

  • Av samma skäl säger get att en VPC saknar gateway i stället för att misslyckas. Kombinera med fm network vpc get <vpc-id>, som däremot rapporterar en VPC som inte finns.

Med Terraform

hcl
resource "frostmoln_gateway" "main" {
  vpc_id = frostmoln_vpc.main.id
  mode   = "public_ip"
}

# Adressen som utgående trafik ser ut att komma från. På en gateway utan
# public_ip_id är detta plattformens adress — läs den för felsökning, aldrig
# för att publicera den.
output "gateway_source_address" {
  value = frostmoln_gateway.main.source_address
}

public_ip_id anger vilken adress trafiken ska gå ut via, och det är det du deklarerar när adressen måste vara fast:

hcl
resource "frostmoln_public_ip" "gateway" {}

resource "frostmoln_gateway" "main" {
  vpc_id       = frostmoln_vpc.main.id
  mode         = "public_ip"
  public_ip_id = frostmoln_public_ip.gateway.id
}
  • public_ip_id är valfritt. Utelämnar du det använder gatewayen plattformens standardadress: VPC:n har utgående anslutning, ingenting tilldelas din tenant, och ingenting debiteras. Attributet förblir null — plattformen rapporterar inget id tillbaka, eftersom det inte finns någon resurs av ditt att rapportera.

  • Poängen är att deklarera den som en egen frostmoln_public_ip. Då överlever adressen gatewayen: ta bort och skapa om frostmoln_gateway.main, eller hela VPC:n, och samma frostmoln_public_ip kopplas in igen med samma adress.

  • Att ta bort attributet igen lämnar inte tillbaka adressen. Terraform behåller det registrerade värdet och planerar ingen ändring, eftersom ett utelämnat public_ip_id betyder "behåll det du har" i stället för "återgå till plattformens adress". Vill du flytta gatewayen till en annan adress anger du den andra adressen; vill du gå tillbaka till plattformens, se Lämna tillbaka en vald adress.

  • En ändring av public_ip_id görs på plats — aldrig som borttagning och nyskapande. Den ger däremot VPC:n en ny utgående adress och bryter pågående anslutningar, så den kräver acknowledge_connectivity_loss = true.

  • mode tar public_ip. Allt annat avvisas redan när planen valideras, så en konfiguration som fortfarande sätter det misslyckas innan någonting tillämpas. Tänk på stavningen: CLI:t accepterar även public-ip med bindestreck, så ett värde kopierat från ett CLI-kommando måste skrivas om med understreck här.

  • acknowledge_connectivity_loss är ett valfritt booleskt fält som armerar resursen för en borttagning eller en ändring av public_ip_id. Leverantören avvisar båda utan det, redan innan någon begäran skickas. Sätt det till true, kör apply, gör sedan borttagningen eller ändringen — och ta bort raden igen efteråt. Lämnas den kvar avväpnas skyddet för resten av resursens livstid: en senare terraform destroy -target, en borttagen modul eller en ändring av vpc_id skulle då koppla bort VPC:n utan mer i planen än ett vanligt "will be destroyed".

  • Det är vpc_id som tvingar fram en ersättning — och den ersättningen tar bort den befintliga gatewayen först, vilket avvisas om inte bekräftelsen redan är applicerad.

  • source_address, status och origin är skrivskyddade. Efter ett byte av public_ip_id registrerar plattformen adressen på nytt, så den planeras som "(known after apply)".

  • Importera med gatewayens id eller VPC:ns id (en gateway utan lagrad post kan bara adresseras med VPC-id). En importerad gateway är aldrig förbekräftad.

    bash
    terraform import frostmoln_gateway.main vpc-abc123

Ordna kopplade adresser mot gatewayen

En adress som är kopplad till något kräver att VPC:n har en gateway — men ingenting som utför kopplingen refererar till frostmoln_gateway, så Terraform ser inget samband mellan dem och kör de två samtidigt. Det gäller frostmoln_public_ip (via dess instance_id), frostmoln_public_ip_association, frostmoln_load_balancer och frostmoln_kubernetes_cluster (public_ip_id). Vilken som helst kan vinna, och båda de felaktiga ordningarna straffar sig:

  • Vid nedmontering kan gatewayen gå först, och då avvisas borttagningen med GATEWAY_IN_USE — destroy stannar halvvägs, med delar av stacken redan borta.
  • Vid skapande kan kopplingen ske först, och då kopplar plattformen på en egen gateway för att bära den. Din frostmoln_gateway krockar sedan antingen med den (GATEWAY_EXISTS, om den anger ett public_ip_id) eller tar tyst över den, enligt ovan.

Detta gäller när gatewayen är en frostmoln_gateway-resurs i samma konfiguration. En data "frostmoln_gateway" kan inte bära ordningen — en datakälla läses, den skapas och tas aldrig bort, så att bero på en skjuter bara upp en läsning och ordnar ingenting. Är gatewayen inte din att hantera, importera den först.

Ange ordningen själv, på resursen som utför kopplingen:

hcl
resource "frostmoln_public_ip_association" "web" {
  public_ip_id = frostmoln_public_ip.web.id
  instance_id  = frostmoln_instance.web.id

  depends_on = [frostmoln_gateway.main]
}

Samma rad hör hemma på vilken som helst av de andra: en frostmoln_public_ip vars eget instance_id utför kopplingen, en frostmoln_load_balancer med scheme = "public", ett frostmoln_kubernetes_cluster som anger ett public_ip_id. Ligger gatewayen i en annan modul, rikta beroendet mot modulen: depends_on = [module.network].

Fyra saker att veta innan du kopierar den:

  • Den hör hemma på kopplingen, inte på reservationen. En adress som bara är reserverad beror inte på något — och en adress som slås upp med datakällan frostmoln_public_ip har ingen reservationsresurs att hänga den på.
  • Lägg den aldrig på adressen som ditt frostmoln_gateway.public_ip_id anger. Gatewayen beror redan på den adressen, så ett beroende åt andra hållet blir ett Cycle:-fel redan vid plan. Den adressen är redan rätt ordnad.
  • Skriv den aldrig åt andra hållet — på gatewayen, med adresserna uppräknade. Det är det frestande misstaget, eftersom det är gatewayen som måste finnas först; men depends_on ordnar den resurs den står på, så det kastar om båda ordningarna och gör en kapplöpning som ibland gick vägen till en nedmontering som misslyckas varje gång.
  • Den ändrar bara ordning. Ingenting skapas och ingenting frigörs — och den armerar inte gatewayens egen borttagning, som fortfarande kräver acknowledge_connectivity_loss först.

Om en gateway redan har tagits över är origin avslöjaren: den står som implicit_public_ip eller vpc_create i stället för explicit, och source_address är en adress du aldrig valt. Du behöver varken importera eller bygga om något — resursen finns redan i Terraforms state. Lägg till ordningen så att det inte kan upprepas, och ge sedan gatewayen den adress du menade genom att sätta public_ip_id, vilket tillämpas på plats och kräver acknowledge_connectivity_loss = true.

För att läsa en gateway du inte hanterar — en som valdes vid VPC-skapandet eller som kopplades på när en publik IP anslöts — använd datakällan:

hcl
data "frostmoln_gateway" "production" {
  vpc_id = frostmoln_vpc.production.id
}

# Trygg att lämna till en partner ENDAST om denna gateway har ett public_ip_id.
# Utan ett sådant är värdet plattformens adress, som lottas om när gatewayen
# byggs upp på nytt.
output "gateway_source_address" {
  value = data.frostmoln_gateway.production.source_address
}

Välj adressen gatewayen använder

Varje Gateway har en källadress. Den är antingen plattformens, eller en av dina publika IP-adresser — samma resurs som du själv reserverar, listar och frigör. Du bestämmer vilket:

  • Ange en adress du har. Reservera en publik IP (eller återanvänd en som är available) och ange den när du skapar gatewayen, eller peka en befintlig gateway på den. Den adressen syns bland dina publika IP-adresser, räknas mot din kvot, debiteras som en publik IP och nålas fast på gatewayen.
  • Eller ange ingen. Gatewayen tar plattformens adress. Ingenting tilldelas dig, ingenting listas, ingen kvot förbrukas och ingenting debiteras — och adressen är inte fast.

Varför välja adressen själv

Eftersom adressen då är din resurs överlever den gatewayen. Ta bort Gateway, eller radera VPC:n och bygg upp den från grunden igen: den publika IP-adressen förblir reserverad för din tenant, behåller sitt id och behåller sin adress, och att peka den nya gatewayen på den återställer exakt den adress du hade förut.

Det är det som gör adressen trygg att lämna ut:

  • till en partner eller leverantör som tillåtelistar adressen din trafik kommer från,
  • till en kund vars brandvägg bara accepterar kända källor,
  • i en DNS-post du publicerar.

Plattformens standardadress ger inget sådant löfte. Den är inte din, den finns i ingen lista, den lottas om ifall gatewayen eller VPC:n byggs upp på nytt, och den överlever inte gatewayen. Lämna den aldrig till någon som tänker tillåtelista den, och publicera den aldrig.

Lämna tillbaka en vald adress

Åt andra hållet — från en egen publik IP tillbaka till plattformens adress — är det avsiktligt, eftersom ingen klient ska kunna göra det av misstag. Att utelämna adressen läses som "behåll den du har", så vägen tillbaka är att ta bort gatewayen och skapa den på nytt utan att ange någon adress:

bash
fm network gateway delete --vpc-id vpc-abc123 --yes
fm network gateway create --vpc-id vpc-abc123 --mode public-ip

Den publika IP-adressen återvänder till din lista med id och adress intakta, som en available adress du fortfarande har — att frigöra den är en separat och permanent handling. Mellan de två kommandona har VPC:n ingen utgående internetåtkomst, inget DNS och ingen anslutning till hanterade tjänster, så behandla det som ett kort underhållsfönster.

Medan adressen är kopplad till en gateway

En publik IP som används av en Gateway är upptagen, så:

  • den kan inte kopplas till en instans — ge den instansen en annan adress, och
  • den kan inte frigöras — att frigöra den ger bort adressen för gott, vilket är just det gatewayen finns till för att förhindra.

Koppla loss den först, så går båda igen. Att koppla loss betyder: peka gatewayen på en annan publik IP, eller ta bort gatewayen. Adressen blir då en helt vanlig available publik IP igen — fortfarande reserverad för din tenant och fortfarande räknad mot din kvot, tills du frigör den.

Den åsidosätter inte en instans egen publika IP

En instans som har en egen publik IP går fortfarande ut via den adressen. Gatewayens adress är källa endast för trafik från instanser som saknar en egen. Att välja adress för gatewayen ändrar alltså ingenting i hur dina publikt exponerade instanser ser ut utifrån.

Gör gatewayens adress till din

En gateway på plattformens standardadress kan få exakt den adressen omvandlad till en publik IP som du äger, utan att adressen ändras. Det är den enda åtgärden på den här sidan som inte ändrar någonting för din trafik:

  • Adressen förblir exakt densamma. Ingenting flyttas och ingenting startas om; det blir inget avbrott.
  • Efteråt syns den i din lista över publika IP-adresser och är fastnålad, så den överlever att Gateway eller VPC:n skapas om — samma löfte som när du väljer adress själv.
  • Från och med då räknas den mot din kvot för publika IP-adresser och debiteras som en publik IP. Det är hela skälet till att det är ditt val och inte något som görs åt dig.
bash
fm network gateway adopt-public-ip --vpc-id vpc-abc123

I portalen erbjuder VPC:ns panel Gateway valet Gör adressen till min.

Det är rätt drag när en adress du aldrig var tänkt att publicera redan har publicerats — det är den enda vägen från standardadressen till en fast adress som inte ändrar adressen, så tillåtelistor och DNS-poster som redan bär den fortsätter att fungera.

Att ta över två gånger är ofarligt — andra gången ändras ingenting och samma adress rapporteras. Det gäller bara en gateway som inte redan går ut via en publik IP du valt; en som gör det har ingenting att ta över. En gateway som fortfarande ligger

Vad en gateway berättar

FältBetydelse
KälladressDen publika adress som utgående trafik ser ut att komma från. Trygg att tillåtelista endast när en publik IP visas nedan; annars är den plattformens, och den ändras. Tom så länge adressen inte är känd.
Publik IPDen publika IP gatewayen går ut via, när du angett en. Dess adress är källadressen, och den förblir din när gatewayen försvinner. Tom betyder att gatewayen använder plattformens standardadress — den du inte får publicera.
StatusObserverad från plattformen, inte från sparade inställningar: active eller detached.
UrsprungVem som bad om gatewayen (se nedan).

Värden för ursprung:

  • explicit — skapad direkt, via portalen, CLI:t, Terraform eller API:t, utan att någon adress angavs.
  • explicit_public_ip — skapad direkt, precis som explicit, och den publika IP den går ut via angavs av dig. Hålls isär eftersom den adressen är din egen resurs: den lämnas tillbaka till dig i stället för till plattformen när gatewayen släpper den.
  • implicit_public_ip — tillagd av plattformen för att en publik IP kopplades i denna VPC. Inkommande och utgående trafik delar samma väg, så att koppla en publik IP i en VPC utan gateway ger den en.
  • vpc_create — den följde med VPC:n, från ett anslutningsval som gjordes när VPC:n skapades. Bara det valet registrerar detta ursprung.
  • legacyokänt. Det finns ingen uppgift om vem som bad om gatewayen. Det beror oftast på att VPC:n är äldre än resursen, men inte alltid — läs det som "okänt", aldrig som "gammalt".

Byta källadress

Att peka en gateway på en annan av dina publika IP-adresser görs på plats: gatewayen behåller sin identitet och ingenting tas bort och skapas om. Det är däremot ett avbrott — inte ett tyst byte:

  • Källadressen ändras. Allt som tillåtelistar din gamla adress slutar acceptera din trafik tills den nya lagts till hos motparten. Eftersom du själv anger den nya adressen är det här det enda fallet där du känner den i förväg.
  • Pågående anslutningar bryts. Sessioner som är öppna under bytet avbryts och måste återansluta.
  • Det kräver en uttrycklig bekräftelse, och det är just det den bekräftar: den ändrade källadressen och de brutna anslutningarna.

Det är inte en borttagning. Själva internetåtkomsten fortsätter, och DNS och anslutning till hanterade tjänster ingår inte i vad ändringen kostar.

Att ange en adress förbrukar en adress ur din tenants kvot och lägger den på din faktura som en publik IP. Adressen du pekar bort ifrån kopplas loss: den förblir reserverad för din tenant, behåller sin adress och blir available igen, så ett senare byte tillbaka kan använda exakt samma adress.

  • Portalen — VPC:ns Gateway-panel, och bekräfta.

  • CLI:t:

    bash
    fm network gateway set-mode --vpc-id vpc-abc123 \
      --mode public-ip --public-ip-id pip-xyz789 --yes
  • Terraform — applicera acknowledge_connectivity_loss = true först, ändra sedan public_ip_id och kör apply igen, och ta därefter bort bekräftelseraden.

Behandla det som ett kort underhållsfönster. Plattformen reserverar det som ändringen behöver innan den tar ned den gamla adressen, så om den inte kan genomföras avvisas den och VPC:n lämnas precis som den var.

Ta bort en Gateway

Detta tar även bort DNS och anslutning till hanterade tjänster

VPC:n förlorar utgående internetåtkomst, namnuppslag och anslutning till hanterade tjänster samtidigt. Resurser inuti fortsätter köra; allt som slår upp ett namn eller pratar med en hanterad tjänst slutar fungera.

  • PortalenTa bort Gateway på VPC:n, och bekräfta.

  • CLI:t--yes är bekräftelsen, och kommandot vägrar utan den:

    bash
    fm network gateway delete --vpc-id vpc-abc123 --yes
  • Terraform — sätt acknowledge_connectivity_loss = true och kör apply, ta sedan bort resursen (eller kör terraform destroy). Utan att den applicerats först misslyckas borttagningen i stället för att tyst koppla bort VPC:n.

Borttagning avvisas så länge publika IP-adresser i VPC:n är beroende av gatewayen. Koppla loss dem först — det är gratis, går att ångra och räcker för att klara kontrollen:

bash
fm network public-ip disassociate <public-ip-id>

Att frigöra dem klarar kontrollen också, men att frigöra är permanent: adressen går tillbaka till plattformen, delas ut på nytt till nästa som ber om en, och du kan inte få tillbaka den. Frigör bara en adress du är säker på att du aldrig vill ha igen.

Att radera själva VPC:n tar bort dess gateway tillsammans med den.

Gatewayens egen adress hör inte till det som blockerar. Är det en publik IP som är din kopplas den loss åt dig när gatewayen försvinner och förblir reserverad för din tenant som en available publik IP med samma adress — att ta bort gatewayen ger inte bort adressen, det gör bara en frigöring av den publika IP-adressen. Är det plattformens standardadress följer den helt enkelt med gatewayen; det fanns aldrig något av ditt att behålla.

Ett undantag, på äldre VPC:er. En gateway vars Ursprung är vpc_create kan hålla en publik IP som plattformen tilldelade när VPC:n skapades — från tiden innan det enda sättet att få en egen adress var att ange den. Du har aldrig bett om en stående adress, så just den frigörs när gatewayen tas bort i stället för att ligga kvar reserverad och debiteras. Att frigöra är permanent. Betyder den adressen något för någon utanför din VPC: notera den innan du tar bort gatewayen.

Om en begäran avvisas

Varje avvisning bär en maskinläsbar kod vid sidan av meddelandet. Matcha på koden, inte på meddelandet — formuleringen får förbättras, koden får det inte. Alla dessa koder bytte namn tillsammans med resursen: det som förut hette EGRESS_* heter nu GATEWAY_*, och ingenting svarar på den gamla stavningen.

Det du serKodVad det betyder
VPC:n har redan en GatewayGATEWAY_EXISTSEn VPC har högst en. Byt adressen den använder i stället för att lägga till en andra. I Terraform utlöses detta bara när resursen anger ett public_ip_id; en som inte anger något tar tyst över den befintliga gatewayen — se Ordna kopplade adresser mot gatewayen.
Publika IP-adresser är fortfarande beroende av gatewayenGATEWAY_IN_USEKoppla loss VPC:ns publika IP-adresser — gratis och går att ångra — och ta sedan bort gatewayen. Att frigöra dem fungerar också, men är permanent. I Terraform är detta oftast ett ordningsproblem — se Ordna kopplade adresser mot gatewayen — om inte en hanterad resurs i VPC:n håller adressen, vilket meddelandet i så fall säger.
Inga publika adresser är tillgängliga i regionenGATEWAY_POOL_EXHAUSTEDEn kapacitetsgräns hos plattformen, inte din kvot — att be om mer kvot hjälper inte. Försök igen senare.
Din kvot för publika IP-adresser är slutett kvotfel, inte ett gateway-felBara att ange en adress — eller att ta över en — förbrukar kvot, så det här blockerar aldrig en gateway på standardadressen. Frigör en adress du inte använder, eller be om mer kvot.
Den publika IP-adressen kan inte bli källadressGATEWAY_PUBLIC_IP_UNAVAILABLEAdressen du angav är kopplad till en instans eller lastbalanserare, redan kopplad till en annan VPC:s gateway, eller inte en adress som kan bära en VPC:s trafik. Frigör den, eller välj en annan. Meddelandet anger vilket av de tre det är.
Borttagningen av gatewayen bekräftades inteGATEWAY_LOSS_NOT_ACKEDBorttagningen tar med sig internet, DNS och anslutning till hanterade tjänster, så den måste anges uttryckligen: --yes i CLI:t, acknowledge_connectivity_loss = true i Terraform.
Lägesbytet bekräftades inteGATEWAY_MODE_SWITCH_NOT_ACKEDEtt lägesbyte ger VPC:n en ny adress och bryter öppna anslutningar. Skilt från borttagning, eftersom du kommer tillbaka online i stället för att bli mörklagd.
Bytet av källadress bekräftades inteGATEWAY_SOURCE_ADDRESS_CHANGE_NOT_ACKEDAtt peka gatewayen mot en annan publik IP ändrar adressen motparten ser och bryter pågående anslutningar; bekräfta det på samma sätt.
Den publika IP-adressen hålls av en gatewayPUBLIC_IP_IN_USE_BY_GATEWAYReturneras på den publika IP-adressen, inte på gatewayen: en adress som en gateway går ut via kan varken kopplas till en instans eller frigöras. Koppla loss den från gatewayen först.

Relaterat