Pools VPN de dobre pila: dirixir as dúas familias en strongSwan

Os pools IPv4 e IPv6 internos, os prefixos protexidos e a familia do túnel externo son tres decisións separadas. Planifique cada unha antes de chamalo dobre pila.

Unha pasarela pode dar a un usuario móbil tanto un enderezo virtual IPv4 como un IPv6 mentres o túnel externo segue viaxando por IPv4. Son decisións independentes, e tratalas como unha soa é onde adoitan vir abaixo os plans de dobre pila. As familias internas do cliente, os prefixos protexidos que pode alcanzar e o transporte que leva a encapsulación son tres eleccións separadas.

A maior parte da confusión vén de aplicar a expresión dobre pila a un deseño que é de dobre pila só nun lugar. Un servizo pode ser de dobre pila internamente, de pila única no seu enderezo exterior, e aínda así funcionar perfectamente ben para os clientes. O que non pode é funcionar por casualidade.

Dúas familias dentro, un só camiño fóra

A conexión exterior é IKE sobre UDP, e necesita unha familia de enderezos accesible desde onde estea o cliente. Un enderezo IPv6 interno non require un provedor con IPv6, porque o paquete interno é carga útil dentro do externo. Moitas implantacións que funcionan transportan prefixos IPv6 por unha ligazón ascendente só IPv4.

O que si limita o camiño exterior é a accesibilidade e o tránsito por NAT. Se a pasarela anuncia só un enderezo IPv4, un cliente nunha rede só IPv6 non pode conectarse en absoluto, por moitos pools que configurase. Decida a familia exterior segundo a súa poboación de clientes, non segundo o plan de enderezos interno.

Dea ao cliente un enderezo en cada familia

Solicitar ambas as familias é unha soa liña no lado do cliente, sempre que a pasarela teña algo que repartir. Os pools con nome manteñen as fontes separadas das redes de servizo, e esa é a propiedade que fai lexibles as regras de devasas seis meses despois.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

O vips valor pide un enderezo de cada familia, e a lista de pools decide de onde veñen eses enderezos. A documentación de strongSwan sobre IP virtual cobre varias solicitudes e a asignación de pools, incluído o punto de que un cliente que pide un enderezo concreto expresa unha preferencia que o respondedor pode anular. Non constrúa unha regra de acceso que supoña que o cliente recibe sempre o mesmo valor.

Xere o seu propio prefixo local único en lugar de copiar o do exemplo. Dúas organizacións que ambas fd42::/16 o despreguen descubrirán a colisión a primeira vez que se interconecten, e diagnosticalo non é agradable.

Os selectores describen destinos, non fontes

Os selectores de tráfico locais da SA filla din que redes protexidas están detrás da pasarela, e os selectores remotos describen que pode usar o cliente como fonte. Un enderezo de pool virtual pertence ao lado de orixe desa política; poñelo na lista de destinos é unha mala lectura habitual da configuración.

Ambas as familias necesitan rutas de retorno e reenvío permitido na pasarela. Engadir un prefixo a un selector sen unha ruta de volta ao pool produce un túnel que se establece, pasa unha soa dirección do tráfico e descarta a resposta en silencio. O selector é política, non encamiñamento.

Manteña os pools e os prefixos de servizo en bloques separados do seu plan de enderezos. Cando se solapan, unha ruta que debería chegar a un host protexido pode coincidir cun enderezo de pool e desaparecer dentro do túnel.

O DNS e o camiño de resposta deciden se parece rematado

As respostas do resolutor son independentes do transporte usado para chegar a el. Un nome pode devolver un rexistro A, un rexistro AAAA ou ambos, e o cliente elixe segundo as súas propias regras de preferencia. Se un servizo interno publica un rexistro AAAA pero nada encamiña ese prefixo, os clientes en redes de dobre pila probarán primeiro o camiño IPv6 e quedarán alí ata que falle. Nada na configuración do túnel parece incorrecto mentres iso ocorre.

Así que decida por nome que familias deberían ser utilizables e despois comprobe que o prefixo correspondente está no selector e ten unha ruta de retorno. É unha decisión servizo por servizo. Publicar ambos os tipos de rexistro sen distinción é como un servizo que funciona só con IPv4 comeza a esgotar o tempo de espera para a metade dos seus usuarios.

Verifique ambas as familias antes de darlo por feito

Unha configuración que carga non é unha configuración que funciona. Lea o estado que informa o daemon, confirme as asignacións de pool e despois mire as rutas que o cliente instalou realmente.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Os dous primeiros comandos mostran as SA fillas establecidas e que pools aínda teñen enderezos dispoñibles, de modo que un plan que funciona para o primeiro cliente e falla para o décimo faise visible. Os dous últimos mostran se o cliente recibiu un enderezo IPv6 global do pool e onde iría realmente o tráfico cara a un prefixo protexido. Compare o enderezo asignado co pool que configurou, non co enderezo que esperaba. Se o respondedor escolleu un valor distinto segundo a súa política, as rutas e as regras de devasas deben seguir encaixando co que escolleu.

Despois probe un host protexido por familia, e probe un nome que resolva a ambas. Unha proba dunha soa familia non lle di nada sobre a metade do plan que non exercitou, e esa metade adoita ser onde vive a ruta que falta.

Artigos relacionados