Gateway

En Gateway er en VPC's forbindelse til internettet. Den er en ressource i sig selv, ikke en indstilling på VPC'en: en VPC har højst én, og en VPC uden en har slet ingen vej til internettet.

Den bærer begge retninger. Trafik fra instanser, der ikke har deres egen offentlige IP-adresse, går ud via gatewayens kildeadresse, og trafik adresseret til en instans' egen offentlige IP-adresse kommer tilbage ad den samme vej — og det er derfor, at det at tilknytte en offentlig IP-adresse i en VPC uden gateway giver den VPC en.

Det, gatewayen ikke afgør, er hvem der må nå ind: det gør reglerne i sikkerhedsgruppen på ressourcen plus en offentlig IP-adresse på den instans, du vil gøre tilgængelig.

De tre forbindelsestilstande

En VPC er altid i præcis én af dem. En VPC, der har en gateway, går altid ud fra én offentlig adresse; det, du vælger, er hvor den adresse kommer fra.

	Udgående internet	Kildeadresse, som modparten ser	Anvendte offentlige IP-adresser
Ingen Gateway	Nej — isoleret	—	0
Gateway, standardadressen	Ja	En adresse, som platformen vælger. Vises intet sted, og trækkes på ny, hvis gatewayen bygges op igen	0
Gateway, en offentlig IP-adresse, du angiver	Ja	Den offentlige IP-adresse, du angav — fast, og din	1, fra din tenants kvote

"Ingen Gateway" er fraværet af ressourcen, ikke en tilstand og ikke en kontakt, du slår fra. Der findes ikke en gateway uden adresse: enten har VPC'en en gateway, eller også har den ingen.

Hvilken vil du have

• Standardadressen — det rigtige valg, når intet på modpartens side bekymrer sig om, hvilken adresse du kommer fra: pakkespejle, offentlige API'er, webhooks du sender, softwareopdateringer. Du får den ved at bede om en gateway uden at angive nogen adresse. Den koster dig ingenting: den bruger intet af din kvote for offentlige IP-adresser, den optræder i ingen af dine lister, den har intet id, og den når aldrig en faktura. Det, den ikke kan, er at forblive den samme — se advarslen nedenfor.
• En offentlig IP-adresse, du angiver — vælg den, når en fjern modpart sætter din kildeadresse på en tilladelsesliste, eller når adressen skal i DNS: et partner-API, en kundes firewall, et SFTP-endepunkt, der kun accepterer kendte adresser. Adressen er en af dine egne offentlige IP-adresser, som du vælger. Den står på din liste over offentlige IP-adresser, den tæller mod din tenants kvote for offentlige IP-adresser, den faktureres som en offentlig IP-adresse, og den er fastgjort — den beholder sin adresse, selv om gatewayen eller VPC'en fjernes og bygges op igen. Se Vælg den adresse, gatewayen bruger.
• Ingen gateway — det rigtige svar for en VPC, der slet ikke må tale med internettet: et isoleret backend-lag, et databehandlingsnetværk, der kun nås fra andre ressourcer i den samme VPC. Det koster ingenting.

Kun en adresse, du selv har angivet, er tryg at offentliggøre eller få på en tilladelsesliste

Standardadressen er ikke din, og den er ikke fast. Den trækkes af platformen, den er ikke en ressource, du ejer, den optræder på ingen liste over offentlige IP-adresser, og den trækkes på ny, hver gang gatewayen eller VPC'en bygges op igen. Den overlever heller ikke gatewayen.

Den må derfor aldrig gives til en partner til en tilladelsesliste, aldrig lægges ind i en kundes firewall og aldrig offentliggøres i en DNS-post. Når adressen ændrer sig — og intet advarer dig, før det sker — holder den trafik ganske enkelt op med at blive accepteret.

Hvis nogen uden for din VPC har brug for at vide, hvilken adresse din trafik kommer fra, så angiv en offentlig IP-adresse af dine egne. Det er den eneste adresse på denne side, der har et løfte knyttet til sig.

At fjerne en Gateway koster mere end internetadgangen

