> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# VPCs
> Crie uma VPC com IPv4, IPv6 público ou privado, sub-redes e acesso à Internet.
Vá para **Networking → VPCs** e escolha **Create VPC**. Em **VPC
details**, dê a ele um **Name** e um **IPv4 CIDR**.
A página é um fluxo de trabalho em vez de uma única criação. **Subnets** pergunta quantas **Public subnets** e **Private subnets** para esculpir fora desse CIDR e permite que você edite cada **Name** e **IPv4 CIDR** gerado. Quando o IPv6 está habilitado, cada sub-rede planejada também tem um campo **IPv6 CIDR**: automático para GUA público, editável para ULA privado.
**Internet access** oferece um **Internet gateway**, um **NAT gateway** e um **Egress-only gateway** quando IPv6 e sub-redes privadas são selecionadas. A opção de saída somente requer GUA. Ele cria o gateway e uma rota `::/0` na tabela de rotas padrão das sub-redes privadas, mesmo quando o plano não tem sub-redes públicas. Com NAT e somente saída selecionados, o IPv4 usa NAT e o IPv6 usa roteamento nativo somente de saída. Com NAT sozinho, ambas as famílias habilitadas usam NAT. Ao enviar, você será direcionado para uma página de **Provisioning progress** que percorre o plano passo a passo: **Create VPC**, **Create public route table**, **Create internet gateway**, **Attach internet gateway**, **Configure
public internet route**, depois um passo por sub-rede e **Create NAT
gateway** com **Configure private internet route**, se você tiver solicitado NAT.
Essa sequência é executada no seu navegador, e é por isso que a página diz **Keep
this page open until provisioning finishes.** Navegue para longe no meio da execução e o que já foi criado permanece, mas as etapas restantes nunca acontecem. Volte para a mesma página de progresso e ela oferece **Retry
failed step**, retomando de onde parou.
```bash theme={null}
POST https://network.sa-saopaulo-1.basaltic.sh/v1/vpcs
{
"name": "prod",
"cidr_ipv4": "10.0.0.0/16"
}
```
Uma chamada, uma VPC. As sub-redes, gateway e rotas que o fluxo de trabalho do console adiciona são chamadas separadas que você faz — veja [gateways](/pt/networking/gateways) e [routing](/pt/networking/routing).
```bash theme={null}
basaltic network vpc create --name prod --cidr-ipv4 10.0.0.0/16
```
```go theme={null}
v, err := network.New(cfg).CreateVPC(ctx, &network.VPCCreateRequest{
Name: "prod",
CIDRIPv4: "10.0.0.0/16",
})
```
`name` é de 1 a 63 caracteres, letras minúsculas, dígitos e hífens, e não pode começar ou terminar com um hífen. É exclusivo por conta e chega no CRN da VPC.
A criação de uma VPC também cria sua tabela de rota padrão `-private-rt`. As sub-redes usam-na a menos que você selecione outra tabela.
## O CIDR deve ser privado
`cidr_ipv4` tem que estar dentro de `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`. A razão não é a limpeza: endereçar suas instâncias fora do espaço roteável que você não possui criaria um buraco negro nesse espaço para suas próprias cargas de trabalho e para qualquer outra pessoa, uma vez que a VPC roteia para qualquer lugar. A alcançabilidade pública vem de [um IP flutuante](/pt/networking/floating-ips) ou um [gateway](/pt/networking/gateways), nunca do próprio endereço IPv4 da instância.
O **prefixo inteiro** tem que estar dentro de um bloco privado, não apenas o primeiro endereço. `10.0.0.0/7` começa em RFC 1918 e se estende para fora dele, então ele é rejeitado.
`name` e `cidr_ipv4` são imutáveis. `PATCH /v1/vpcs/{vpc_id}` recebe `description`, `tags`, e uma alocação IPv6 inicial. CIDRs existentes não podem ser redimensionados.
## Alocação de IPv6
Em **Create VPC**, em **VPC details**, defina **IPv6** como **Automatic public
IPv6 (GUA)** ou **Manual private IPv6 (ULA)**.
O GUA aloca uma VPC `/60` e uma distinta `/64` para cada sub-rede planejada. O **IPv6 CIDR** de cada sub-rede mostra **Automatically allocated /64**; o intervalo real é atribuído durante a criação. Um `/60` contém dezesseis `/64`s.
Para ULA, **VPC IPv6 CIDR** começa com um `/48` privado gerado, e cada sub-rede **IPv6 CIDR** começa com um `/64` distinto desse intervalo. Mantenha as sugestões ou edite-as. Cada sub-rede deve ter um `/64` alinhado dentro do intervalo da VPC e os intervalos não devem se sobrepor.
Alterar o CIDR IPv6 da VPC regenera os intervalos IPv6 da sub-rede. Alterar as contagens de sub-rede ou escolher **Regenerate** repõe os intervalos de sub-rede de ambas as famílias para suas sugestões. O formulário valida-os antes de provisioná-los. A saída da Internet ULA precisa de NAT; a opção somente saída está desabilitada.
Você também pode ativar o IPv6 mais tarde na página de detalhes da VPC.
```bash theme={null}
POST /v1/vpcs
{ "name": "prod", "cidr_ipv4": "10.0.0.0/16", "allocate_cidr_ipv6": true }
```
```bash theme={null}
basaltic network vpc create --name prod --cidr-ipv4 10.0.0.0/16 \
--allocate-cidr-ipv6
```
```go theme={null}
v, err := network.New(cfg).CreateVPC(ctx, &network.VPCCreateRequest{
Name: "prod",
CIDRIPv4: "10.0.0.0/16",
AllocateCIDRIPv6: basaltic.Bool(true),
})
```
`allocate_cidr_ipv6` delega um `/60` roteável globalmente do pool da região e o retorna como o `cidr_ipv6` da VPC. Sub-redes então esculpem `/64`s fora dele. O assistente de VPC habilita o IPv6 em todas as suas sub-redes planejadas. As sub-redes criadas de forma independente podem permanecer somente IPv4, o que é útil ao migrar cargas de trabalho em estágios ou ao manter deliberadamente uma sub-rede em uma família de endereços. As interfaces de uma sub-rede sempre herdam todas as famílias habilitadas nessa sub-rede.
Alternativamente, forneça um prefixo ULA privado em `cidr_ipv6`: um prefixo canônico dentro de `fd00::/8`, de `/48` até `/60`. Não envie junto com `allocate_cidr_ipv6`. Escolha um prefixo ULA gerado aleatoriamente para reduzir o risco de colisão se as redes forem conectadas posteriormente.
Uma VPC somente IPv4 existente aceita qualquer uma das opções por meio de `PATCH /v1/vpcs/{vpc_id}`. Uma vez atribuído, o CIDR IPv6 não pode ser substituído ou removido. As sub-redes existentes permanecem inalteradas até que o IPv6 seja ativado nelas.
Se a região não tiver um pool IPv6 público, a alocação pública automática falhará. O endereçamento ULA não se torna roteável pela Internet ao adicionar uma rota da Internet. Use um gateway NAT para acesso de saída compartilhado ou um IP flutuante IPv6 público quando uma NIC endereçada por ULA precisar de sua própria identidade pública. Uma NIC com um endereço global nativo pode usar esse endereço diretamente quando o roteamento e as regras de segurança permitirem; nenhum IP flutuante é necessário.
## Pools IPv4 roteados
Uma VPC pode reservar até quatro pools de prefixo IPv4 dentro do `cidr_ipv4`. Os pools não devem sobrepor sub-redes ou um ao outro. Gerencie-os através de `/v1/vpcs/{vpc_id}/prefix-pools`. Cada pool tem um ID e `cidr_ipv4`.
As interfaces alocam prefixos `/28` desses pools através de `/v1/interfaces/{interface_id}/prefixes`, usando `pool_id`. Uma NIC pode conter até 16 prefixos roteados, retornados separadamente como `routed_prefixes`. Os prefixos roteiam para essa NIC; eles não são entradas de endereço de convidado individuais ou concessões DHCP. O convidado configura cargas de trabalho e roteamento para o intervalo delegado. Esse é um bloco de construção de rede, não um serviço gerenciado do Kubernetes.
## Excluir uma VPC
O delete se recusa em dois casos, cada um nomeando o que o está segurando:
* **As sub-redes permanecem.** "O VPC tem sub-redes; exclua-as primeiro."
* **Um gateway de internet ainda está conectado.** "O VPC tem um gateway de internet conectado; desconecte-o primeiro."
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.