Tres deseños resolven o mesmo problema de laboratorio: unha LAN pequena que debe saír por un par WireGuard mentres a pasarela conserva o seu enlace ascendente habitual. O atallo tentador é mover a ruta predeterminada do router dentro do túnel, pero iso rompe a propia ruta de xestión da caixa e todo o demais que reenvía. A opción interesante é o encamiñamento por políticas limitado a unha interface e un prefixo. Escolla entre eles respondendo tres preguntas sobre a máquina que realmente ten.

Decida onde vive a saída

Primeira pregunta: reenvía este host para algo máis? Unha pasarela de laboratorio dedicada pode vivir cunha política de reenvío que descarta por defecto. Un router con deberes de produción non pode, e superpoñer un conxunto de regras competidor sobre un cortalumes xestionado é exactamente como se programan as caídas. Segunda: pode posuír dous obxectos de política e a súa orde entre reinicios? Terceira: o par que ten autoriza o enderezo de orixe do seu túnel e ofrece saída a internet? Un par que só expón unha rede privada é outro produto, e ningún cambio local de encamiñamento o arranxa. Se calquera resposta é non, poña a saída nun espazo de nomes ou nunha máquina virtual dun só uso.

Un espazo de nomes ou unha VM custan memoria e danlle un radio de impacto limpo. O encamiñamento por políticas custa dúas regras e déixalle unha soa máquina que depurar.

Escolla a saída que autoriza a súa orixe

A maioría dos fallos neste laboratorio ocorren antes de que exista unha soa regra de cortalumes. O operador da saída debe aceptar o enderezo de orixe que levan os seus paquetes tras a tradución, que neste deseño é o enderezo do túnel e non o prefixo da LAN. Por iso o enmascaramento pertence ao deseño desde o principio e non como un engadido tardío.

Confirme tres cousas co operador: o par autoriza o enderezo do seu túnel, reenvía IPv4 en lugar de terminar en si mesmo e aplica NAT de saída. Sen a primeira, os seus paquetes chegan e desaparecen. Sen a terceira, saen cunha orixe privada e morren no seguinte salto. Despois comprobe que wg-quick non instala a súa propia ruta predeterminada, o que evita Table = off; ese axuste suprime a creación de rutas, non as comprobacións de AllowedIPs do par nin o seu manexo de DNS.

Dous obxectos de política fan a dirección

A dirección necesita unha táboa e unha regra. A táboa contén dúas rutas: o prefixo da LAN fóra da interface LAN e unha predeterminada fóra do túnel. A regra envía o tráfico que chega pola interface LAN e leva ese prefixo cara á táboa. Use o selector iif xunto coa coincidencia de orixe, porque os paquetes WireGuard propios da pasarela orixínanse localmente e nunca coinciden cunha interface entrante.

O gardián vai antes da consulta, non despois. Ese orde é toda a propiedade de seguridade do deseño.

O gardián é unha segunda regra sobre o mesmo selector cuxo veredicto é unreachable. Délle unha prioridade numérica máis alta para que a consulta siga gañando mentres o túnel está levantado. Cando a ruta do túnel desaparece, a consulta non devolve nada e o gardián detén a busca en lugar de deixala caer á ruta predeterminada WAN da táboa principal.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Pecha a fenda de retroceso antes de abrila

Instale primeiro o gardián e a consulta despois. Facelo ao revés deixa unha xanela de segundos na que o tráfico dun cliente de probas pode alcanzar o enlace ascendente.

O filtro completa o cadro. No gancho forward acepte a dirección da LAN ao túnel para o prefixo de probas e a dirección de retorno establecida, e logo descarte todo o demais; o NAT dese prefixo cara á interface do túnel vai en postrouting. Deixar policy drop na cadea de reenvío é o que converte unha ruta ausente en silencio en vez de nunha fuga. O filtrado de ruta inversa necesita modo permisivo na interface do túnel, porque unha orixe pública que chega desencapsulada ten a súa mellor ruta inversa no lado WAN. Linux toma o maior dos valores all e por interface, así que configurar a interface do túnel non é o mesmo que debilitar a validación en todas partes.

Demóstreo co caso de fallo

Pregúntelle ao núcleo algo preciso nomeando o enderezo de orixe do cliente e a interface pola que chega. Unha consulta sen ambas responde outra pregunta e parecerá correcta en ambos os casos. Despois mire os contadores do cortalumes, o estado de transferencia do par e o propio servizo do cliente.

Probe a retirada como cómpre. Deteña o túnel deixando a regra e o filtro no seu sitio: o cliente debería atascarse e o tráfico propio da pasarela debería seguir funcionando. Despois deteña o par sen tocar a interface local, que é o caso que atrapa os deseños que confían só na presenza da ruta. Por último reinicie e volva comprobar a orde das regras, porque un gancho de desmontaxe que elimina o gardián devolve todo o deseño á táboa principal. Anote o número de táboa, as prioridades e os nomes de interface no tícket de cambio, porque a próxima persoa que engada unha regra será a que rompa isto.

Artigos relacionados