VPC'ens navneopslag (DNS) og dens forbindelse til administrerede tjenester går ad samme vej. Fjerner du Gatewayen, mister VPC'en alle tre på én gang: ingen udgående internetadgang, intet DNS og ingen forbindelse til administrerede tjenester. Ressourcer inde i VPC'en kører videre og bliver ved med at tale sammen over private adresser — men alt, der slår et værtsnavn op eller når en administreret tjeneste, holder op med at virke.

Derfor kræver hver eneste flade, at du udtrykker hensigten eksplicit: en bekræftelse i portalen, et flag på CLI'en, en godkendt plan i Terraform.

Vælg forbindelse, når du opretter en VPC

Når du opretter en VPC, kan du valgfrit vælge forbindelse — none eller public-ip. Udelader du det, betyder det none: intet provisioneres, så en VPC får aldrig udgående forbindelse, fordi et felt blev udeladt.

I portalen spørger Netværk → VPC'er → Opret efter valget og forvælger intet.

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'en staver det tilsluttede valg public-ip og accepterer også public_ip. Det giver VPC'en en gateway på standardadressen; at angive en offentlig IP-adresse af dine egne gør du på selve gatewayen, nedenfor.

Kontrollér gatewayen, efter at VPC'en er oprettet

Valget ved oprettelsen anvendes så godt det kan lade sig gøre, og efter at VPC'en selv findes. VPC'en oprettes først; gatewayen provisioneres i et efterfølgende trin, og en fejl dér er bevidst ikke fatal for VPC'en — en kapacitetsgrænse hos platformen, en fejl under opsætningen af den udgående vej eller en mislykket registrering af den efterlader dig med den VPC, du bad om, uden en gateway, og oprettelsen rapporterer stadig, at den lykkedes.

Bekræft det derfor bagefter i stedet for at antage:

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

eller se på VPC'ens forbindelsespanel i portalen — det kontrollerer det for dig og advarer, hvis det valg, du traf, ikke blev anvendt. Endte VPC'en uden en, er intet brugt, og intet er i stykker: tilføj en med fm network gateway create (nedenfor).

Terraform er bevidst anderledes. frostmoln_vpc har intet forbindelsesargument, fordi en VPC, der oprettede en gateway ved siden af, ville eje et objekt, som Terraform ikke håndterer. I Terraform er forbindelsesvalget tilstedeværelsen eller fraværet af den ressource.

Det har betydning for en VPC, der ikke begyndte i Terraform, og fejltilstanden er mere stille, end man skulle vente. Har VPC'en allerede en gateway — valgt ved oprettelsen eller tilknyttet af platformen, da en offentlig IP-adresse blev tilknyttet — så mislykkes det ikke nødvendigvis at deklarere frostmoln_gateway for den. En ressource, der ikke angiver noget public_ip_id, overtager den gateway, der allerede er der: Terraform rapporterer en oprettelse, den ikke udførte, og VPC'en bliver ved med at gå ud via den adresse, gatewayen allerede havde — den, platformen trak, eller en, der blev valgt tidligere fra portalen eller CLI'en, men ikke en, som denne konfiguration angiver. Den afvises normalt med GATEWAY_EXISTS kun, når ressourcen angiver et public_ip_id, som den eksisterende gateway ikke har. Vil du håndtere en gateway, der allerede findes, så importér den i stedet for at deklarere en ny.

Uanset hvordan VPC'en begynder, er gateway-ressourcen nedenfor måden, du tilføjer, ændrer eller fjerner forbindelsen på bagefter — valget ved oprettelsen kan ikke angives på ny for en VPC, der allerede findes.

Føj en Gateway til en eksisterende VPC

At tilføje en er ikke-destruktivt: instanser kører videre og beholder deres adresser, de får ganske enkelt en vej ud.

I portalen

Åbn Netværk → VPC'er, og derefter VPC'en. Panelet Gateway viser, om VPC'en har en, og hvilken adresse dens udgående trafik ser ud til at komme fra. Tilføjer du en, bliver du spurgt, hvor den adresse skal komme fra: platformens standardadresse, eller en af dine egne offentlige IP-adresser, som du derefter vælger fra en liste. Når gatewayen findes, tilbyder panelet Fjern Gateway, og — så længe gatewayen bruger standardadressen — Gør denne adresse til min, som er beskrevet under Gør gatewayens adresse til din egen.

Fra CLI'en

