Gateway

En Gateway er VPC-ens utgående vei mot internett. Den er en egen ressurs, ikke en innstilling på VPC-en: en VPC har høyst én, og en VPC uten har ingen vei ut mot internett i det hele tatt.

Innkommende tilgang er noe annet — det er en offentlig IP pluss de tilhørende reglene i sikkerhetsgruppen.

De tre tilkoblingstilstandene

En VPC er alltid i nøyaktig én av dem. En VPC som har en gateway går alltid ut fra én offentlig adresse; det du velger, er hvor den adressen kommer fra.

	Utgående internett	Kildeadressen motparten ser	Offentlige IP-adresser brukt
Ingen Gateway	Nei — isolert	—	0
Gateway, standardadressen	Ja	En adresse plattformen velger. Vises ingen steder, og velges på nytt hvis gatewayen gjenopprettes	0
Gateway, en offentlig IP du oppgir	Ja	Den offentlige IP-en du oppga — fast, og din	1, fra tenantens kvote

"Ingen Gateway" er fraværet av ressursen, ikke en modus og ikke en bryter du slår av. Det finnes ingen gateway uten adresse: enten har VPC-en en gateway, eller så har den ingen.

Hvilken vil du ha

• Standardadressen — det riktige valget når ingenting på motpartens side bryr seg om hvilken adresse du kommer fra: pakkespeil, offentlige API-er, webhooks du sender, programvareoppdateringer. Du får den ved å be om en gateway uten å oppgi noen adresse. Den koster deg ingenting: den bruker ingen av kvoten din for offentlige IP-adresser, den vises i ingen av listene dine, den har ingen id, og den når aldri en faktura. Det den ikke kan, er å forbli den samme — se advarselen nedenfor.
• En offentlig IP du oppgir — velg den når en motpart har kildeadressen din på en tillatelsesliste, eller når adressen skal inn i DNS: et partner-API, en kundes brannmur, et SFTP-endepunkt som bare godtar kjente adresser. Adressen er en offentlig IP du eier og velger selv. Den står i listen din over offentlige IP-adresser, den teller mot tenantens kvote for offentlige IP-adresser, den faktureres som en offentlig IP, og den er festet — den beholder adressen sin selv om gatewayen eller VPC-en fjernes og bygges opp igjen. Se Velg adressen gatewayen bruker.
• Ingen gateway — riktig svar for en VPC som ikke skal snakke med internett i det hele tatt: et isolert backend-lag, et databehandlingsnettverk som bare nås fra andre ressurser i samme VPC. Det koster ingenting.

Bare en adresse du selv har oppgitt er trygg å publisere eller få tillatelseslistet

Standardadressen er ikke din, og den er ikke fast. Den velges av plattformen, den er ikke en ressurs du eier, den vises i ingen liste over offentlige IP-adresser, og den velges på nytt hver gang gatewayen eller VPC-en gjenopprettes. Den overlever heller ikke gatewayen.

Den må derfor aldri gis til en partner for en tillatelsesliste, aldri legges inn i en kundes brannmur og aldri publiseres i en DNS-post. Når adressen endrer seg — og ingenting varsler deg før den gjør det — slutter trafikken din rett og slett å bli godtatt.

Trenger noen utenfor VPC-en å vite hvilken adresse trafikken din kommer fra, oppgi en offentlig IP du eier selv. Det er den eneste adressen på denne siden som det følger et løfte med.

Å fjerne en Gateway koster mer enn internettilgangen

VPC-ens navneoppslag (DNS) og dens tilkobling til administrerte tjenester går samme vei. Fjerner du Gateway, mister VPC-en alle tre på én gang: ingen utgående internettilgang, ingen DNS og ingen tilkobling til administrerte tjenester. Ressurser inne i VPC-en fortsetter å kjøre og fortsetter å snakke sammen over private adresser — men alt som slår opp et vertsnavn eller når en administrert tjeneste slutter å virke.

Derfor krever hver flate at du uttrykker hensikten eksplisitt: en bekreftelse i portalen, et flagg på CLI-et, en godkjent plan i Terraform.

Velg tilkobling når du oppretter en VPC

