Prefix públic per OpenVPN: arreglar el camí de tornada

Mireu com puja el túnel i el client fa ping a l’altre costat, i després una adreça pública que pertany darrere de la VPN respon des d’un altre lloc, o no respon. Aquest símptoma normalment no té res a veure amb el xifratge ni amb els certificats. Un prefix encaminat pel proveïdor es lliura com una ruta IP, i portar-lo per OpenVPN vol dir reproduir aquesta ruta a dos nivells i preservar l’adreça d’origen en el camí de tornada. No cal fer pont de la WAN, i afegir l’adreça a una interfície no crea la ruta ascendent.

El prefix primer s’ha d’encaminar cap a vosaltres

Pregunteu al proveïdor com es lliura el bloc. Un prefix encaminat a l’adreça principal del vostre servidor és una cosa diferent de les adreces que el proveïdor espera assolir directament en un segment WAN. Només el primer model funciona amb el disseny d’aquí.

Si el proveïdor encamina 198.51.100.64/28 al vostre servidor d’entrada, els paquets d’aquest rang arriben al servidor i s’hi aturen tret que els reenvieu. Si el proveïdor, en canvi, fa pont del rang cap al vostre enllaç ascendent, el servidor ha de respondre ARP per a ell, que és un altre problema.

Proveu el model de lliurament abans de tocar OpenVPN: des de fora, feu ping a una adreça del bloc i mireu quina interfície la rep. Si no arriba res, cap configuració del túnel no ajudarà. Si l’adreça respon directament a la WAN, el proveïdor fa pont en lloc d’encaminar, i el disseny de sota no s’aplica.

Dos nivells d’encaminament: ruta del nucli i iroute

OpenVPN necessita el prefix en dos llocs. El nucli ha de saber que el prefix pertany al dispositiu del túnel, perquè els paquets reenviats entrin a OpenVPN en lloc de la ruta per defecte. OpenVPN també ha de saber quin client autenticat posseeix el prefix, que és l’entrada iroute al directori específic del client.

La ruta del costat del servidor té aquest aspecte, amb el prefix i la màscara coincidint amb l’assignació:

ip route add 198.51.100.64/28 dev tun0

La configuració específica del client assigna la propietat. Poseu-la al fitxer CCD que porta el nom comú del certificat del client, i confirmeu que aquest directori és el que el servidor llegeix realment:

iroute 198.51.100.64 255.255.255.240

La documentació d’OpenVPN sobre xarxes encaminades descriu els dos nivells i per què són separats. Una ruta del nucli sense iroute envia paquets al túnel sense propietari, i OpenVPN els descarta. Un iroute sense la ruta del nucli deixa els paquets al camí per defecte del servidor. Tots dos errors semblen un túnel trencat des del costat del client.

On viu l’adreça del servei

El prefix delegat no és el mateix que les adreces pròpies del túnel. Numereu l’enllaç des de l’espai privat si voleu, i col·loqueu l’adreça pública del servei on el servei s’executa realment.

En un client Linux que acaba el servei localment, n’hi ha prou amb una adreça d’amfitrió individual:

ip address add 198.51.100.70/32 dev lo

Si el prefix s’encamina més enllà cap a un amfitrió VM o una altra LAN, configureu en canvi aquest camí descendent i la seva ruta de tornada. Assignar cada adreça del bloc al client VPN no és necessari i crea conflictes més endavant.

Manteniu l’origen públic en el camí de tornada

Una resposta del prefix delegat ha de sortir pel túnel i arribar a la ruta del proveïdor. Si l’amfitrió remot l’envia pel seu propi ISP, l’adreça d’origen sembla falsificada, i el proveïdor o la destinació la descarten. La solució és una regla basada en l’origen o una taula d’encaminament dedicada, no un NAT més ampli. Sense això, el servei funciona des del parell del túnel i falla des de qualsevol altre lloc.

Al servidor d’entrada, una regla de masquerade àmplia és el culpable habitual. Reescriu l’origen públic a l’adreça principal del servidor, i el client mai no veu la real:

iptables -t nat -S POSTROUTING

Limiteu el NAT als clients VPN privats que el necessiten i deixeu el prefix delegat sense traduir. Després confirmeu que el servidor reenvia el prefix, perquè una cadena de reenviament amb denegació per defecte el descarta en silenci.

Verifiqueu les dues direccions abans de confiar-hi

La verificació són quatre observacions, no una. Confirmeu que arriba la ruta del proveïdor, que el nucli envia el prefix al túnel, que OpenVPN l’atribueix al client correcte i que la resposta torna amb l’origen públic intacte. Cada observació té la seva pròpia ordre, així que una fallada assenyala una capa i no tot el disseny. Executeu-les en aquest ordre després de cada canvi de configuració.

Pregunteu al nucli quin camí pren una adreça delegada, i observeu el túnel mentre s’executa una petició:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

El filtratge de camí invers pot desfer una ruta correcta. Comproveu el paràmetre efectiu al túnel i a l’enllaç ascendent, i recordeu que el mode estricte rebutja el trànsit l’origen del qual no coincideix amb la interfície per on ha arribat:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Finalment, proveu el cas de fallada. Atureu el túnel i confirmeu que el prefix públic no es filtra per l’enllaç ascendent ordinari. Restaurar la VPN hauria de tornar el servei sense ampliar quins ports exposa l’amfitrió.