Grupos de pares de WireGuard no concentrador: propiedade da orixe máis política
Manteña os grupos de pares separados con enderezos de orixe estreitos por par e unha política de reenvío, sen unha interface de túnel separada para cada grupo.
Un concentrador que executa WireGuard pode manter os grupos de pares separados sen unha interface nin unha táboa de rutas separada por grupo. Dous mecanismos fan o traballo, e confundilos é a razón habitual de que unha política pareza correcta e non faga nada. Unha capa decide quen pode reclamar un enderezo de orixe. A outra decide cara a onde se permite saír a ese paquete.
Dúas tarefas, mantidas á parte
A capa de túnel responde a unha pregunta estreita: se a chave deste par autorizou este enderezo de orixe interno. A capa de reenvío responde a unha máis ampla: se este paquete pode saír cara a ese destino. Ningunha responde á pregunta da outra, e ningunha é por si soa unha política de acceso completa.
Esa separación é a razón de que un par poida estar autenticado, ben enderezado e aínda así non poder alcanzar un equipo ao que non debería chegar. Tamén explica o contrario: unha regra de cortalumes que o permite todo non demostra nada sobre quen pode reclamar que enderezo.
Deseñe as dúas capas xuntas e despois probe ambas. Unha configuración correcta nunha capa e sen probar na outra falla aberta ou pechada segundo o valor predeterminado.
Dea a cada par só o seu propio enderezo
Os pares con varios equipos téntano a conceder todo o rango do grupo no lado do servidor. Ese permiso é unha reclamación de enderezo de orixe, así que un cliente comprometido ou mal configurado pode presentar calquera enderezo do rango e o túnel aceptarao. Asigne un /32 por par para o seu propio enderezo interno. Configure rangos de grupo só nos clientes, onde describen que destinos pode alcanzar ese cliente en lugar de que orixes pode usar.
O cortalumes entón compara unha orixe na que pode confiar. Unha regra escrita para o rango do grupo segue a ser unha agrupación útil, e só cobra sentido cando ningún par individual pode reclamar un enderezo que pertence a outro membro.
Escriba a política de reenvío que separa os grupos
O tráfico interesante aquí entra e sae pola mesma interface de túnel, así que cruza a ruta de reenvío e non a ruta de entrada do equipo. As regras pertencen á cadea de reenvío existente do xestor de cortalumes que sexa dono do equipo, e son fragmentos, non un conxunto de regras completo.
iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept iifname "wg0" oifname "wg0" drop
As dúas primeiras regras permiten o tráfico dentro de cada grupo. A última bloquea todo o demais que cruza esa interface, e iso é o que produce o illamento entre os grupos. Engada regras explícitas para a outra familia de enderezos se as necesita, porque un descarte escrito para IPv4 non autoriza nin describe o comportamento de IPv6.
A orde decide se a política se aplica
A orde das regras importa máis que o fragmento en si. Unha regra xenérica que acepta conexións establecidas e está colocada antes destas entradas deixa continuar un fluxo antigo entre grupos, así que o illamento só se aplica a conexións novas. Decida cal deses dous resultados quere antes de recargar.
Un veredicto de aceptación tampouco é sempre definitivo entre cadeas no mesmo gancho. Se outra cadea base se executa despois, a política efectiva é a combinación, así que inspeccione os contadores en lugar do ficheiro que editou. Os contadores son a evidencia máis barata dispoñible. Unha regra sen reconto de paquetes non coincide, e unha regra que coincide mentres unha cadea posterior acepta dille que o descarte está no lugar equivocado.
Probe a matriz, non o número de ficheiros
Constrúa unha matriz pequena de resultados esperados e comprobe cada cela. Do grupo A ao grupo A debería funcionar, do grupo B ao grupo B debería funcionar, e de A a B non debería, en ambos os sentidos e para ambas as familias de enderezos se as admite.
nft list ruleset wg show wg0 allowed-ips ping -c 2 10.66.10.5 conntrack -L -s 10.66.20.7 2>/dev/null | head
As dúas primeiras mostran que está configurado. O ping desde un membro do grupo equivocado mostra que ocorre en realidade. A lista de conntrack mostra se un fluxo máis antigo segue aceptándose, e así é como un cambio de illamento falla silenciosamente ao entrar en vigor.
Os servizos de equipo no concentrador e o acceso a unha LAN detrás del son rutas separadas con política separada. Anote cales delas cobre a matriz, porque unha proba que só comproba tráfico entre pares non di nada sobre ningunha das dúas.