Når du oppretter en VPC kan du velge tilkobling — none eller public-ip. Utelater du valget, betyr det none: ingenting provisjoneres, så en VPC får aldri utgående tilkobling bare fordi et felt ble utelatt.

I portalen spør Nettverk → VPC-er → Opprett om valget og forhåndsvelger ingenting.

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-et staver det tilkoblede valget public-ip, og godtar også public_ip. Det gir VPC-en en gateway på standardadressen; å oppgi en offentlig IP du eier selv gjøres på selve gatewayen, nedenfor.

Kontroller gatewayen etter at VPC-en er opprettet

Valget fra opprettelsen anvendes etter beste evne, og etter at VPC-en selv finnes. VPC-en opprettes først; gatewayen provisjoneres i et påfølgende steg, og en feil der er bevisst ikke fatal for VPC-en — en kapasitetsgrense hos plattformen, en feil når den utgående veien settes opp eller en mislykket registrering etterlater deg med VPC-en du ba om, uten gateway, og opprettelsen melder likevel at den lyktes.

Bekreft det altså etterpå i stedet for å anta:

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

eller se på VPC-ens tilkoblingspanel i portalen — det kontrollerer det for deg og varsler hvis valget du gjorde ikke ble anvendt. Hvis VPC-en endte opp uten gateway, er ingenting brukt og ingenting ødelagt: legg til en med fm network gateway create (nedenfor).

Terraform er bevisst annerledes. frostmoln_vpc har ingen tilkoblingsargument, fordi en VPC som opprettet en gateway på siden ville eie et objekt Terraform ikke forvalter. I Terraform er tilkoblingsvalget tilstedeværelsen eller fraværet av den ressursen.

Det har betydning for en VPC som ikke startet i Terraform, og feilmåten er stillere enn du venter. Hvis VPC-en allerede har en gateway — valgt ved opprettelsen, eller koblet på av plattformen da en offentlig IP ble tilknyttet — feiler det ikke nødvendigvis å deklarere frostmoln_gateway for den. En ressurs som ikke oppgir noen public_ip_id overtar gatewayen som allerede finnes: Terraform melder en opprettelse den ikke utførte, og VPC-en fortsetter å gå ut via adressen gatewayen allerede hadde — den plattformen valgte, eller en som ble valgt tidligere fra portalen eller CLI-et, men ikke en denne konfigurasjonen oppgir. Deklarasjonen avvises normalt med GATEWAY_EXISTS bare når ressursen oppgir en public_ip_id som den eksisterende gatewayen ikke har. For å forvalte en gateway som allerede finnes, importer den i stedet for å deklarere en ny.

Uansett hvordan VPC-en starter, er gateway-ressursen nedenfor måten du legger til, endrer eller fjerner tilkoblingen på etterpå — valget fra opprettelsen kan ikke oppgis på nytt for en VPC som allerede finnes.

Legg til en Gateway på en eksisterende VPC

Å legge til en er ikke-destruktivt: instanser fortsetter å kjøre og beholder adressene sine, de får ganske enkelt en vei ut.

I portalen

Åpne Nettverk → VPC-er, og deretter VPC-en. Panelet Gateway viser om VPC-en har en, og hvilken adresse den utgående trafikken ser ut til å komme fra. Når du legger til en, får du spørsmål om hvor den adressen skal komme fra: plattformens standardadresse, eller en av dine egne offentlige IP-adresser, som du så velger fra en liste. Når gatewayen finnes, tilbyr panelet Fjern Gateway, og — så lenge gatewayen bruker standardadressen — Gjør adressen til min, som er beskrevet under Gjør gatewayens adresse til din egen.

Fra CLI-et

fm network gateway forvalter en VPC-s gateway:

# Alle gatewayer i tenanten. En VPC uten gateway mangler rett og slett i listen.
fm network gateway list

# Én VPC-s gateway
fm network gateway get --vpc-id vpc-abc123

# Gi en VPC utgående tilgang på standardadressen — --mode er påkrevd og har
# aldri en standardverdi
fm network gateway create --vpc-id vpc-abc123 --mode public-ip

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