fm network gateway håndterer en VPC's gateway:

# Hver gateway i tenanten. En VPC uden en mangler ganske enkelt på listen.
fm network gateway list

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

# Giv en VPC udgående adgang på standardadressen — --mode er påkrævet og har
# aldrig en standardværdi
fm network gateway create --vpc-id vpc-abc123 --mode public-ip

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

# Peg en eksisterende gateway på en anden af dine offentlige IP-adresser — --yes
# bekræfter afbrydelsen
fm network gateway set-mode --vpc-id vpc-abc123 \
  --mode public-ip --public-ip-id pip-xyz789 --yes

# Fjern den — --yes bekræfter tabet af internet, DNS og administrerede tjenester
fm network gateway delete --vpc-id vpc-abc123 --yes

--mode tager public-ip (public_ip accepteres også) og har aldrig en standardværdi: forbindelse er et udtalt valg, aldrig et, en VPC får, fordi et flag blev udeladt.

--public-ip-id angiver den offentlige IP-adresse, VPC'en skal gå ud via, og det er valgfrit:

• Udelader du det, tager gatewayen platformens standardadresse. Intet tildeles dig, intet optræder i fm network public-ip list, og intet faktureres. Adressen er ikke fast.
• Angiver du en, bliver den offentlige IP-adresse VPC'ens kildeadresse — opført på listen, talt med i din kvote, faktureret som en offentlig IP-adresse og fastgjort.

At udelade --public-ip-id tildeler ikke en adresse til dig

Det gjorde det før. Det gør det ikke længere: et udeladt --public-ip-id betyder nu "brug platformens standardadresse", som er skjult og ikke faktureres — ikke "tildel en offentlig IP-adresse på mine vegne". Intet optræder på din liste over offentlige IP-adresser, fordi du oprettede en gateway uden at angive en, og intet dér er trygt at sætte på en tilladelsesliste.

Scripts, der er skrevet mod den gamle adfærd, fungerer fortsat og holder VPC'en forbundet; det, der ændrer sig, er, at de ikke længere giver en adresse, du kan slå op, offentliggøre eller give til en partner. Byggede dit script på det, så tildel en offentlig IP-adresse, og angiv den eksplicit.

Værd at vide, når du scripter det:

• get -o json udsender altid en liste med nul eller én gateway — den samme form, som list udsender — så det samme jq virker uanset svaret:

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

• create mod en VPC, der allerede har en gateway, er en idempotent gentagelse: den rapporterer den eksisterende gateway, og intet oprettes eller forbruges. At angive ingen adresse er også en gentagelse — en udeladt adresse betyder "behold den adresse, gatewayen har", så den giver aldrig noget en ny adresse. Kun en create, der angiver en anden adresse, afvises (GATEWAY_EXISTS); brug set-mode til det. Det er den samme regel, der får Terraform til at overtage en gateway, den ikke har oprettet.

• set-mode, der beder om det, gatewayen allerede har, gør ingenting og kræver intet --yes.

• set-mode uden --public-ip-id tager aldrig en adresse væk. At udelade det betyder "behold den adresse, gatewayen har", ikke "gå tilbage til standardadressen" — ellers ville ethvert værktøj, der aldrig har hørt om flaget, løsne fastgørelsen af din valgte adresse bag din ryg. At give en valgt adresse tilbage er bevidst og er beskrevet under Giv en valgt adresse tilbage.

• delete afslutter med en kode forskellig fra nul for et --vpc-id, den ikke kan bekræfte findes. Et tomt gateway-opslag ser ens ud for "denne VPC har ingen", "ukendt id" og "en anden tenants VPC" — så et afviklingsscript, der peger på et forældet eller fejlskrevet id, får at vide, at det intet gjorde, i stedet for at få besked om, at gatewayen er væk, mens den stadig er tilknyttet.

• Af samme grund siger get på en VPC uden gateway det i stedet for at fejle. Kombinér det med fm network vpc get <vpc-id>, som derimod rapporterer en VPC, der ikke findes.

Med Terraform

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

# Adressen, som udgående trafik ser ud til at komme fra. På en gateway uden
# public_ip_id er dette platformens adresse — læs den til fejlfinding, aldrig
# for at offentliggøre den.
output "gateway_source_address" {
  value = frostmoln_gateway.main.source_address
}

