Encamiñamento por orixe para dous pools VPN: o que se lle escapa á súa regra

Dous pools de clientes, unha pasarela e o plan parece trivial: unha regra envía o primeiro pool polo enlace rápido, outra envía o segundo pool por un túnel de socio. Despois as regras están no seu sitio e o segundo pool segue saíndo pola ruta por defecto. A regra non está rota. A orixe do paquete non é o que o autor esperaba no momento da consulta, porque a tradución e a consulta ocorren en puntos distintos da viaxe do mesmo paquete, e a orde é a contraria do diagrama mental que debuxa a maioría.

A consulta ocorre antes de que se reescriba a orixe

Para un paquete reenviado desde un cliente VPN, o núcleo executa unha secuencia fixa. Chega á interface do túnel, pasa por prerouting onde viven conntrack e DNAT, despois tómase a decisión de encamiñamento, despois o reenvío, despois postrouting, onde SNAT se aplica ao final. Unha regra da forma from consúltase durante esa decisión de encamiñamento, o que significa que ve o enderezo orixinal do cliente, non o traducido.

Así que engadir unha regra de masquerade non cambia que política coincide co fluxo saínte. O que cambia é o que ve o extremo remoto e, por tanto, que camiño de volta existe. Son dúas consecuencias distintas, e as revisións de cambios confúndeas constantemente. Sepáreas e o deseño adoita quedar claro nun minuto.

É na dirección de resposta onde o enderezo traducido aparece nas regras. Un paquete que volve á pasarela vai dirixido ao enderezo traducido, e se ten regras de política baseadas no destino ou na interface pola que chegou, ese é o valor que vai comparar. A mesma conexión, unha fonte de verdade distinta en cada dirección.

Dous pools con orixes distintas si necesitan táboas distintas, e o deseño é sólido. O que a táboa anterior descarta é o atallo de depurar mirando que recibiu o sitio remoto e deducir a regra a partir diso.

Unha proba desde a pasarela non é unha proba do pool

O tráfico que xera a propia pasarela nunca pasa por prerouting, porque non chegou por ningunha interface. Encamíñase na ruta de saída, co enderezo da propia pasarela como orixe, e unha regra from baseada nun rango de clientes non coincidirá. Cada ticket deste ámbito que di que funciona desde a máquina pero non desde o cliente é ese mesmo feito repetido.

Simule o cliente en lugar de aproximalo. A consulta de encamiñamento pódese preguntar directamente, cunha orixe e unha interface de entrada:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Execúteo unha vez por pool. Se os dous comandos devolven a mesma interface, as regras non separan os pools, e o motivo é ou unha regra que falta ou unha regra de maior prioridade que coincide con ambos. Se devolven interfaces distintas pero o cliente segue fallando, o fallo está despois da consulta e pode deixar de mirar as regras.

Prioridade, non posición no ficheiro

As regras avalíanse en orde ascendente de prioridade, e o número é o que importa, non a orde en que as escribiu. A táboa local está na prioridade 0, a táboa main en 32766 e a regra por defecto en 32767, por iso unha regra engadida coa prioridade por defecto cae preto do final da lista e perde contra case todo.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Unha prioridade explícita fai visible a orde pretendida no ficheiro e na revisión. Tamén evita que unha adición posterior se adiante en silencio a unha regra existente, que é a causa máis habitual de que unha política que funciona deixe de funcionar tras un cambio non relacionado.

Unha regra coincidente que apunta a unha táboa incompleta é a outra trampa. Se a táboa 201 contén unha ruta por defecto pero ningunha ruta ao destino, o paquete descártase ou énviase ao lugar equivocado, e a regra parece perfectamente correcta illada. Lea a táboa, non só a regra. Unha regra é un punteiro, e unha táboa baleira é un punteiro ao nada.

O camiño de volta ten que existir igualmente

A política de orixe escolle unha saída. Non crea un camiño de volta. Se o segundo pool sae por un túnel de socio, o socio ten que saber como chegar a 172.31.8.0/24, xa sexa cunha ruta de volta á pasarela ou recibindo enderezos traducidos que xa coñece.

Escoller entre iso é unha decisión de deseño con consecuencias visibles. Encamiñar o rango de clientes de volta conserva a identidade de cada cliente no socio e esixe que acepte o seu prefixo. A tradución esconde o pool detrás dun enderezo e esixe que o socio acepte só ese enderezo, a costa de que os seus rexistros e os seus xa non coincidan sobre quen se conectou.

Escolla o que escolla, escríbao xunto á definición do pool. Unha ruta de volta que só existe na memoria de alguén é xusto o tipo de cousa que sobrevive ata que o socio cambia un cortalumes, e despois custa un día reconstruíla.

Non atrape o túnel propio da pasarela na política

As regras que escribe para clientes tamén se aplican ao tráfico que xera a pasarela, salvo que o exclúa. Unha regra ampla baseada nunha marca ou na interface de saída pode capturar a conexión propia da pasarela co socio, e entón o túnel que transporta a política é encamiñado pola política. Iso produce un bucle ou unha caída que parece un fallo do provedor.

Limite cada regra tanto como permita o deseño: prefixo de orixe, interface de entrada e, onde se admita, unha marca que só leven os paquetes de clientes. Despois probe a conectividade propia da pasarela tras cada cambio de regras, porque o fallo é autorreferente e non aparece nunha proba desde o cliente.

A páxina de manual de ip-rule documenta a semántica do selector e da prioridade. Combine-a cunha proba de consulta por pool e o deseño vólvese comprobable, que é a diferenza entre un encamiñamento por política que aguanta un ano e un que todos temen tocar.