# Pek en eksisterende gateway på en annen av dine offentlige IP-adresser —
# --yes bekrefter avbruddet
fm network gateway set-mode --vpc-id vpc-abc123 \
  --mode public-ip --public-ip-id pip-xyz789 --yes

# Fjern den — --yes bekrefter tapet av internett, DNS og administrerte tjenester
fm network gateway delete --vpc-id vpc-abc123 --yes

--mode tar public-ip (public_ip godtas også) og har aldri en standardverdi: tilkobling er et uttrykt valg, aldri noe en VPC får fordi et flagg ble utelatt. --public-ip-id angir hvilken offentlig IP VPC-en skal gå ut via, og er valgfritt:

• Utelat det, så tar gatewayen plattformens standardadresse. Ingenting tildeles deg, ingenting dukker opp i fm network public-ip list, og ingenting faktureres. Adressen er ikke fast.
• Oppgi en, så blir den offentlige IP-en VPC-ens kildeadresse — listet, talt mot kvoten din, fakturert som en offentlig IP, og festet.

Å utelate --public-ip-id tildeler ingen adresse for deg

Det gjorde det før. Det gjør det ikke lenger: et utelatt --public-ip-id betyr nå "bruk plattformens standardadresse", som er skjult og ikke faktureres — ikke "tildel en offentlig IP på mine vegne". Ingenting dukker opp i listen din over offentlige IP-adresser fordi du opprettet en gateway uten å oppgi en, og ingenting der er trygt å tillatelsesliste.

Skript skrevet mot den gamle oppførselen fortsetter å virke og holder VPC-en tilkoblet; det som endrer seg, er at de ikke lenger produserer en adresse du kan slå opp, publisere eller gi til en partner. Var ditt avhengig av det, tildel en offentlig IP og oppgi den eksplisitt.

Verdt å vite når du skripter:

• get -o json gir alltid en liste med null eller én gateway — samme form som list gir — så samme jq virker uansett svar:

  fm network gateway get --vpc-id vpc-abc123 -o json | jq -r '.[0].mode // empty'

• create mot en VPC som allerede har en gateway er en idempotent gjentakelse: den melder den eksisterende gatewayen, og ingenting opprettes eller brukes. Å ikke oppgi noen adresse er også en gjentakelse — en utelatt adresse betyr "behold den adressen gatewayen har", så den gir aldri en eksisterende gateway en ny. Bare en create som oppgir en annen adresse avvises (GATEWAY_EXISTS); bruk set-mode til det. Det er samme regel som får Terraform til å overta en gateway den ikke opprettet.

• set-mode som ber om det gatewayen allerede har gjør ingenting, og krever ingen --yes.

• set-mode uten --public-ip-id tar aldri en adresse fra deg. Å utelate det betyr "behold den adressen gatewayen har", ikke "gå tilbake til standardadressen" — ellers ville hvert verktøy som aldri har hørt om flagget løsne den valgte adressen din bak ryggen din. Å gi en valgt adresse tilbake er bevisst, og er beskrevet under Gi en valgt adresse tilbake.

• delete avslutter med kode ulik null for en --vpc-id den ikke kan bekrefte finnes. Et tomt gateway-oppslag ser likt ut for "denne VPC-en har ingen", "ukjent id" og "en annen tenants VPC" — så et avviklingsskript som peker på en gammel eller feilskrevet id får vite at det ikke gjorde noe, i stedet for å få beskjed om at gatewayen er borte mens den fortsatt sitter der.

• Av samme grunn sier get at en VPC mangler gateway i stedet for å feile. Bruk den sammen med fm network vpc get <vpc-id>, som derimot melder fra om en VPC som ikke finnes.

Med Terraform

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

# Adressen utgående trafikk ser ut til å komme fra. På en gateway uten
# public_ip_id er dette plattformens adresse — les den for feilsøking, aldri
# for å publisere den.
output "gateway_source_address" {
  value = frostmoln_gateway.main.source_address
}

