OpenVPN a GCE: afegiu una IP àlies abans de fer push de rutes

Un client es connecta al servidor OpenVPN en una VM de Compute Engine, la finestra d’estat diu connectat, i un ping a un host de la VPC segueix sense arribar enlloc. L’instint és afegir una línia push més, i això no ho arregla mai. Compute Engine decideix on van els paquets a partir de la seva pròpia taula de rutes i de les adreces que una interfície de la VM té realment, així que un pool de túnel que la VM no posseeix és un pool al qual ningú no lliura.

Seguiu el paquet que falla en lloc del fitxer de configuració, i les peces que falten apareixen en ordre.

Començar pel paquet que mor

El SYN surt del client, entra al túnel i arriba a la VM com un paquet encapsulat cap a una destinació de la VPC. OpenVPN el desencapsula i intenta reenviar-lo per eth0, on la fabric fa una pregunta abans que res: aquesta instància posseeix l’adreça de destinació. Un pool de túnel retallat de la subxarxa d’un altre falla aquesta pregunta, i el paquet es descarta abans que es consulti cap ruta ni cap regla de tallafoc.

La direcció de client a VPC té, doncs, dos requisits separats, i cap dels dos no és una directiva push. La VM necessita un rang àlies que cobreixi el pool de túnel, i és això el que la fa propietària legítima d’aquestes adreces. La VPC necessita una ruta que designi la VM com a next hop per a cada prefix protegit. Si en falta un, el paquet mor en un altre lloc, mentre el client veu el mateix silenci.

Llegiu la fallada en aquest ordre, perquè des del costat del client les dues condicions són idèntiques. Un túnel que diu connectat mentre no respon res és la signatura d’un problema de topologia, no d’un xifratge dolent.

La instància posseeix el pool de túnel

Donau a la VM un rang secundari dins de la seva pròpia subxarxa i feu que OpenVPN reparteixi adreces exactament d’aquest rang. En una instància amb adreça primària 10.156.0.10/20, un àlies /28 manté el pool separat de les adreces que altres instàncies ja tenen:

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

La directiva server ha de descriure llavors el mateix bloc. La seva primera adreça es converteix en la passarel·la del túnel, i la resta d’adreces es reparteixen als clients. Aquí dos nombres descriuen un bloc, una xarxa i una màscara, i aquesta és la sintaxi de pool que OpenVPN encara espera.

server 10.156.1.0 255.255.255.240

Confirmeu que l’adreça ha arribat realment a la interfície i no només dins de la configuració d’OpenVPN. La fabric reenvia el que la NIC informa, no el que el dimoni creu. Una ordre ho decideix:

ip -4 addr show dev eth0

Una adreça secundària que no arriba mai a eth0, o un pool que se solapa amb una altra subxarxa, apareix més tard com a pèrdues intermitents en lloc d’un error d’arrencada. El dimoni arrenca, els clients es connecten, i només algunes destinacions es comporten malament. Manteniu el rang àlies petit perquè el pool sigui fàcil de reconèixer en una taula de rutes. No el retalleu mai d’una subxarxa que una altra instància ja fa servir.

Donar un next hop al trànsit de retorn

Una resposta d’un host de la VPC s’adreça a una adreça client del pool de túnel, que no pertany a cap subxarxa que la VPC conegui. Sense una ruta per a aquest pool, la resposta s’atura al primer salt sense coincidència, i la petició pot molt bé haver tingut èxit a l’altre extrem.

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

La mateixa ruta cal per a qualsevol prefix que visqui darrere d’un client en lloc de dins de la VPC. Aquests prefixos també necessiten una entrada iroute al fitxer ccd d’aquell client. Aquesta entrada és comptabilitat del costat del servidor: diu al servidor quin client posseeix el prefix, i no instal·la res al client mateix.

Guardeu la llista push per al costat client de la conversa, perquè només afegeix rutes a la màquina que es connecta. Una línia push per a una subxarxa de la VPC i una ruta de la VPC cap al pool són dues meitats del mateix camí, i qualsevol meitat sola produeix un túnel que porta peticions però no respostes.

Tallafocs, reenviament i els salts entremig

El tallafoc de la VPC avalua el paquet desencapsulat, així que una regla d’entrada ha d’admetre el pool de túnel i qualsevol prefix de lloc que arribi a la VM per aquesta via. Una postura de denegació per defecte falla en silenci aquí: el paquet es descarta després del desencapsulament, i el registre d’OpenVPN mostra una sessió sana.

En qualsevol host Linux que reenviï en lloc de terminar, comproveu que net.ipv4.ip_forward estigui activat. La regla de propietat també s’hi aplica: una màquina que reenvia per a una subxarxa que no té descarta el paquet igual que ho faria la VM. Llegiu el valor abans de culpar el túnel.

Quan falla exactament un prefix

La fallada parcial és el cas més fàcil de llegir, perquè tota la resta del camí ja s’ha demostrat. Comenceu per la llista de rutes i llegiu el rang de destinació i el next hop de l’entrada que hauria de cobrir el prefix, després llegiu la descripció de la instància i compareu el seu rang àlies amb el pool que el servidor reparteix.

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

Una ruta que falta es mostra com a absència de next hop per al prefix, mentre que un àlies que falta es mostra com un paquet descartat a la interfície; des del client les dues coses s’assemblen i en aquestes dues sortides són completament diferents. Si hi són totes dues, el sospitós que queda és l’iroute ccd del client que reclama el prefix.

Apunteu els quatre valors al costat del túnel: rang àlies, pool del servidor, prefixos fets push, rutes de la VPC. Un àlies obsolet trenca cada adreça del pool, una ruta obsoleta trenca una direcció, un push que falta amaga el prefix al client, i un iroute equivocat envia el prefix al peer equivocat. La propera persona que afegeixi una subxarxa necessita tots quatre en un sol lloc, i la nota és més barata que el vespre.