public_ip_id angiver den adresse, trafikken skal gå ud via, og det er det, du deklarerer, når adressen skal 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 valgfrit. Udelader du det, bruger gatewayen platformens standardadresse: VPC'en har udgående forbindelse, intet tildeles din tenant, og intet faktureres. Attributten forbliver null — platformen rapporterer intet id tilbage, fordi der ikke er nogen ressource af dine at rapportere.

• Pointen er at deklarere den som sin egen frostmoln_public_ip. Så overlever adressen gatewayen: destruér og genopret frostmoln_gateway.main eller hele VPC'en, og den samme frostmoln_public_ip tilknyttes igen med den samme adresse.

• At fjerne attributten igen giver ikke adressen tilbage. Terraform beholder den registrerede værdi og planlægger ingen ændring, fordi et udeladt public_ip_id betyder "behold det, du har", snarere end "gå tilbage til platformens adresse". Vil du flytte gatewayen over på en anden adresse, så angiv den anden adresse; vil du tilbage til platformens, se Giv en valgt adresse tilbage.

• En ændring af public_ip_id anvendes på stedet — aldrig som destruktion og genoprettelse. Den giver dog VPC'ens trafik en ny adresse og afbryder eksisterende forbindelser, så den kræver acknowledge_connectivity_loss = true.

• mode tager public_ip. Alt andet afvises, mens planen valideres, så en konfiguration, der stadig sætter det, fejler, før noget anvendes. Bemærk stavemåden: CLI'en accepterer også public-ip med bindestreg, så en værdi kopieret fra en CLI-kommando skal skrives om med understreg her.

• acknowledge_connectivity_loss er en valgfri boolesk værdi, der armerer ressourcen til en destruktion eller en ændring af public_ip_id. Udbyderen afviser begge uden den, før nogen anmodning sendes. Sæt den til true, kør apply, og destruér derefter eller foretag ændringen — og fjern linjen igen bagefter. Bliver den liggende, afvæbner den kontrollen i resten af ressourcens levetid: en senere terraform destroy -target, en fjernelse af et modul eller en ændring af vpc_id ville så afbryde VPC'ens forbindelse uden mere i planen end et almindeligt "will be destroyed".

• vpc_id er det, der tvinger en udskiftning frem — og den udskiftning destruerer den eksisterende gateway først, hvilket afvises, medmindre bekræftelsen allerede er anvendt.

• source_address, status og origin er skrivebeskyttede. Efter en ændring af public_ip_id registrerer platformen adressen på ny, så den planlægges som "(known after apply)".

• Importér med gatewayens id eller med VPC'ens id (en gateway uden en gemt registrering kan kun adresseres med VPC-id). En importeret gateway er aldrig forhåndsbekræftet.

  terraform import frostmoln_gateway.main vpc-abc123

Ordn tilknyttede adresser i forhold til gatewayen

En adresse, der er tilknyttet noget, kræver, at VPC'en har en gateway — men intet af det, der udfører tilknytningen, refererer til frostmoln_gateway, så Terraform ser ingen sammenhæng mellem dem og kører de to samtidigt. Det gælder frostmoln_public_ip (via dens instance_id), frostmoln_public_ip_association, frostmoln_load_balancer og frostmoln_kubernetes_cluster (public_ip_id). Begge kan vinde, og begge de forkerte rækkefølger gør ondt:

• Ved nedtagning kan gatewayen gå først, og dens sletning afvises så med GATEWAY_IN_USE — destruktionen standser halvvejs, med dele af stakken allerede væk.
• Ved oprettelse kan tilknytningen lande først, og så tilknytter platformen selv en gateway til at bære den. Din frostmoln_gateway støder derefter enten sammen med den (GATEWAY_EXISTS, hvis den angiver et public_ip_id) eller overtager den lydløst, som ovenfor.

Dette gælder, hvor gatewayen er en frostmoln_gateway-ressource i den samme konfiguration. En data "frostmoln_gateway" kan ikke bære rækkefølgen — en datakilde læses, den oprettes eller destrueres aldrig, så at afhænge af en udskyder blot en læsning og sætter intet i rækkefølge. Er gatewayen ikke din at håndtere, så importér den først.