public_ip_id angir hvilken adresse trafikken skal gå ut via, og er det du deklarerer når adressen må være fast:

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 er valgfritt. Utelater du det, bruker gatewayen plattformens standardadresse: VPC-en har utgående tilkobling, ingenting tildeles tenanten din, og ingenting faktureres. Attributtet forblir null — plattformen melder ingen id tilbake, fordi det ikke finnes noen ressurs av dine å melde.

• Poenget er å deklarere den som en egen frostmoln_public_ip. Da overlever adressen gatewayen: slett og gjenopprett frostmoln_gateway.main, eller hele VPC-en, og den samme frostmoln_public_ip kobles på igjen med samme adresse.

• Å fjerne attributtet igjen gir ikke adressen tilbake. Terraform beholder den registrerte verdien og planlegger ingen endring, fordi et utelatt public_ip_id betyr "behold det du har" i stedet for "gå tilbake til plattformens adresse". Vil du flytte gatewayen til en annen adresse, må du oppgi den andre adressen; vil du tilbake til plattformens, se Gi en valgt adresse tilbake.

• En endring av public_ip_id gjøres på stedet — aldri som sletting og gjenoppretting. Den gir derimot VPC-en en ny utgående adresse og bryter pågående tilkoblinger, så den krever acknowledge_connectivity_loss = true.

• mode tar public_ip. Alt annet avvises mens planen valideres, så en konfigurasjon som fortsatt setter den feiler før noe blir anvendt. Merk skrivemåten: CLI-et godtar i tillegg bindestrek-formen public-ip, så en verdi kopiert fra en CLI-kommando må skrives om med understrek her.

• acknowledge_connectivity_loss er et valgfritt boolsk felt som armerer ressursen for sletting eller en endring av public_ip_id. Leverandøren avviser begge uten det, før noen forespørsel sendes. Sett det til true, kjør apply, gjør så slettingen eller endringen — og fjern linjen igjen etterpå. Blir den stående, avvæpnes kontrollen for resten av ressursens levetid: en senere terraform destroy -target, en fjernet modul eller en endring av vpc_id ville da koble fra VPC-en uten mer i planen enn en vanlig "will be destroyed".

• Det er vpc_id som tvinger fram en erstatning — og den erstatningen sletter den eksisterende gatewayen først, noe som avvises med mindre bekreftelsen allerede er anvendt.

• source_address, status og origin er skrivebeskyttet. Etter en endring av public_ip_id registrerer plattformen adressen på nytt, så den planlegges som "(known after apply)".

• Importer med gatewayens id eller VPC-ens id (en gateway uten lagret post kan bare adresseres med VPC-id). En importert gateway er aldri forhåndsbekreftet.

  terraform import frostmoln_gateway.main vpc-abc123

Ordne tilknyttede adresser mot gatewayen

En adresse som er tilknyttet noe krever at VPC-en har en gateway — men ingenting som utfører tilknytningen refererer til frostmoln_gateway, så Terraform ser ingen sammenheng mellom dem og kjører de to samtidig. Det gjelder frostmoln_public_ip (via dens instance_id), frostmoln_public_ip_association, frostmoln_load_balancer og frostmoln_kubernetes_cluster (public_ip_id). Hvilken som helst kan vinne, og begge de gale rekkefølgene straffer seg:

• Ved riving kan gatewayen gå først, og da avvises slettingen med GATEWAY_IN_USE — destroy stopper halvveis, med deler av stakken alt borte.
• Ved opprettelse kan tilknytningen skje først, og da kobler plattformen på en egen gateway for å bære den. Din frostmoln_gateway kolliderer så enten med den (GATEWAY_EXISTS, hvis den oppgir en public_ip_id) eller overtar den stille, som over.

Dette gjelder når gatewayen er en frostmoln_gateway-ressurs i samme konfigurasjon. En data "frostmoln_gateway" kan ikke bære rekkefølgen — en datakilde leses, den opprettes og slettes aldri, så å avhenge av en utsetter bare en lesing og ordner ingenting. Er gatewayen ikke din å forvalte, importer den først.

Oppgi rekkefølgen selv, på ressursen som utfører tilknytningen:

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]
}

