El pull-filter d'OpenVPN coincideix amb més que la ruta que volíeu

Afegiu una línia per conservar la ruta predeterminada local, i després el túnel ja no arriba al servidor DNS intern. La línia era pull-filter ignore "route", que no vol dir "ignora aquesta ruta". Vol dir "descarta qualsevol opció enviada el text de la qual comenci amb aquestes cinc lletres", i en un servidor normal això inclou route-gateway, route-metric i route-ipv6 juntament amb les rutes mateixes. La llista de comprovació de sota és el que faig abans de tocar un perfil que ha de fer servir una altra persona.

El filtre només s'aplica a les opcions enviades

pull-filter actua sobre les línies d'opció que el servidor envia un cop establert el túnel, i sobre res més. Les opcions escrites al vostre fitxer local no hi queden afectades, ni tampoc el trànsit de les aplicacions. Si esperàveu impedir que un procés utilitzés el túnel, aquesta és completament l'eina equivocada i cap combinació de filtres ho aconseguirà.

Aquest abast és útil, perquè significa que podeu deixar la configuració del servidor tranquil·la i tot i així rebutjar-ne una part localment. També és un límit que val la pena consignar al tiquet: un filtre canvia què accepta aquest client, no què ofereix el servidor. No té cap efecte sobre altres usuaris del mateix perfil. Ni sobreviu a un canvi a un altre client que no implementi l'opció, cosa que val la pena saber abans de construir-hi un flux de treball.

Confirmeu què envia realment el servidor abans d'escriure el patró. Amb una verbositat alta el client imprimeix la cadena d'opcions enviades que ha rebut, i aquesta és l'única font honesta per al text exacte amb què feu la comparació:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Llegiu la línia enviada com una llista d'opcions separades per comes, i fixeu-vos que els noms d'opció i els seus arguments se separen amb espais. El vostre text de filtre es compara amb aquest flux, i per això els espais importen tant al pas següent.

La coincidència és un prefix, així que els espais ho són tot

La comparació és un prefix de cadena, no un nom d'opció analitzat. Per tant "route" coincideix amb route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 i route-metric 100. Un sol espai final l'estreta a la família que probablement volíeu, i el prefix complet l'estreta encara més a una destinació concreta.

L'última fila és la que atrapa la gent durant la feina de túnel dividit. Conservar el vostre propi resolutor és una opció legítima, i significa que cada nom intern ara depèn d'un resolutor que no pot veure la zona privada. És una conseqüència que s'accepta a propòsit, no un efecte secundari que es descobreix en producció.

La coincidència per prefix també vol dir que una regla es pot ampliar més endavant en silenci. Quan el servidor afegeix una opció nova que comença amb el vostre text, el vostre filtre comença a aplicar-s'hi sense que ningú editi el vostre perfil. Aquest és el mode de fallada contra el qual cal dissenyar, i la mitigació és coincidir amb tanta part de l'opció com pugueu, no amb tan poca com pugueu.

Tres verbs amb tres resultats diferents

accept, ignore i reject no són tres grafies de la mateixa idea. Difereixen en què fa el client amb una coincidència i en si algú se n'assabenta.

ignore descarta l'opció coincident en silenci, que és el que voleu per a un paràmetre que heu substituït deliberadament. reject la descarta i fa que el client es queixi, que és el que voleu quan la seva absència ha de ser visible en un registre en lloc de descobrir-se més tard. accept és la forma positiva, s'usa quan construïu una llista d'autoritzacions en lloc de treure opcions individuals.

Sigui quin sigui el verb que useu, els filtres s'apliquen en l'ordre en què apareixen, així que dues regles superposades produeixen un resultat dependent de l'ordre i molt difícil de revisar. Tingueu una regla per intenció i poseu el text més específic a cadascuna. Si us cal una llista d'autoritzacions, preferiu unes poques regles accept a un munt de regles ignore que sumen el mateix. Aleshores els revisors poden llegir el fitxer de dalt a baix i predir el resultat, i aquesta és l'única prova que escala.

Comproveu la ruta i el resolutor aplicats, no el perfil

Un filtre que sembla correcte al fitxer encara us pot deixar amb un túnel que no encamina res d'útil. Verifiqueu l'efecte al sistema en marxa, on les opcions enviades ja s'han aplicat o descartat:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Les dues primeres línies us diuen si ha arribat la ruta predeterminada enviada i quantes entrades estàtiques han sobreviscut. La consulta al resolutor mostra quin servidor fa servir realment la interfície del túnel, i és normalment on apareix una sorpresa de DNS. L'última línia respon l'única pregunta que importa a un usuari.

Proveu les dues direccions mentre hi sou. Una regla que manté el vostre internet local funcionant però trenca en silenci la resolució de noms interna passa una comprovació superficial i falla la primera tasca real, així que incloeu un recurs intern i un lloc públic a la mateixa prova.

Registreu l'excepció i qui en respon

Un filtre és una excepció al disseny de l'operador, així que deixeu-lo escrit amb un motiu i un punt de revisió. "Ignora les rutes enviades per conservar la predeterminada local" és revisable; una línia nua en un perfil no ho és, i la propera persona l'esborrarà o l'ampliarà a cegues.

La versió també hi compta. El comportament de coincidència i la sintaxi acceptada exacta s'han refinat al llarg d'OpenVPN 2.4, 2.5 i 2.6, així que confirmeu el patró amb el manual de la compilació que distribuïu i no amb un missatge de fòrum sobre una versió més antiga. El manual d'OpenVPN 2.6 documenta l'opció i la seva regla de coincidència.

Finalment, acordeu l'excepció amb qui gestiona el servidor. Un filtre del costat del client que contradiu una política deliberada del servidor és un incident de suport esperant la propera auditoria, i és molt més barat resoldre'l abans que el perfil surti que després que algú noti que falten les rutes.