Connecteu el túnel, executeu ip route, i la porta d’enllaç per defecte original continua allà. El pensament següent és que el client no ha assumit la ruta, així que esborreu la ruta per defecte manualment i perdeu la connectivitat del tot. Aquesta entrada ha de romandre. Amb redirect-gateway def1, OpenVPN instal·la dues rutes més específiques que superen la ruta per defecte ordinària en lloc de substituir-la. La porta d’enllaç antiga es queda i deixa de portar el trànsit que estàveu provant.

Què fa realment def1

El senyal afegeix 0.0.0.0/1 i 128.0.0.0/1, totes dues apuntant al túnel. 0.0.0.0/1 pren cada adreça el primer octet de la qual va de 0 a 127, i 128.0.0.0/1 pren de 128 a 255, així que cada destinació IPv4 té una coincidència més específica que la ruta per defecte antiga. La longitud del prefix, no la mètrica, decideix quina ruta guanya.

Deixar la ruta per defecte original al seu lloc és deliberat. El client no ha de recordar què ha substituït i no reescriu la ruta que porta la seva pròpia connexió al servidor VPN. En desconnectar, elimina les dues meitats de ruta i la taula torna al que era.

Per què /1 i no /0

L’encaminament tria el prefix coincident més llarg, no la mètrica més baixa, així que una /1 guanya una /0 digui el que digui la mètrica de la ruta per defecte. Totes dues meitats existeixen perquè una /1 només cobreix la meitat de l’espai; amb només 0.0.0.0/1 present, tot el que hi ha des de 128.0.0.0 en amunt continua seguint la ruta per defecte antiga, cosa que produeix el símptoma confús que alguns llocs funcionin i d’altres no.

Pujar o baixar la mètrica de la ruta per defecte antiga no canvia res, i una ruta per defecte amb mètrica més baixa en una altra interfície tampoc no roba el trànsit. La longitud del prefix decideix primer, i només els prefixos iguals recorren a la mètrica.

Llegiu una taula d’encaminament real

Un amfitrió connectat pot mostrar les tres entrades alhora, amb el túnel portant les meitats i la porta d’enllaç original encara a la llista. Les adreces són exemples i no una configuració per copiar, perquè els noms d’interfície, la topologia del túnel i les rutes addicionals varien segons la plataforma i el client.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

L’important és la relació: dues meitats concretes per sobre d’una ruta per defecte general. La línia de la porta d’enllaç antiga es queda perquè res no l’ha substituïda.

Comproveu quina ruta pren realment el paquet

Les rutes més específiques encara poden guanyar: una ruta per a un rang privat, una subxarxa local o l’adreça pròpia del servidor VPN és més llarga que una /1. El túnel necessita un camí exterior cap al seu servidor, i tornar a enviar aquesta connexió dins del túnel el trencaria immediatament. A Linux, pregunteu al nucli en lloc de llegir la taula a ull: ip route get amb la destinació que us interessa imprimeix la ruta triada, la interfície i l’origen. Si hi ha encaminament per polítiques configurat, reviseu també les regles, perquè una regla pot triar una altra taula abans que es consulti la principal.

Si només una part d’IPv4 es comporta malament, confirmeu que totes dues meitats són instal·lades i després busqueu una excepció que coincideixi amb la destinació que falla. Esborrar la ruta per defecte antiga no és cap solució, i elimina la ruta que el client necessita per desmuntar el túnel netament.

Què no cobreix def1

Dues entrades IPv4 no diuen res sobre IPv6: un amfitrió amb connectivitat IPv6 continua usant la seva pròpia ruta per defecte fins que alguna cosa redirigeixi aquella família per separat, i per això en una xarxa de doble pila part del trànsit sembla evitar el túnel. Altres clients i gestors de xarxa implementen l’encaminament de túnel complet de manera diferent, i les seves taules no coincidiran. El comportament de def1 descrit aquí pertany al senyal documentat d’OpenVPN, no a cada VPN de la màquina.

Un kill switch respon una altra pregunta: què fa la màquina quan cau el túnel. La precedència de rutes decideix on va el trànsit mentre el túnel és actiu; no decideix què fa després un tallafoc. Ordre de treball: llegiu la taula, confirmeu que hi ha totes dues meitats, executeu ip route get per a la destinació que falla, reviseu les regles de política i després mireu IPv6 per separat. Deixeu la ruta per defecte antiga on és.

Articles relacionats