Samme linje hører hjemme på hvilken som helst av de andre: en frostmoln_public_ip der dens egen instance_id utfører tilknytningen, en frostmoln_load_balancer med scheme = "public", en frostmoln_kubernetes_cluster som oppgir en public_ip_id. Ligger gatewayen i en annen modul, rett avhengigheten mot modulen: depends_on = [module.network].

Fire ting å vite før du kopierer den:

• Den hører hjemme på tilknytningen, ikke på reservasjonen. En adresse som bare er reservert avhenger av ingenting — og en adresse slått opp med datakilden frostmoln_public_ip har ingen reservasjonsressurs å henge den på.
• Legg den aldri på adressen som din frostmoln_gateway.public_ip_id oppgir. Gatewayen avhenger allerede av den adressen, så en avhengighet den andre veien blir en Cycle:-feil alt ved plan. Den adressen er allerede riktig ordnet.
• Skriv den aldri motsatt vei — på gatewayen, med adressene listet opp. Det er den fristende feilen, siden det er gatewayen som må finnes først; men depends_on ordner ressursen den står på, så det snur begge rekkefølgene og gjør et kappløp som iblant gikk bra, til en riving som feiler hver gang.
• Den endrer bare rekkefølge. Ingenting opprettes og ingenting frigis — og den armerer ikke gatewayens egen sletting, som fortsatt krever acknowledge_connectivity_loss først.

Er en gateway allerede overtatt, er origin tegnet: den står som implicit_public_ip eller vpc_create i stedet for explicit, og source_address er en adresse du aldri valgte. Du trenger verken å importere eller bygge om noe — ressursen ligger allerede i Terraform-staten. Legg til rekkefølgen så det ikke kan gjenta seg, og gi så gatewayen adressen du mente ved å sette public_ip_id, som anvendes på stedet og krever acknowledge_connectivity_loss = true.

For å lese en gateway du ikke forvalter — en som ble valgt ved VPC-opprettelsen, eller som ble koblet på da en offentlig IP ble tilknyttet — bruk datakilden:

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

# Trygt å gi til en partner BARE hvis denne gatewayen har en public_ip_id. Uten
# en er verdien plattformens adresse, som velges på nytt ved en gjenoppretting.
output "gateway_source_address" {
  value = data.frostmoln_gateway.production.source_address
}

Velg adressen gatewayen bruker

Hver Gateway har én kildeadresse. Den er enten plattformens, eller en av dine offentlige IP-adresser — den samme ressursen du selv reserverer, lister og frigir. Du bestemmer hvilken:

• Oppgi en adresse du har. Reserver en offentlig IP (eller gjenbruk en som er available) og oppgi den når du oppretter gatewayen, eller pek en eksisterende gateway på den. Den adressen står i listen din over offentlige IP-adresser, teller mot kvoten din, faktureres som en offentlig IP, og er festet på gatewayen.
• Eller oppgi ingen. Gatewayen tar plattformens adresse. Ingenting tildeles deg, ingenting listes, ingen kvote brukes og ingenting faktureres — og adressen er ikke fast.

Hvorfor oppgi adressen selv

Fordi adressen er din ressurs, overlever den gatewayen. Fjern Gateway, eller slett VPC-en og bygg den opp igjen fra bunnen: den offentlige IP-adressen forblir reservert for tenanten din, beholder id-en sin og beholder adressen sin, og å peke den nye gatewayen på den gjenoppretter nøyaktig adressen du hadde før.

Det er det som gjør adressen trygg å gi ut:

• til en partner eller leverandør som setter adressen trafikken din kommer fra på en tillatelsesliste,
• til en kunde hvis brannmur bare godtar kjente kilder,
• i en DNS-post du publiserer.

Plattformens standardadresse gir ikke noe slikt løfte. Den er ikke din, den står i ingen liste, den velges på nytt hvis gatewayen eller VPC-en gjenopprettes, og den overlever ikke gatewayen. Gi den aldri til noen som har tenkt å sette den på en tillatelsesliste, og publiser den aldri.

Gi en valgt adresse tilbake

