Conserveu les rutes privades i elimineu la redirecció: túnel dividit d’OpenVPN

El túnel s’aixeca, l’aplicació es carrega i llavors tota la resta de l’ordinador portàtil comença a comportar-se de manera estranya. Aquesta és la forma habitual d’una política només privada implementada suprimint una línia. Treure una ruta per defecte empenyuda sí que canvia on va el trànsit, però no diu on hauria d’anar el trànsit en lloc d’això, i no toca gens la resolució de noms. Una política necessita dues meitats positives abans de poder-se provar.

Suprimir la redirecció és només la meitat del canvi

Una redirecció de túnel complet i una política només privada difereixen en què afirmen sobre el món. La redirecció reivindica cada destinació, mentre que la política privada reivindica una llista i deixa la resta tranquil·la. Suprimir la reivindicació sense escriure la llista produeix un client que no arriba enlloc fora de la LAN, cosa que sembla una fallada d’encaminament més que no pas un buit de política. Escriviu la llista abans de treure la reivindicació, i l’ordre d’aquests dos passos deixa de tenir importància.

Totes dues meitats són requisits, no valors per defecte. Els prefixos privats han d’entrar al túnel, i les destinacions ordinàries han de conservar el camí que tenien abans de la connexió.

Si una organització imposa el túnel complet, res d’això no s’aplica. El disseny només privat pertany a desplegaments on l’encaminament dividit està aprovat.

pull-filter és una coincidència, no un interruptor

La directiva pull-filter elimina les opcions empenyudes els noms de les quals coincideixen amb un prefix, i això és tot el que fa. Ignorar la redirecció deixa cada altra opció empenyuda al seu lloc, que normalment és el que voleu: les rutes, la configuració de DNS i el valor de la passarel·la de ruta arriben igualment. També no pot eliminar una directiva escrita al perfil local, perquè el filtratge s’aplica al que empeny el servidor.

Resistiu la temptació d’ignorar totes les opcions que comencin per route. Aquest patró també descarta les rutes privades que necessita la connexió, i pot fer caure informació de passarel·la de la qual depèn el túnel.

route-nopull és una decisió més àmplia del que sembla. Atura que el client accepti les rutes empenyudes i les opcions a l’estil DHCP com a grup, cosa que és una política diferent de filtrar una sola opció.

Escriviu la llista de rutes de l’aplicació cap enfora

Comenceu pel que l’usuari obre realment, i després afegiu les peces de suport. Una aplicació a 10.60.20.15 implica la seva subxarxa 10.60.0.0/16, i un nom privat implica el resolutor que el respon. Per tant, un usuari que ha demanat una sola aplicació necessita dues destinacions i una decisió de DNS. Tot el que queda més enllà d’aquesta llista és fora d’abast per construcció, i això és el que manté la política revisable.

En un servidor que hi col·labora, això es converteix en dues rutes empenyudes, i cap de les dues no és una redirecció. Manteniu la topologia del túnel i els valors de passarel·la de ruta que subministra el servei existent.

Quan només alguns usuaris necessiten aquesta política, apliqueu-la per client o per grup. Canviar l’encaminament de tothom per arreglar el requisit d’un sol equip és com un túnel dividit es converteix en una interrupció.

Feu que el DNS segueixi el mateix camí

Una ruta cap al resolutor no és una política de resolutor. En un client systemd-resolved el resultat semàntic és un domini d’encaminament per a l’espai de noms privat que apunta al resolutor intern, i això és el que fa que només aquells noms l’utilitzin. Un client de Windows necessita en canvi el seu propi mecanisme de política d’espais de noms. Una línia de servidor DNS al perfil no instal·la cap de les dues coses per si sola.

Comproveu què ha seleccionat el sistema operatiu, no què ha demanat el perfil. A Linux, resolvectl status mostra el domini i el servidor per enllaç; a Windows, la taula de política d’espais de noms és l’evidència equivalent.

Manteniu el resolutor accessible a través del túnel, o la política apunta a una adreça que no es pot consultar. Una adreça de resolutor a què el túnel no arriba converteix una política que funciona en un temps d’espera esgotat.

Verifiqueu les dues meitats en una reconnexió

Reconnecteu el client després del canvi i inspeccioneu la ruta efectiva cap a una adreça privada i cap a una de pública. Després resoleu un nom privat i un nom públic i confirmeu que cadascun ha utilitzat el resolutor previst. Que un lloc web públic es carregui només demostra la segona meitat, i és la meitat que normalment funciona per casualitat.

Registreu la política acabada en una frase: aquests prefixos i noms utilitzen aquesta connexió, tota la resta segueix el camí local. Després manteniu-la al perfil en lloc de reparar la configuració de l’adaptador després de cada inici de sessió.