BYOIP na Exoscale: usar os seus próprios endereços IP na Exoscale

A Exoscale nada publica sobre trazer os seus próprios endereços IP. A 15 de outubro de 2026 lemos a sua documentação, as suas FAQ e a sua página de preços, e nenhuma delas menciona endereços do cliente. A documentação só descreve os da própria Exoscale. Cada instância é aprovisionada com "a native IPv4 address, leased from a global pool and intrinsically tied to the Compute instance" (tradução: «um endereço IPv4 nativo, cedido a partir de um pool global e intrinsecamente ligado à instância Compute»). Os Elastic IPs acrescentam endereços estáticos que a Exoscale cria para a sua organização, cinco por defeito, associados a instâncias dentro de uma zona.

O Private Connect, a ligação dedicada da Exoscale às suas redes privadas, não resolve isto. As suas FAQ perguntam se a Exoscale pode anunciar o seu intervalo IP aos seus routers por BGP, e respondem: "No, Private Connect is a pure Layer 2 connection to your router. No routing is done inside of Exoscale." (tradução: «Não, o Private Connect é uma ligação puramente de camada 2 ao seu router. Não é feito nenhum encaminhamento dentro da Exoscale.»)

O caminho do túnel

Uma rede que possa anunciar o bloco anuncia-o, e um túnel GRE ou WireGuard leva o tráfego até à sua instância Exoscale e de volta (como funciona o túnel). A instância mantém o endereço IPv4 nativo que a Exoscale lhe deu, e esse endereço é a ponta exterior do túnel. O bloco alugado chega dentro do túnel. Configura os seus endereços na interface do túnel ou de loopback, e a instância responde neles como se fossem locais. A rede da Exoscale só vê tráfego entre dois endereços públicos.

• Use o endereço nativo para o túnel. A Exoscale diz que os Elastic IPs só funcionam nativamente para tráfego de entrada, e o tráfego de saída continua a usar o endereço nativo da instância como origem. Um Elastic IP manual contorna isso em parte: o guia da Exoscale sobre usar um Elastic IP como origem de tráfego associa uma aplicação a um. Para um túnel, o endereço nativo continua a ser a ponta mais simples, por isso aponte a outra ponta para o endereço IPv4 nativo, não para um Elastic IP.
• As respostas regressam pelo túnel. Acrescente uma rota de política para que o tráfego do bloco saia pelo túnel. Enviado diretamente, levaria um endereço de origem que a Exoscale nunca atribuiu à instância, e as redes filtram esse tráfego.
• Abra o security group. A Exoscale recusa todo o tráfego de entrada por defeito. Acrescente uma regra de entrada a partir do endereço da outra ponta para GRE, que os security groups oferecem como protocolo a par de TCP, UDP e ICMP, ou para a porta UDP do WireGuard. A saída fica aberta até criar a primeira regra de saída. Depois disso, permita também a saída do túnel.
• Defina o MTU. 1476 bytes para GRE, cerca de 1420 para WireGuard, com MSS clamping se a instância encaminhar o bloco para contentores ou máquinas virtuais.
• Qualquer tamanho. Um túnel entrega menos de 256 endereços, até um único, o que o BYOIP nunca permite.

Onde entra a RTM Networks

Alugamos /24 e maiores a partir do nosso próprio espaço de endereçamento do RIPE NCC, e vendemos blocos nas regiões RIPE NCC, ARIN e APNIC. Cada aluguer inclui o ROA, o objeto route, os registos PTR e uma Letter of Authorization sempre que precisar (alugar IPv4). Se a Exoscale aceitar anunciar um bloco, criamos o ROA para o ASN que ela indicar e assinamos a Letter of Authorization. Até lá, anunciamos nós próprios o bloco e entregamo-lo à sua instância por GRE ou WireGuard, em qualquer tamanho até um único endereço (túneis GRE e WireGuard). Diga-nos a zona e de quantos endereços precisa. Outros fornecedores: guias BYOIP.