Å gå den andre veien — fra en offentlig IP du eier tilbake til plattformens adresse — er bevisst, fordi ingen klient skal kunne gjøre det ved et uhell. Å utelate adressen leses som "behold det du har", så veien tilbake er å fjerne gatewayen og opprette den på nytt uten å oppgi noen adresse:

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

Den offentlige IP-en kommer tilbake i listen din med id-en og adressen sin intakt, som en available adresse du fortsatt har — å frigi den er en egen, permanent handling. Mellom de to kommandoene har VPC-en ingen utgående internettilgang, ingen DNS og ingen tilkobling til administrerte tjenester, så behandle det som et kort vedlikeholdsvindu.

Mens adressen er koblet til en gateway

En offentlig IP som brukes av en Gateway er opptatt, så:

• den kan ikke kobles til en instans — gi den instansen en annen adresse, og
• den kan ikke frigis — å frigi den gir bort adressen for godt, som er nettopp det gatewayen finnes for å hindre.

Koble den fra først, så går begge deler igjen. Å koble fra betyr: pek gatewayen på en annen offentlig IP, eller fjern gatewayen. Adressen blir da en helt vanlig available offentlig IP igjen — fortsatt reservert for tenanten din og fortsatt talt mot kvoten din, til du frigir den.

Den overstyrer ikke en instans' egen offentlige IP

En instans som har sin egen offentlige IP går fortsatt ut via den adressen. Gatewayens adresse er kilde bare for trafikk fra instanser som ikke har en egen. Å velge adresse for gatewayen endrer altså ingenting i hvordan de offentlig eksponerte instansene dine ser ut utenfra.

Gjør gatewayens adresse til din egen

En gateway som bruker plattformens standardadresse kan få nøyaktig den adressen gjort om til en offentlig IP du eier, uten at adressen endrer seg. Det er den ene handlingen på denne siden som ikke endrer noe for trafikken din:

• Adressen forblir nøyaktig den samme. Ingenting flyttes og ingenting startes på nytt; det blir ingen avbrudd.
• Etterpå vises den i listen din over offentlige IP-adresser og er festet, så den overlever at Gateway eller VPC-en gjenopprettes — det samme løftet som når du oppgir en adresse selv.
• Fra da av teller den mot kvoten din for offentlige IP-adresser og faktureres som en offentlig IP. Det er hele grunnen til at dette er ditt valg og ikke noe som gjøres for deg.

fm network gateway adopt-public-ip --vpc-id vpc-abc123

I portalen tilbyr VPC-ens panel Gateway valget Gjør adressen til min.

Dette er det riktige grepet når en adresse du aldri skulle publisert allerede er publisert — det er den eneste veien fra standardadressen til en fast adresse som ikke endrer selve adressen, så tillatelseslister og DNS-poster som allerede inneholder den fortsetter å virke.

Å overta to ganger er ufarlig — andre gangen endres ingenting, og samme adresse meldes tilbake. Det gjelder bare en gateway som ikke allerede går ut via en offentlig IP du har valgt; en som gjør det, har ingenting å overta. En gateway som

Hva en gateway forteller deg

Felt	Betydning
Modus	public_ip.
Kildeadresse	Den offentlige adressen utgående trafikk ser ut til å komme fra. Trygg å tillatelsesliste bare når en offentlig IP vises nedenfor; ellers er den plattformens, og den endrer seg. Tom så lenge adressen ikke er kjent.
Offentlig IP	Den offentlige IP-en gatewayen går ut via, når du har oppgitt en. Adressen dens er kildeadressen, og den forblir din når gatewayen forsvinner. Tom betyr at gatewayen bruker plattformens standardadresse — den du ikke må publisere.
Status	Observert fra plattformen, ikke fra lagrede innstillinger: active eller detached.
Opphav	Hvem som ba om gatewayen (nedenfor).

Verdier for opphav:

• explicit — opprettet direkte, via portalen, CLI-et, Terraform eller API-et, uten at en adresse ble oppgitt.
• explicit_public_ip — opprettet direkte, som explicit, og den offentlige IP-en den går ut via ble oppgitt av deg. Holdes atskilt fordi den adressen er din egen ressurs: den gis tilbake til deg i stedet for til plattformen når gatewayen slipper den.
• implicit_public_ip — lagt til av plattformen fordi en offentlig IP ble koblet til i denne VPC-en. Innkommende og utgående trafikk deler samme vei, så å koble til en offentlig IP i en VPC uten gateway gir den en.
• vpc_create — den fulgte med VPC-en, fra et tilkoblingsvalg gjort da VPC-en ble opprettet. Bare det valget registrerer dette opphavet.
• legacy — ukjent. Det finnes ingen opplysning om hvem som ba om gatewayen. Det skyldes som regel at VPC-en er eldre enn ressursen, men ikke alltid — les det som "ukjent", aldri som "gammelt".

Endre kildeadressen

Å peke en gateway på en annen av dine offentlige IP-adresser gjøres på stedet: gatewayen beholder identiteten sin, og ingenting slettes og opprettes på nytt. Det er derimot et avbrudd — ikke et stille bytte:

• Kildeadressen endres. Alt som har den gamle adressen din på en tillatelsesliste slutter å godta trafikken din til den nye er lagt inn hos motparten. Fordi du oppgir den nye adressen, er dette det ene tilfellet der du kjenner den på forhånd.
• Pågående tilkoblinger brytes. Økter som er åpne under endringen brytes og må koble til på nytt.
• Det krever en uttrykkelig bekreftelse, og det er nettopp det den bekrefter: den endrede kildeadressen og de brutte tilkoblingene.

Dette er ikke en fjerning. Selve internettilgangen fortsetter, og DNS og tilkobling til administrerte tjenester inngår ikke i det endringen koster.

Å oppgi en adresse bruker én adresse fra tenantens kvote og setter den på fakturaen din som en offentlig IP. Adressen du peker bort fra, kobles fra: den forblir reservert for tenanten din, beholder adressen sin og blir available igjen, så en senere endring tilbake kan bruke nøyaktig samme adresse.

• Portalen — VPC-ens Gateway-panel, og bekreft.

• CLI-et:

  fm network gateway set-mode --vpc-id vpc-abc123 \
    --mode public-ip --public-ip-id pip-xyz789 --yes

• Terraform — anvend acknowledge_connectivity_loss = true først, endre så public_ip_id og kjør apply igjen, og fjern deretter bekreftelseslinjen.

Behandle det som et kort vedlikeholdsvindu. Plattformen reserverer det endringen trenger før den tar ned den gamle adressen, så hvis den ikke kan gjennomføres, avvises den, og VPC-en står akkurat som den var.

Fjerne en Gateway

Dette fjerner også DNS og tilkobling til administrerte tjenester

VPC-en mister utgående internettilgang, navneoppslag og tilkobling til administrerte tjenester samtidig. Ressurser inne fortsetter å kjøre; alt som slår opp et navn eller snakker med en administrert tjeneste slutter å virke.

• Portalen — Fjern Gateway på VPC-en, og bekreft.

• CLI-et — --yes er bekreftelsen, og kommandoen nekter uten den:

  fm network gateway delete --vpc-id vpc-abc123 --yes

• Terraform — sett acknowledge_connectivity_loss = true og kjør apply, fjern deretter ressursen (eller kjør terraform destroy). Uten at den er anvendt først, feiler slettingen i stedet for å stille koble fra VPC-en.

Fjerning avvises så lenge offentlige IP-adresser i VPC-en er avhengige av gatewayen. Koble dem fra først — det er gratis, kan angres og er nok til å klarere kontrollen:

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

Å frigi dem klarerer kontrollen også, men å frigi er permanent: adressen går tilbake til plattformen, deles ut på nytt til den neste som ber om en, og du får den ikke tilbake. Frigi bare en adresse du er sikker på at du aldri vil ha igjen.

Å slette selve VPC-en fjerner gatewayen sammen med den.

Gatewayens egen adresse er ikke blant det som blokkerer. Er den en offentlig IP du eier, kobles den fra for deg når gatewayen forsvinner, og forblir reservert for tenanten din som en available offentlig IP med samme adresse — å fjerne gatewayen gir ikke bort adressen, det gjør bare en frigivelse av den offentlige IP-en. Er den plattformens standardadresse, følger den ganske enkelt med gatewayen; det fantes aldri noe av ditt å beholde.