Angiv rækkefølgen selv, på den ressource, der udfø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]
}

Den samme linje hører hjemme på hvilken som helst af de andre: en frostmoln_public_ip, hvis eget instance_id udfører tilknytningen, en frostmoln_load_balancer med scheme = "public", en frostmoln_kubernetes_cluster, der angiver et public_ip_id. Ligger gatewayen i et andet modul, så ret afhængigheden mod modulet: depends_on = [module.network].

Fire ting, der er værd at vide, før du kopierer den:

• Den hører hjemme på tilknytningen, ikke på tildelingen. En adresse, der kun er tildelt, afhænger af intet — og en adresse, der slås op med datakilden frostmoln_public_ip, har ingen tildelingsressource at hænge den på.
• Læg den aldrig på den adresse, dit frostmoln_gateway.public_ip_id angiver. Gatewayen afhænger allerede af den adresse, så en afhængighed den anden vej er en Cycle:-fejl allerede ved plan. Den adresse er allerede ordnet rigtigt.
• Skriv den aldrig den modsatte vej — på gatewayen, med adresserne opregnet. Det er den fristende fejl, fordi det er gatewayen, der skal findes først; men depends_on ordner den ressource, den står på, så det vender begge rækkefølger om og gør et kapløb, der nogle gange gik godt, til en nedtagning, der fejler hver gang.
• Den ændrer kun rækkefølgen. Intet oprettes, og intet frigives — og den armerer ikke gatewayens egen destruktion, som stadig kræver acknowledge_connectivity_loss først.

Er en gateway allerede blevet overtaget, er origin afsløreren: den står som implicit_public_ip eller vpc_create i stedet for explicit, og source_address er en adresse, du aldrig har valgt. Du behøver hverken at importere eller bygge noget om — ressourcen er allerede i state. Tilføj rækkefølgen, så det ikke kan gentage sig, og giv derefter gatewayen den adresse, du mente, ved at sætte public_ip_id, hvilket anvendes på stedet og kræver acknowledge_connectivity_loss = true.

Vil du læse en gateway, du ikke håndterer — en, der blev valgt ved oprettelsen af VPC'en, eller som blev tilknyttet, da en offentlig IP-adresse blev tilknyttet — så brug datakilden:

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

# Tryg at give til en partner KUN hvis denne gateway har et public_ip_id. Uden et
# sådant er værdien platformens adresse, som trækkes på ny ved en genopbygning.
output "gateway_source_address" {
  value = data.frostmoln_gateway.production.source_address
}

Vælg den adresse, gatewayen bruger

Hver Gateway har én kildeadresse. Den er enten platformens eller en af dine offentlige IP-adresser — den samme ressource, som du selv tildeler, lister og frigiver. Du bestemmer hvilken:

• Angiv en adresse, du har. Tildel en offentlig IP-adresse (eller genbrug en, der er available), og angiv den, når du opretter gatewayen, eller peg en eksisterende gateway på den. Den adresse står på din liste over offentlige IP-adresser, tæller mod din kvote, faktureres som en offentlig IP-adresse og fastgøres på gatewayen.
• Eller angiv ingen. Gatewayen tager platformens adresse. Intet tildeles dig, intet opføres på en liste, ingen kvote trækkes, og intet faktureres — og adressen er ikke fast.

Hvorfor angive adressen selv

Fordi adressen så er en ressource, der er din, overlever den gatewayen. Fjern Gatewayen, eller slet VPC'en og byg den op igen fra bunden: den offentlige IP-adresse forbliver tildelt din tenant, beholder sit id og beholder sin adresse, og at pege den nye gateway på den genskaber præcis den adresse, du havde før.

Det er det, der gør adressen tryg at give ud:

• til en partner eller leverandør, der sætter den adresse, din trafik kommer fra, på en tilladelsesliste,
• til en kunde, hvis firewall kun accepterer kendte kilder,
• i en DNS-post, du offentliggør.

Platformens standardadresse giver intet sådant løfte. Den er ikke din, den står på ingen liste, den trækkes på ny, hvis gatewayen eller VPC'en bygges op igen, og den overlever ikke gatewayen. Giv den aldrig til nogen, der har til hensigt at sætte den på en tilladelsesliste, og offentliggør den aldrig.

