Sub-redes

Console
API
CLI
Go

Vá para Networking → Subnets e escolha Create Subnet. Em Subnet details, escolha o VPC e preencha Name e CIDR. Gateway IP é opcional e é o padrão para você.Em Routing, Route Table começa na tabela padrão da VPC. Este é o único campo que vale a pena decidir aqui ao invés de mais tarde — veja public and private are routing.

POST /v1/subnets
{
  "vpc": "5f8d3a2e-1c4b-4e7a-9f6d-2b1a8c3e5d7f",
  "name": "prod-web",
  "cidr_ipv4": "10.0.1.0/24"
}

basaltic network subnet create --vpc <vpc-id> \
  --name prod-web --cidr-ipv4 10.0.1.0/24

Adicione --cidr-ipv6 para uma sub-rede de pilha dupla, e --route-table para aterrissar em algum lugar diferente da tabela padrão.

sub, err := network.New(cfg).CreateSubnet(ctx, &network.SubnetCreateRequest{
    VPC: vpcID,
    Name:  "prod-web",
    CIDRIPv4:  "10.0.1.0/24",
})

A entrada vpc aceita um UUID, CRN ou nome exato de escopo de conta. O opcional route_table aceita um UUID, um CRN aninhado ou um nome dentro dessa VPC; omitir seleciona a tabela padrão, chamada <vpc-name>-private-rt. Uma referência vazia é inválida. Um CRN de sub-rede inclui seu pai: crn:network:sa-saopaulo-1:my-account:vpc/prod/subnet/public. As listas aceitam filtros exatos name e crn. Filtrar sub-redes por nome também requer vpc; filtrar interfaces por nome requer subnet. Os filtros se combinam, e uma pesquisa com falha nunca tenta uma interpretação diferente da referência.

Posicionamento de leitura

As respostas de sub-rede incluem a VPC pai completa em vpc e um resumo de route_table contendo id, crn e name. Use vpc.id e vpc.name para colocação, e route_table.id e route_table.name para links de roteamento; leituras separadas são desnecessárias apenas para exibir esses nomes. Esses embeds substituem os antigos campos de resposta vpc_id e route_table_id. route_table pode ser nulo quando sua pesquisa não é mais resolvida, como durante a reassociação simultânea e exclusão da tabela anterior. Trate isso como um posicionamento indisponível: atualize antes de agir sobre a associação. Isso não significa que a sub-rede é privada ou usa a tabela padrão. O relacionamento VPC é necessário. As solicitações ainda usam referências de string. Para reutilizar uma relação embutida em uma solicitação de criação ou atualização, passe seu id (ou um CRN/nome suportado), não o objeto embutido. Em Go, verifique o sumário nullável antes de ler seu ID:

if sub.RouteTable != nil {
    fmt.Println(sub.RouteTable.ID, sub.RouteTable.Name)
}

O CIDR deve estar totalmente dentro do CIDR da VPC pai da mesma família e não deve sobrepor outra sub-rede na mesma VPC. O name é exclusivo por VPC. gateway_ipv4 é o primeiro endereço após o endereço de rede (10.0.1.1 em um 10.0.1.0/24). Você pode fornecer o seu próprio, desde que esteja dentro do CIDR. cidr_ipv4 e gateway_ipv4 são imutáveis. description, tags e route_table não são.

Público e privado estão roteando, não um sinalizador

Não há nenhum boolean public em uma sub-rede. Uma sub-rede é pública quando a tabela de rotas que ela usa tem uma rota 0.0.0.0/0 apontando para um gateway de internet, e privada caso contrário. O route_table.id da sub-rede identifica essa tabela, então mover uma sub-rede entre as duas posições é um PATCH que a re-associa com uma tabela diferente:

Console
API
CLI
Go

Abra a guia Settings da sub-rede. Em Routing, escolha uma tabela e selecione Change route table. Atualize se a associação atual não estiver disponível.

PATCH /v1/subnets/{subnet_id}
{ "route_table": "a3c9e1f4-7b2d-4a6e-8c1f-9d3b5e7a2c4f" }

basaltic network subnet update <subnet-id> --route-table private

sub, err := network.New(cfg).UpdateSubnet(ctx, subnetID, &network.SubnetUpdateRequest{
    RouteTable: basaltic.String("private"),
})

