Un dispositiu per un VPN del router necessita tres regles, no un commutador

En un VPN del router no hi ha cap commutador per dispositiu; el commutador que busques és una drecera que escriu regles d’encaminament per política en nom teu. En el moment que un portàtil, un rang de ports, una llista d’adreces o un segment LAN ha d’usar el túnel mentre la resta continua per la WAN, estàs construint una ruta de política, no activant una funció. La feina té tres peces mòbils, i cada una falla de manera diferent: una taula marcada sense ruta sembla silenci, una marca aplicada a la cadena equivocada sembla que no ha passat res, i una regla NAT que falta sembla un túnel que connecta i no transporta res. Encara hi ha dues peces que desapareixen perquè no apareixen mai a la regla mangle, i són DNS i IPv6.

El mite: el túnel és un paràmetre del client

Un client VPN al router fa bé una cosa contundent: posa 0.0.0.0/0 a la taula d’encaminament principal i l’apunta al túnel. WireGuard ho deriva d’AllowedIPs, OpenVPN d’un redirect-gateway empès, i tots dos canvien el camí de cada amfitrió darrere del router. Estrenyer AllowedIPs o afegir route-nopull canvia què instal·la el client. No canvia a qui s’aplica la instal·lació, perquè el client no veu mai dispositius. Només veu paquets.

Triar per origen o destinació és una decisió d’encaminament, així que pertany a la capa de política del router: una regla mangle més una segona taula a RouterOS, un MARK més una ip rule a OpenWrt o DD-WRT, o una regla de tallafoc amb el túnel com a porta d’enllaç a pfSense. La recepta de client WireGuard de Netgate és la que cal llegir abans d’endevinar, perquè en aquesta plataforma la porta d’enllaç de la regla, l’assignació d’interfície i l’entrada NAT de sortida han de coincidir abans que un sol client faci servir el túnel.

La segona meitat del mite és el segon router. Comprar una altra caixa o moure el dispositiu a un SSID de convidats sovint funciona, i la raó no és el maquinari: posa el dispositiu a la seva pròpia subxarxa, cosa que et dona el selector d’origen que el firmware ja entén. Si pots definir aquest segment al router que tens, la caixa extra resol un problema que no tenies.

Primera peça: un túnel que no és la ruta per defecte

A RouterOS, afegeix el client sense ruta per defecte i dona al túnel la seva pròpia taula. La primera ruta és la per defecte marcada; la segona és la meitat del fracàs.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

La ruta unreachable és el motiu pel qual una taula marcada guanya una llista d’excepcions a la taula principal. Quan el túnel cau, els paquets marcats reben un unreachable immediat en lloc de tornar silenciosament a la WAN, així que el fracàs apareix al missatge d’error de l’aplicació i no en una pàgina de geolocalització que consultes una hora després.

RouterOS 7 separa el que 6.x mantenia junt: declares la taula amb /routing table add name=vpn fib i després la referencies pel nom a la ruta i a la regla mangle. Un fragment de 6.x que posa routing-mark en línia sense definir la taula es carrega net i no coincideix amb res. L’altre cas clàssic són dues meitats 0.0.0.0/1, o dues rutes per defecte a la mateixa distància en una taula: el nucli tria una, i el comportament pot canviar després d’un reinici.

Segona peça: marca abans de la consulta de ruta

El selector decideix quins paquets entren en aquesta taula. RouterOS normalment comença amb una llista d’adreces per a la política de destinació, o amb una adreça d’origen per a la política de dispositiu:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

El firmware de Linux fa el mateix amb una marca netfilter i una regla que porta els paquets marcats a una taula que has omplert:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

La cadena no és una qüestió d’estil. Quan un paquet arriba a FORWARD, la consulta de ruta ja ha passat, així que un MARK o un DROP allà només pot reescriure o descartar. La marca ha de caure a PREROUTING per al trànsit reenviat i a OUTPUT per al trànsit que origina el router, que és on viuen el DNS, l’NTP i les comprovacions d’actualització del router. Aquest camí de sortida és la raó habitual que una configuració totalment tunelitzada encara respongui des del resolutor de l’ISP en una prova de fuites.