Giv en valgt adresse tilbage

Den anden vej — fra en af dine egne offentlige IP-adresser tilbage til platformens adresse — er bevidst, fordi ingen klient kan gøre det ved et uheld. At udelade adressen læses som "behold det, du har", så vejen tilbage er at fjerne gatewayen og oprette den igen uden at angive en adresse:

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

Den offentlige IP-adresse vender tilbage til din liste med id og adresse intakt, som en available adresse, du stadig har — at frigive den er en separat og permanent handling. Mellem de to kommandoer har VPC'en ingen udgående internetadgang, intet DNS og ingen forbindelse til administrerede tjenester, så behandl det som et kort vedligeholdelsesvindue.

Mens adressen er tilknyttet en gateway

En offentlig IP-adresse, der er i brug af en Gateway, er optaget, så:

• den kan ikke tilknyttes en instans — giv den instans en anden adresse, og
• den kan ikke frigives — at frigive den giver adressen fra sig for bestandigt, hvilket er netop det, gatewayen er der for at forhindre.

Frakobl den først, så bliver begge dele mulige igen. At frakoble betyder: peg gatewayen på en anden offentlig IP-adresse, eller fjern gatewayen. Adressen bliver derefter en helt almindelig available offentlig IP-adresse af dine egne igen — stadig tildelt din tenant og stadig talt med i din kvote, indtil du frigiver den.

Den tilsidesætter ikke en instans' egen offentlige IP-adresse

En instans, der har sin egen offentlige IP-adresse, går fortsat ud via den adresse. Gatewayens adresse er kun kilde for trafik fra instanser, der ingen har. At vælge en adresse til gatewayen ændrer altså intet ved, hvordan dine offentligt eksponerede instanser fremstår udadtil.

Gør gatewayens adresse til din egen

En gateway på platformens standardadresse kan få præcis den adresse lavet om til en offentlig IP-adresse, du ejer, uden at adressen ændrer sig. Det er den ene handling på denne side, der intet ændrer ved din trafik:

• Adressen forbliver præcis den samme. Intet flyttes, og intet genstartes; der er ingen afbrydelse.
• Bagefter optræder den på din liste over offentlige IP-adresser og er fastgjort, så den overlever, at Gatewayen eller VPC'en genoprettes — det samme løfte som ved selv at angive en adresse.
• Fra da af tæller den mod din kvote for offentlige IP-adresser og faktureres som en offentlig IP-adresse. Det er hele grunden til, at dette er dit valg og ikke noget, der gøres for dig.

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

I portalen tilbyder VPC'ens panel Gateway valget Gør denne adresse til min.

Det er det rigtige træk, når en adresse, du aldrig var ment at offentliggøre, allerede er blevet offentliggjort — det er den eneste vej fra standardadressen til en fast adresse, der ikke ændrer adressen, så tilladelseslister og DNS-poster, der allerede bærer den, fortsat virker.

At overtage to gange er harmløst — anden gang ændrer intet og rapporterer den samme adresse. Det gælder kun en gateway, der ikke allerede går ud via en offentlig IP-adresse, du har valgt; en, der gør det, har intet at overtage.

Hvad en gateway fortæller dig

Felt	Betydning
Kildeadresse	Den offentlige adresse, som udgående trafik ser ud til at komme fra. Tryg at sætte på en tilladelsesliste kun, når en offentlig IP-adresse vises nedenfor; ellers er den platformens, og den ændrer sig. Tom, så længe adressen endnu ikke er kendt.
Offentlig IP	Den offentlige IP-adresse, gatewayen går ud via, når du har angivet en. Dens adresse er kildeadressen, og den forbliver din, når gatewayen forsvinder. Tom betyder, at gatewayen bruger platformens standardadresse — den, du ikke må offentliggøre.
Status	Observeret fra platformen, ikke fra gemte indstillinger: active eller detached.
Ophav	Hvem der bad om gatewayen (nedenfor).

Værdier for ophav:

• explicit — oprettet direkte, via portalen, CLI'en, Terraform eller API'en, uden at der blev angivet en adresse.
• explicit_public_ip — oprettet direkte, ligesom explicit, og den offentlige IP-adresse, den går ud via, blev angivet af dig. Holdt adskilt, fordi den adresse er din egen ressource: den gives tilbage til dig i stedet for til platformen, når gatewayen slipper den.
• implicit_public_ip — tilføjet af platformen, fordi en offentlig IP-adresse blev tilknyttet i denne VPC. Indgående og udgående deler samme vej, så at tilknytte en offentlig IP-adresse i en VPC, der ingen gateway havde, giver den en.
• vpc_create — den fulgte med VPC'en, fra et forbindelsesvalg, der blev truffet, da VPC'en blev oprettet. Kun det valg registrerer dette ophav.
• legacy — ukendt. Der findes ingen registrering af, hvem der bad om denne gateway. Det skyldes som regel, at VPC'en er ældre end ressourcen, men ikke altid — læs det som "ukendt", aldrig som "gammelt".

Ændring af kildeadressen

At pege en gateway på en anden af dine offentlige IP-adresser anvendes på stedet: gatewayen beholder sin identitet, og intet destrueres og genoprettes. Det er dog en afbrydelse — ikke en lydløs udskiftning i drift:

• Kildeadressen ændrer sig. Alt, der har din gamle adresse på en tilladelsesliste, holder op med at acceptere din trafik, indtil den nye er tilføjet hos modparten. Fordi du selv angiver den nye adresse, er dette det ene tilfælde, hvor du kender den på forhånd.
• Igangværende forbindelser afbrydes. Sessioner, der er åbne hen over ændringen, brydes og skal forbinde igen.
• Den kræver en udtrykkelig bekræftelse, og det er netop det, den bekræfter: den ændrede kildeadresse og de afbrudte forbindelser.

Dette er ikke en fjernelse. Selve internetadgangen fortsætter, og DNS og forbindelsen til administrerede tjenester indgår ikke i det, ændringen koster.

At angive en adresse bruger én adresse af din tenants kvote og sætter den på din faktura som en offentlig IP-adresse. Den adresse, du peger væk fra, frakobles: den forbliver tildelt din tenant, beholder sin adresse og bliver available igen, så et senere skift tilbage kan bruge nøjagtig den samme adresse.

• Portalen — VPC'ens Gateway-panel, og bekræft derefter.

• CLI'en:

  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, ændr derefter public_ip_id, og kør apply igen, og fjern så bekræftelseslinjen.

Behandl det som et kort vedligeholdelsesvindue. Platformen reserverer det, ændringen kræver, før den tager den gamle adresse ned, så hvis den ikke kan gennemføres, afvises den, og VPC'en efterlades præcis, som den var.

Fjern en Gateway

Dette fjerner også DNS og forbindelsen til administrerede tjenester

VPC'en mister udgående internetadgang, navneopslag og forbindelse til administrerede tjenester samtidig. Ressourcer indeni kører videre; alt, der slår et navn op eller taler med en administreret tjeneste, holder op med at virke.

• Portalen — Fjern Gateway på VPC'en, og bekræft derefter.

• CLI'en — --yes er bekræftelsen, og kommandoen nægter uden det:

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

• Terraform — sæt acknowledge_connectivity_loss = true, og kør apply, fjern derefter ressourcen (eller kør terraform destroy). Uden at den er anvendt først, fejler destruktionen i stedet for lydløst at afbryde VPC'ens forbindelse.

Fjernelsen afvises, så længe offentlige IP-adresser i VPC'en stadig afhænger af gatewayen. Frakobl dem først — det er gratis, kan fortrydes og er nok til at bestå kontrollen:

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

At frigive dem består kontrollen også, men at frigive er permanent: adressen går tilbage til platformen, gives ud igen til den næste, der beder om en, og du kan ikke få den tilbage. Frigiv kun en adresse, du er sikker på, at du aldrig får brug for.

At slette selve VPC'en fjerner dens gateway sammen med den.

Gatewayens egen adresse er ikke en af de blokerende. Er det en offentlig IP-adresse, der er din, frakobles den for dig, når gatewayen forsvinder, og forbliver tildelt din tenant som en available offentlig IP-adresse med den samme adresse — at fjerne gatewayen giver den ikke bort, det gør kun en frigivelse af den offentlige IP-adresse. Er det platformens standardadresse, følger den ganske enkelt med gatewayen; der var aldrig noget af dit at beholde.