Mover uma sub-rede altera a postura de todas as instâncias já em execução nela, imediatamente — não apenas as criadas posteriormente. Mover uma sub-rede para uma tabela com uma rota padrão para um gateway de internet é o que a torna pública; movê-la para fora é o que a tira.

Tudo sobre quais rotas existem vive na página routing.

Quais endereços você realmente recebe

Três endereços em uma sub-rede IPv4 estão indisponíveis: o endereço de rede, o endereço de difusão e o gateway. Um /24 deixa 253 utilizável — nada é retido para DNS ou metadados de instância, porque o ponto final de metadados é o link-local 169.254.169.254 ao invés de um endereço dentro da sua sub-rede. A alocação automática toma o endereço livre mais baixo acima do gateway. Se você fornecer um address IPv4 na requisição de addresses de uma interface, ele é verificado contra tudo: dentro do CIDR, não a rede ou o endereço de broadcast, e não já ocupado — seja por outra interface ou mantido por outro recurso, como o VIP de um balanceador de carga.

Sub-redes de pilha dupla

A VPC deve possuir um prefixo IPv6. Cada sub-rede de pilha dupla usa um /64; um /60 público fornece dezesseis, enquanto alocações de ULA privadas maiores fornecem mais.

Console
API
CLI
Go

Em Create Subnet, selecione uma VPC com IPv6. Em IPv6, escolha Automatic IPv6 /64 para atribuir um prefixo livre. O formulário começa com IPv4 only. Para escolher um prefixo específico, selecione Manual IPv6 /64 e digite IPv6 CIDR.O IPv6 é desabilitado quando a VPC selecionada não tem prefixo IPv6. Alterar a VPC ou região limpa a seleção de IPv6.

Solicitar atribuição automática sem nomear um prefixo:

POST /v1/subnets
{
  "vpc": "5f8d3a2e-1c4b-4e7a-9f6d-2b1a8c3e5d7f",
  "name": "prod-web",
  "cidr_ipv4": "10.0.1.0/24",
  "allocate_cidr_ipv6": true
}

Para escolher um /64 específico, substitua "allocate_cidr_ipv6": true por "cidr_ipv6": "2a13:9500:1a6:100::/64", usando um prefixo livre dentro do cidr_ipv6 da sua VPC. Não envie ambos. Omita ambos para uma sub-rede somente IPv4.

Nomeie um /64 livre dentro da sua VPC:

basaltic network subnet create --vpc <vpc-id> \
  --name prod-web --cidr-ipv4 10.0.1.0/24 --cidr-ipv6 2a13:9500:1a6:100::/64

Para atribuição automática, substitua --cidr-ipv6 e seu valor por --allocate-cidr-ipv6.

Nomeie um /64 livre dentro da sua VPC:

cidrV6 := "2a13:9500:1a6:100::/64"
sub, err := network.New(cfg).CreateSubnet(ctx, &network.SubnetCreateRequest{
    VPC:  vpcID,
    Name:   "prod-web",
    CIDRIPv4:   "10.0.1.0/24",
    CIDRIPv6: &cidrV6,
})

Para atribuição automática, substitua CIDRIPv6 por AllocateCIDRIPv6: basaltic.Bool(true).

A atribuição automática seleciona o menor /64 livre, incluindo prefixos liberados pela exclusão de uma sub-rede. Os prefixos explícitos devem ser /64s dentro da VPC e não podem se sobrepor a outra sub-rede. O gateway IPv6 é o endereço ::1 do prefixo. Quando todos os prefixos disponíveis estão ocupados, a criação retorna HTTP 409 com “VPC não tem IPv6 /64s livre”. Exclua uma sub-rede não usada ou use outra VPC. Um 409 mencionando a disputa de alocação significa que solicitações concorrentes reivindicaram prefixos durante a criação; tente novamente a solicitação.

Habilitando o IPv6 mais tarde

A VPC já deve ter IPv6. Depois que um prefixo de sub-rede é definido, ele não pode ser substituído ou removido. Ao ativá-lo, o IPv6 é adicionado a todas as interfaces existentes, preservando os endereços IPv4. Um gateway NAT hospedado nessa sub-rede também recebe seu endereço IPv6 público, mesmo que você deixe o roteamento inalterado.

Console
API
CLI
Go