La política de dispositiu necessita una coincidència que no es desplaci. Reserva l’adreça al DHCP o fes coincidir una interfície per a un segment dedicat; una adreça que després passa a un altre dispositiu aplica el túnel silenciosament al client equivocat. Un pont per SSID amb la seva pròpia subxarxa és la versió més duradora de la mateixa idea, i dona a les regles IPv6 un lloc on viure.

Tercera peça: NAT, DNS i l’excepció de la LAN

El trànsit que surt pel túnel necessita una adreça d’origen que el costat llunyà respongui. Limita la traducció a la interfície del túnel: out-interface=VPN_NAME a RouterOS, -o tun0 a Linux, una entrada NAT de sortida coincident a pfSense. Una regla masquerade sense aquest abast reescriu trànsit que volies deixar tranquil, i el símptoma és que el dispositiu no tunelitzat perd la seva adreça pública.

L’excepció de la LAN causa més fils de suport que el túnel mateix. Si la taula marcada només té una ruta per defecte, una destinació d’impressora o NAS des del dispositiu seleccionat coincideix amb aquesta per defecte i desapareix dins del túnel. Afegeix la ruta LAN a la mateixa taula, o exclou la subxarxa local al selector; totes dues funcionen, i l’exclusió és més fàcil de mantenir correcta quan afegeixis VLANs més endavant.

DNS pren un camí a part. Les consultes que el router reenvia s’originen al router i segueixen OUTPUT, no la marca de reenviament, així que un portàtil totalment tunelitzat encara pot resoldre a través de l’ISP. Apunta els clients a un resolutor abastable pel túnel, o marca el propi trànsit del port 53 del router, i després comprova l’adreça resolta en lloc de suposar que la resposta ha viatjat amb la petició web.

Quan la regla coincideix però l’aplicació encara usa la WAN

Les llistes de destinacions envelleixen malament. Un nom es resol a una adreça que no és a la llista, així que la petició agafa la WAN mentre cada prova que has fet contra l’adreça llistada funcionava. Actualitza la llista des del mateix resolutor que fa servir el client, i prefereix un selector basat en origen quan de debò vols tot el trànsit d’un dispositiu.

IPv6 és el desviament silenciós. El dispositiu té una segona família d’adreces amb la seva pròpia ruta per defecte i el seu propi conjunt de regles, i fer coincidir només l’adreça IPv4 és mitja política. Aplica el mateix selector a ip6tables o a l’equivalent de nftables, o desactiva IPv6 en aquest segment deliberadament i no per accident.

Les connexions establertes també compten. Una entrada conntrack creada abans del canvi segueix el camí vell fins que caduca, així que un navegador que ha quedat obert durant l’edició sembla exactament una regla que mai es va aplicar. Obre una connexió nova, o buida l’estat, abans de jutjar la política.

Verifica amb dos dispositius i un reinici

Prova el dispositiu que ha d’anar pel túnel i el que no, i compara el segon salt en lloc d’un número de velocitat. Un traceroute des de cadascun mostra o la porta d’enllaç del túnel o la de l’ISP al segon salt; si tots dos semblen iguals, la marca o la taula no fa el que diu la regla. Fes servir connexions noves per a la prova.

Després reinicia. L’ordre d’arrencada és on una política que funciona es converteix en una de trencada, perquè el client ha d’estar actiu abans que s’instal·li la ruta unreachable, i una instantània desada que restaura el conjunt de regles antic sobreescriurà la teva taula. Comprova que cada regla és a la configuració desada i que la ruta per defecte marcada existeix després de l’arrencada, no només després que l’hagis escrita.

Si alguna cosa falla, treu primer la marca i mira si torna el trànsit normal, després treu la taula. Aquest ordre et diu si persegueixes un problema d’encaminament o un de tallafoc, i deixa la casa amb una impressora que funciona mentre acabes la feina.