Ett unntak, på eldre VPC-er. En gateway med Opphav vpc_create kan holde en offentlig IP plattformen tildelte da VPC-en ble opprettet — fra tiden før det å oppgi en adresse ble den eneste måten å få en egen på. Du har aldri bedt om en stående adresse, så nettopp den frigis når gatewayen fjernes, i stedet for å bli stående reservert og fakturert. Å frigi er permanent. Betyr den adressen noe for noen utenfor VPC-en din, noter den før du fjerner gatewayen.

Hvis en forespørsel avvises

Hver avvisning bærer en maskinlesbar kode ved siden av meldingen. Match på koden, ikke på meldingen — ordlyden står fritt til å bli bedre, koden gjør det ikke. Alle disse kodene ble omdøpt sammen med ressursen: det som før het EGRESS_*, heter nå GATEWAY_*, og ingenting svarer på den gamle skrivemåten.

Det du ser	Kode	Hva det betyr
VPC-en har allerede en Gateway	GATEWAY_EXISTS	En VPC har høyst én. Endre adressen den bruker i stedet for å legge til nummer to. I Terraform utløses dette bare når ressursen oppgir en public_ip_id; en som ikke oppgir noen, overtar den eksisterende gatewayen stille — se Ordne tilknyttede adresser mot gatewayen.
Offentlige IP-adresser er fortsatt avhengige av gatewayen	GATEWAY_IN_USE	Koble fra VPC-ens offentlige IP-adresser — gratis og kan angres — og fjern deretter gatewayen. Å frigi dem virker også, men er permanent. I Terraform er dette som regel et rekkefølgeproblem — se Ordne tilknyttede adresser mot gatewayen — med mindre en forvaltet ressurs i VPC-en holder adressen, noe meldingen da sier.
Ingen offentlige adresser er tilgjengelige i regionen	GATEWAY_POOL_EXHAUSTED	En kapasitetsgrense hos plattformen, ikke kvoten din — å be om mer kvote hjelper ikke. Prøv igjen senere.
Kvoten din for offentlige IP-adresser er brukt opp	en kvotefeil, ikke en gateway-feil	Bare det å oppgi en adresse — eller å overta en — bruker kvote, så dette blokkerer aldri en gateway på standardadressen. Frigi en adresse du ikke bruker, eller be om mer kvote.
Den offentlige IP-en kan ikke brukes som kildeadresse	GATEWAY_PUBLIC_IP_UNAVAILABLE	Adressen du oppga er tilknyttet en instans eller lastbalanserer, er allerede koblet til en annen VPC-s gateway, eller er ikke en adresse som kan bære en VPC-s trafikk. Frigjør den, eller velg en annen. Meldingen sier hvilken av de tre det er.
Fjerning av gatewayen ble ikke bekreftet	GATEWAY_LOSS_NOT_ACKED	Fjerning tar med seg internett, DNS og tilkobling til forvaltede tjenester, så det må sies eksplisitt: --yes på CLI-et, acknowledge_connectivity_loss = true i Terraform.
Modusbyttet ble ikke bekreftet	GATEWAY_MODE_SWITCH_NOT_ACKED	Et modusbytte gir VPC-en ny adresse og bryter åpne forbindelser. Skilt fra fjerning, fordi du kommer tilbake på nett i stedet for å bli mørklagt.
Endringen av kildeadressen ble ikke bekreftet	GATEWAY_SOURCE_ADDRESS_CHANGE_NOT_ACKED	Å peke gatewayen mot en annen offentlig IP endrer adressen motparten ser, og bryter forbindelser underveis; bekreft det på samme måte.
Den offentlige IP-en holdes av en gateway	PUBLIC_IP_IN_USE_BY_GATEWAY	Returneres på den offentlige IP-en, ikke på gatewayen: en adresse en gateway går ut gjennom kan verken tilknyttes en instans eller frigis. Koble den fra gatewayen først.

Relatert

• VPCer · Offentlige IPer · Sikkerhetsgrupper