Én undtagelse, på ældre VPC'er. En gateway, hvis Ophav er vpc_create, kan holde en offentlig IP-adresse, som platformen tildelte, da VPC'en blev oprettet — fra før det at angive en adresse blev den eneste måde at få en af sine egne på. Du har aldrig bedt om en stående adresse, så netop den frigives, når gatewayen fjernes, i stedet for at ligge tildelt og blive faktureret. At frigive er permanent. Betyder den adresse noget for nogen uden for din VPC, så notér den, før du fjerner gatewayen.

Hvis en anmodning afvises

Hver afvisning bærer en maskinlæsbar kode ved siden af meddelelsen. Match på koden, ikke på meddelelsen — formuleringen må gerne forbedres, det må koden ikke. Alle disse koder blev omdøbt sammen med ressourcen: det, der før stod som EGRESS_*, står nu som GATEWAY_*, og intet svarer på den gamle stavemåde.

Det, du ser	Kode	Hvad det betyder
VPC'en har allerede en Gateway	GATEWAY_EXISTS	En VPC har højst én. Skift den adresse, den bruger, i stedet for at tilføje en nummer to. I Terraform udløses dette kun, når ressourcen angiver et public_ip_id; en, der ikke angiver noget, overtager lydløst den eksisterende gateway — se Ordn tilknyttede adresser i forhold til gatewayen.
Offentlige IP-adresser afhænger stadig af gatewayen	GATEWAY_IN_USE	Frakobl VPC'ens offentlige IP-adresser — gratis og kan fortrydes — og fjern derefter gatewayen. At frigive dem virker også, men er permanent. I Terraform er dette som regel et rækkefølgeproblem — se Ordn tilknyttede adresser i forhold til gatewayen — medmindre en håndteret ressource i VPC'en holder adressen, hvilket meddelelsen så siger.
Der er ingen offentlige adresser tilgængelige i denne region	GATEWAY_POOL_EXHAUSTED	En kapacitetsgrænse hos platformen, ikke din kvote — at bede om mere kvote hjælper ikke. Prøv igen senere.
Din kvote for offentlige IP-adresser er opbrugt	en kvotefejl, ikke en gateway-fejl	Kun det at angive en adresse — eller at overtage en — trækker på kvoten, så dette blokerer aldrig en gateway på standardadressen. Frigiv en adresse, du ikke bruger, eller bed om mere kvote.
Den offentlige IP-adresse kan ikke bruges som kildeadresse	GATEWAY_PUBLIC_IP_UNAVAILABLE	Den adresse, du angav, er tilknyttet en instans eller en lastbalancer, er allerede tilknyttet en anden VPC's gateway, eller er ikke en adresse, der kan bære en VPC's trafik. Frigør den, eller vælg en anden. Meddelelsen angiver, hvilken af de tre det er.
Fjernelsen af gatewayen blev ikke bekræftet	GATEWAY_LOSS_NOT_ACKED	Fjernelsen tager internet, DNS og forbindelsen til administrerede tjenester med sig, så den skal angives udtrykkeligt: --yes på CLI'en, acknowledge_connectivity_loss = true i Terraform.
Tilstandsskiftet blev ikke bekræftet	GATEWAY_MODE_SWITCH_NOT_ACKED	Et tilstandsskift giver VPC'en en ny adresse og afbryder åbne forbindelser. Adskilt fra fjernelse, fordi du kommer online igen i stedet for at blive mørklagt.
Ændringen af kildeadressen blev ikke bekræftet	GATEWAY_SOURCE_ADDRESS_CHANGE_NOT_ACKED	At pege gatewayen på en anden offentlig IP-adresse ændrer den adresse, modparten ser, og afbryder igangværende forbindelser; bekræft det på samme måde.
Den offentlige IP-adresse holdes af en gateway	PUBLIC_IP_IN_USE_BY_GATEWAY	Returneres på den offentlige IP-adresse, ikke på gatewayen: en adresse, en gateway går ud via, kan hverken tilknyttes en instans eller frigives. Frakobl den fra gatewayen først.

Relateret

• VPC'er · Offentlige IP-adresser · Sikkerhedsgrupper