OpenVPN no GCE: adicionar um IP alias antes de fazer push de rotas

Um cliente liga-se ao servidor OpenVPN numa VM do Compute Engine, a janela de estado diz ligado, e um ping para um host dentro da VPC continua a não chegar a lado nenhum. O instinto é acrescentar mais uma linha push, e isso nunca resolve. O Compute Engine decide para onde vão os pacotes a partir da sua própria tabela de rotas e dos endereços que uma interface da VM detém realmente, por isso um pool de túnel que a VM não possui é um pool para o qual ninguém entrega.

Siga o pacote que falha em vez do ficheiro de configuração, e as peças em falta aparecem por ordem.

Começar pelo pacote que morre

O SYN sai do cliente, entra no túnel e chega à VM como um pacote encapsulado para um destino dentro da VPC. O OpenVPN desencapsula-o e tenta encaminhá-lo por eth0, onde a fabric põe uma pergunta antes de tudo o resto: esta instância possui o endereço de destino. Um pool de túnel recortado da sub-rede de outra pessoa falha essa pergunta, e o pacote é descartado antes de qualquer rota ou regra de firewall ser consultada.

Portanto, o sentido cliente para VPC tem dois requisitos separados, e nenhum deles é uma diretiva push. A VM precisa de um intervalo alias que cubra o pool de túnel, e é isso que a torna proprietária legítima desses endereços. A VPC precisa de uma rota que nomeie a VM como next hop para cada prefixo protegido. Falte um dos dois e o pacote morre noutro sítio, enquanto o cliente vê o mesmo silêncio.

Leia a falha nessa ordem, porque do lado do cliente as duas condições parecem idênticas. Um túnel que diz ligado enquanto nada responde é a assinatura de um problema de topologia, não de uma cifra má.

A instância possui o pool de túnel

Dê à VM um intervalo secundário dentro da sua própria sub-rede e depois faça o OpenVPN distribuir endereços exatamente desse intervalo. Numa instância cujo endereço primário é 10.156.0.10/20, um alias /28 mantém o pool separado dos endereços que outras instâncias já têm:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

A diretiva server tem então de descrever o mesmo bloco. O seu primeiro endereço passa a ser a gateway do túnel, e os restantes endereços são distribuídos aos clientes. Aqui dois números descrevem um bloco, uma rede e uma máscara, e é essa a sintaxe de pool que o OpenVPN ainda espera.

server 10.156.1.0 255.255.255.240

Confirme que o endereço chegou mesmo à interface e não apenas dentro da configuração do OpenVPN. A fabric encaminha o que a NIC reporta, não o que o daemon acredita. Um comando resolve:

ip -4 addr show dev eth0

Um endereço secundário que nunca chega a eth0, ou um pool que se sobrepõe a outra sub-rede, aparece mais tarde como perdas intermitentes em vez de um erro de arranque. O daemon arranca, os clientes ligam-se, e apenas alguns destinos se comportam mal. Mantenha o intervalo alias pequeno para que o pool seja fácil de reconhecer numa tabela de rotas. Nunca o recorte de uma sub-rede que outra instância já usa.

Dar um next hop ao tráfego de retorno

Uma resposta de um host da VPC é endereçada a um endereço de cliente no pool de túnel, que não pertence a nenhuma sub-rede que a VPC conheça. Sem uma rota para esse pool, a resposta para no primeiro salto sem correspondência, e o pedido pode muito bem ter tido sucesso no extremo remoto.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

A mesma rota é necessária para qualquer prefixo que viva atrás de um cliente em vez de dentro da VPC. Esses prefixos também precisam de uma entrada iroute no ficheiro ccd desse cliente. Essa entrada é contabilidade do lado do servidor: diz ao servidor qual cliente possui o prefixo, e não instala nada no próprio cliente.

Guarde a lista push para o lado cliente da conversa, porque só acrescenta rotas à máquina que se liga. Uma linha push para uma sub-rede da VPC e uma rota da VPC de volta ao pool são duas metades do mesmo caminho, e qualquer metade sozinha produz um túnel que transporta pedidos mas não respostas.

Firewalls, encaminhamento e os saltos pelo meio

A firewall da VPC avalia o pacote desencapsulado, por isso uma regra de entrada tem de admitir o pool de túnel e qualquer prefixo de site que chegue à VM por essa via. Uma postura de negação por omissão falha em silêncio aqui: o pacote é descartado após o desencapsulamento, e o registo do OpenVPN mostra uma sessão saudável.

Em qualquer host Linux que encaminhe em vez de terminar, verifique se net.ipv4.ip_forward está ativado. A regra de propriedade também se aplica aí: uma máquina que encaminha para uma sub-rede que não detém descarta o pacote tal como a VM faria. Leia o valor antes de culpar o túnel.

Quando falha exatamente um prefixo

A falha parcial é o caso mais fácil de ler, porque tudo o resto do caminho já está provado. Comece pela lista de rotas e leia o intervalo de destino e o next hop da entrada que deveria cobrir o prefixo, depois leia a descrição da instância e compare o seu intervalo alias com o pool que o servidor distribui.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Uma rota em falta mostra-se como ausência de next hop para o prefixo, enquanto um alias em falta se mostra como um pacote descartado na interface; do lado do cliente as duas parecem-se e nessas duas saídas são completamente diferentes. Se ambas existirem, o suspeito restante é o iroute ccd do cliente que reclama o prefixo.

Anote os quatro valores ao lado do túnel: intervalo alias, pool do servidor, prefixos empurrados, rotas da VPC. Um alias desatualizado quebra cada endereço do pool, uma rota desatualizada quebra um sentido, um push em falta esconde o prefixo ao cliente, e um iroute errado manda o prefixo para o par errado. A próxima pessoa que acrescentar uma sub-rede precisa dos quatro num só sítio, e a nota é mais barata do que a noite.