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

Os servidores cloud e os servidores dedicados normais da Hetzner usam endereços atribuídos pela Hetzner, e a sua documentação para eles nada diz sobre trazer os seus: nesses, a forma de usar os seus próprios endereços é um túnel, a opção 2 abaixo. O que a Hetzner trata a pedido é a opção 1, para configurações bare metal à medida.

Opção 1: o upstream BGP da Hetzner

A Hetzner apresenta isto nas suas ofertas especiais de colocation como um upstream de internet com uma sessão BGP pessoal e redundante. No dia em que consultámos, a sua documentação dizia:

• O cliente traz o ASN e os endereços. O upstream "requires an own ASN" (tradução: «exige um ASN próprio»), anuncia os seus próprios endereços IP, e a Hetzner não fornece nenhum para ele.
• Dois uplinks. A ligação termina em dois routers de backbone redundantes, com uma sessão BGP em cada um, sobre duas redes de trânsito /30, que a Hetzner fatura à parte.
• Onde. Soluções à medida para servidores dedicados, que se ligam através de uma interligação de rede privada, por isso a sua localização não importa. Racks e cages de colocation em Falkenstein (FSN1-DC2), Nuremberga (NBG1-DC2 e NBG1-DC4) e Helsínquia (HEL1-DC1), embora a Hetzner não possa disponibilizar espaço de colocation por agora.
• Cablagem. Exige cablagem para a meet-me room da Hetzner, ou a interligação privada para bare metal.

O tráfego é faturado a 1 € por TB à parte, e cada uma das duas redes de trânsito /30 a 6,00 € por mês mais 17,50 € de ativação. Todos estes preços são sem IVA. Os preços da Hetzner mudam, por isso consulte a página indicada no topo deste guia antes de orçamentar.

O que prepara

1. Um número AS. Se não tiver um, um LIR patrocinador pode tratar disso por si (patrocínio de ASN).
2. Um /24 ou maior. A Hetzner não publica nenhum mínimo para este upstream, mas o resto da Internet filtra tudo o que seja mais pequeno do que um /24, por isso esse é o limite prático.
3. Um ROA que indica o seu ASN para o prefixo, com o comprimento máximo igual ao que vai anunciar (RPKI e ROA).
4. Um objeto route para o prefixo com o seu ASN como origem, e um objeto aut-num que indica a rede da Hetzner, AS24940, como o seu upstream. As páginas da Hetzner não indicam o ASN do upstream; o AS24940 pertence à Hetzner Online segundo a RIPE Database.
5. Um BGP speaker do seu lado: o seu router, ou BIRD ou FRR num servidor.

As sessões

Peça à Hetzner o upstream através da sua conta, indicando o seu ASN e o prefixo. A Hetzner atribui as duas redes de trânsito; ativa então uma sessão por uplink e anuncia apenas o seu prefixo. Uma sessão mínima no BIRD 2, com valores de documentação (64500 para o seu ASN, 203.0.113.0/24 para o seu bloco, 192.0.2.1 para o lado da Hetzner da primeira rede de trânsito):

protocol static {
  ipv4;
  route 203.0.113.0/24 unreachable;
}

protocol bgp hetzner1 {
  local as 64500;
  neighbor 192.0.2.1 as 24940;
  ipv4 {
    import all;
    export filter { if net = 203.0.113.0/24 then accept; reject; };
  };
}

O BIRD só anuncia rotas que estão na sua tabela, por isso o bloco protocol static coloca lá o seu prefixo; sem ele, a sessão sobe e não anuncia nada. A rota unreachable só responde por endereços do bloco que nenhuma interface ou rota mais específica transporta (documentação do BIRD 2, o protocolo static). A segunda sessão é igual, contra a segunda rede de trânsito. Verifique o anúncio do exterior, com um looking glass ou um validador RPKI, antes de passar tráfego para ele.

Opção 2: um túnel, para a Hetzner Cloud e servidores dedicados

Se os seus servidores estiverem na Hetzner Cloud ou em máquinas dedicadas normais, não há sessão BGP possível. Pode ainda assim usar neles os seus próprios endereços: uma rede que possa anunciar o bloco anuncia-o, e um túnel GRE ou WireGuard leva o tráfego até ao seu servidor Hetzner e de volta. O servidor vê os endereços como se fossem locais (como funciona o túnel).

Três coisas a acertar:

• As respostas regressam pelo túnel. Acrescente uma rota de política para que o tráfego do bloco saia pelo túnel, como mostra o guia de GRE. Enviado diretamente, levaria um endereço de origem que a Hetzner nunca atribuiu ao servidor, e as redes filtram esse tráfego.
• Abra a firewall para o túnel. Se usar a Hetzner Cloud Firewall, permita GRE (protocolo IP 47) ou a porta UDP do WireGuard a partir da outra ponta do túnel.
• Defina o MTU. 1476 bytes para GRE, cerca de 1420 para WireGuard, com MSS clamping se o servidor encaminhar o bloco para máquinas virtuais.

Um túnel resolve também o problema que o BYOIP nunca resolve: pode entregar menos de 256 endereços, até um único.

Se alugar o bloco

Com o upstream BGP, é o titular do bloco que faz o trabalho no registo: o ROA para o seu ASN, o objeto route e, se a Hetzner a pedir, uma Letter of Authorization que indique o seu ASN e a Hetzner como a rede que o transporta. Com um túnel, nada muda na Hetzner; a rede do outro lado anuncia o bloco, e o titular só precisa de autorizar essa rede.

Onde entra a RTM Networks

Alugamos /24 e maiores do nosso próprio espaço de endereçamento do RIPE NCC, com o ROA, o objeto route e a Letter of Authorization configurados para o seu ASN (alugar IPv4), e vendemos blocos nas regiões RIPE NCC, ARIN e APNIC. Patrocinamos números AS para organizações que não têm o seu próprio LIR. Para a Hetzner Cloud e servidores dedicados, anunciamos nós próprios o bloco e entregamo-lo ao seu servidor por GRE ou WireGuard, em qualquer tamanho, até um único endereço (túneis GRE e WireGuard). Diga-nos que produto Hetzner usa e de quantos endereços precisa. Há mais fornecedores nos nossos guias BYOIP.