Per què una resposta UDP d’OpenVPN surt d’una adreça incorrecta

Un client d’OpenVPN marca una adreça, el servidor respon des d’una altra i el túnel no s’aixeca mai. El registre del servidor mostra que el paquet arriba i una captura mostra que la resposta surt, de manera que la fallada s’atribueix al client. En un equip amb diverses interfícies, o amb diverses adreces en una sola interfície, les dues parts simplement no coincideixen sobre quina adreça s’utilitza. La resposta és vàlida a la capa IP, però molts clients descarten un datagrama la font del qual no és l’adreça amb què van contactar.

Què veu el client quan canvia la font

Un sòcol UDP que no està lligat a una adreça local concreta no té una font fixa, així que el nucli n’escull una en el moment d’enviar. Aquesta tria prové d’una consulta de ruta cap a l’adreça del client, i la font passa a ser l’adreça de la interfície que selecciona la consulta. En una màquina amb una sola interfície la tria és invisible; en un equip amb una adreça de gestió, una adreça pública i una adreça secundària a la mateixa targeta de xarxa, depèn de les mètriques i la política d’encaminament. L’encaminament per polítiques fa la discrepància més probable en lloc de menys, perquè una regla pot seleccionar un enllaç ascendent al qual el client no va arribar mai. Una ruta per defecte apresa d’un proveïdor més una regla de font que apunta a un altre n’hi ha prou per produir-ho.

Els clients que filtren respostes, i el seguiment de connexions que espera l’exacta quàdruple i la font, descartaran la resposta sense cap missatge útil. Llavors el túnel expira com si no hagués arribat res, i per això això es confon amb un problema de tallafocs al costat del client. Una captura presa només al servidor confirma l’error en lloc d’explicar-lo, perquè la resposta realment surt. Compareu la font de la resposta amb l’adreça amb què va contactar el client abans de canviar res més.

Què fa realment l’opció multihome

La directiva s’escriu multihome en un fitxer de configuració i --multihome a la línia d’ordres, i fa que un servidor UDP respongui des de l’adreça on va arribar el paquet del client. El nucli lliura l’adreça de destinació original com a dades auxiliars en rebre, i OpenVPN utilitza aquest valor com a font de la resposta. Així, un servidor escoltant en una adreça comodí, local 0.0.0.0 per a IPv4 o el seu equivalent IPv6, es comporta com si cada client hagués arribat a un oient dedicat. Els clients que van entrar per l’adreça pública reben respostes des de l’adreça pública, i els clients en una adreça interna les reben des d’aquesta. Res més en el camí del paquet no es mou: la ruta, les regles de filtre i la configuració del túnel queden exactament com estaven.

Aquesta darrera propietat és la raó per la qual l’opció és segura d’afegir a un servidor que ja funciona, i també la raó per la qual no pot reparar un filtre que només permet una adreça. El paquet encara s’ha d’acceptar pel camí que segueix, així que la correcció de la font canvia l’origen de la resposta i res més. També és només per a UDP: un oient TCP no té aquest problema en la mateixa forma, perquè la connexió s’identifica per la quàdruple i no per l’adreça de font de la resposta.

Quan una adreça local fixa és el defecte equivocat

Abans d’agafar l’opció, comproveu si el servidor lliga una adreça local concreta, perquè un oient lligat sempre respon des d’aquesta adreça. Això és correcte per a un desplegament amb una sola interfície i equivocat tan bon punt els clients utilitzen legítimament més d’una adreça. Si la lligadura va ser deliberada, decidiu si el servidor ha d’acceptar trànsit en adreces addicionals. Treure la lligadura augmenta l’exposició, així que les interfícies i les xarxes de font permeses les han d’aplicar el servei i el filtre, no només l’adreça de lligadura.

La referència d’OpenVPN limita l’opció als servidors UDP, anota el processament addicional del camí del paquet i registra quines plataformes la suporten. Confirmeu-ho a la versió instal·lada abans de planificar-hi. On no és compatible, l’alternativa és lligar l’adreça concreta o corregir l’encaminament de retorn, i totes dues són canvis més estrets del que semblen d’entrada. Escoltar en comodí també té conseqüències més enllà de les respostes: un servidor a totes les adreces és abastable des de cada xarxa a què està connectat l’equip, cosa que potser no és l’exposició que ningú pretenia.

Demostreu la font de la resposta des de fora

Proveu des de fora del servidor i anoteu l’adreça i el transport exactes que va fer servir el client abans de capturar res. Les tres proves de sota responen tres preguntes diferents, i l’ordre importa.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

La captura mostra l’adreça de font a la resposta, que és el fet sobre el qual gira tot l’article. El llistat de sòcols mostra què va lligar realment el servidor, perquè un oient comodí i un de concret semblen idèntics en un fitxer de configuració i es comporten diferent a la xarxa. La consulta de ruta mostra la font que el nucli triaria per a aquell flux, cosa que explica la captura abans que canvieu res. Repetiu les tres per a IPv4 i IPv6 per separat, perquè són oients separats i consultes separades, i una entrada comodí per a una família no diu res de l’altra.

Encaminament, descobriment i filtratge continuen separats

Preservar la font de la resposta no instal·la una ruta de sortida, no actualitza el DNS dinàmic ni fa que una família d’adreces accepti l’altra. En un servidor amb diversos enllaços ascendents, el camí de retorn de cada font s’ha d’acordar deliberadament, o les respostes surten per una interfície que el filtre del client no va permetre mai. Igualment, una adreça nova després d’un canvi de prefix ha d’arribar als clients mitjançant el descobriment i el flux de reconnexió admès, no mitjançant el registre antic.

Deixeu les comprovacions d’identitat del servidor i la verificació de certificats exactament com estan, perquè una adreça canviada no justifica acceptar un parell no verificat. Si la resposta ara surt de la font prevista i el túnel encara falla, considereu el problema de la font resolt i seguiu endavant. El següent error observat pertany a l’encaminament, el filtratge o l’autenticació, i tornar a canviar l’oient no hi arribarà. Escriviu la font de la resposta al tiquet al costat de l’adreça amb què va contactar el client, perquè la propera persona pugui comprovar el mateix fet amb una ordre.