Abra a sub-rede e escolha Enable IPv6. Deixe IPv6 CIDR (optional) vazio para alocação automática. Copy matching IPv4 security rules é selecionado por padrão. Em IPv6 internet routing, mantenha Match IPv4 routing ou escolha o gateway necessário ou Leave routing unchanged. Confirme com Enable IPv6.

PATCH /v1/subnets/{subnet_id}

{
  "allocate_cidr_ipv6": true,
  "copy_ipv4_security_rules": true,
  "ipv6_routing": "match_ipv4"
}

Substitua allocate_cidr_ipv6 por cidr_ipv6 para escolher um /64 específico.

basaltic network subnet update <subnet-id> \
  --allocate-cidr-ipv6 --ipv6-routing match_ipv4

Adicione --copy-ipv4-security-rules=false para manter as regras de grupo de segurança inalteradas.

subnet, err := network.New(cfg).UpdateSubnet(ctx, subnetID, &network.SubnetUpdateRequest{
    AllocateCIDRIPv6:      basaltic.Bool(true),
    CopyIPv4SecurityRules: basaltic.Bool(true),
    IPv6Routing:          basaltic.String("match_ipv4"),
})

A cópia de regra preserva protocolo, portas e direção. Ele copia 0.0.0.0/0 para ::/0 e copia referências de grupo de segurança. CIDRs IPv4 restritos não têm equivalente IPv6 automático e permanecem inalterados. As regras IPv6 equivalentes existentes não são duplicadas. As alterações afetam todas as interfaces que compartilham esses grupos. match_ipv4 adiciona ::/0 através da mesma internet ou gateway NAT como a rota padrão IPv4. Sem uma rota padrão IPv4, o IPv6 permanece isolado. As rotas padrão IPv6 existentes são sempre preservadas. Você também pode selecionar internet_gateway, nat_gateway, egress_only_gateway, ou unchanged. Uma rota NAT IPv6 requer IPv6 na sub-rede de hospedagem do gateway NAT primeiro. Os gateways somente de saída fornecem saída GUA nativa; o acesso à Internet ULA precisa de NAT. As alterações de rota afetam todas as sub-redes que compartilham a tabela. O programa de instalação verifica permissões e cotas antes de confirmar alterações. Copiar regras requer network:CreateSecurityGroupRule; adicionar rotas requer network:CreateRoute; criar um gateway somente de saída requer network:CreateEgressOnlyGateway. Atualizar um gateway NAT hospedado requer network:UpdateNATGateway e cota IPv6 pública disponível. cidr_ipv6 na resposta é como um cliente separa os dois: é nulo em uma sub-rede somente v4 e definido em uma de pilha dupla, ao lado de gateway_ipv6. Novas interfaces em uma sub-rede de pilha dupla recebem uma alocação /96 automaticamente, com seu primeiro /128 fornecido através do DHCPv6.

Um prefixo IPv6 na sub-rede e um endereço na NIC não tornam qualquer coisa acessível. A alcançabilidade IPv6 também depende de rotas e regras de grupo de segurança — veja a alcançabilidade IPv6 é a rota.

Excluir uma sub-rede

Três coisas o bloqueiam, e o erro nomeia o que o fez:

Bloqueador de anúncios	O que o erro diz
Interfaces ainda na sub-rede	”a sub-rede ainda tem N interface(s) — exclua-as primeiro”
Um gateway NAT vive aqui	”gateway NAT de hosts de sub-rede nome — exclua-o primeiro”
Um endereço é mantido por outro recurso	nomes do endereço e do titular

O terceiro é o mais surpreendente. O VIP de um balanceador de carga é mantido dentro da sub-rede sem ser uma interface. O delete recusa em vez de soltar o endereço abaixo do recurso que o possui.

Primeiros passos

Produtos

Plataforma

Ajuda

Posicionamento de leitura

Público e privado estão roteando, não um sinalizador

Quais endereços você realmente recebe

Sub-redes de pilha dupla

Habilitando o IPv6 mais tarde

Excluir uma sub-rede

​Posicionamento de leitura

​Público e privado estão roteando, não um sinalizador

​Quais endereços você realmente recebe

​Sub-redes de pilha dupla

​Habilitando o IPv6 mais tarde

​Excluir uma sub-rede

Posicionamento de leitura

Público e privado estão roteando, não um sinalizador

Quais endereços você realmente recebe

Sub-redes de pilha dupla

Habilitando o IPv6 mais tarde

Excluir uma sub-rede