Pools VPN de doble pila: adreçar les dues famílies a strongSwan

Els pools IPv4 i IPv6 interns, els prefixos protegits i la família del túnel extern són tres decisions separades. Planifiqueu cadascuna abans de dir-ne doble pila.

Una passarel·la pot donar a un treballador mòbil tant una adreça virtual IPv4 com una IPv6 mentre el túnel extern encara viatja per IPv4. Són decisions independents, i tractar-les com una sola és on solen esfondrar-se els plans de doble pila. Les famílies internes del client, els prefixos protegits que pot assolir i el transport que porta l’encapsulació són tres tries separades.

La major part de la confusió ve de l’aplicació de la paraula doble pila a un disseny que és de doble pila en un sol lloc. Un servei pot ser de doble pila internament, d’una sola pila a la seva adreça exterior, i funcionar perfectament bé per als clients. El que no pot fer és funcionar per casualitat.

Dues famílies a dins, un sol camí a fora

La connexió exterior és IKE sobre UDP, i necessita una família d’adreces assolible des d’on sigui que estigui el client. Una adreça IPv6 interna no requereix un proveïdor amb IPv6, perquè el paquet intern és càrrega dins del paquet extern. Moltes implementacions que funcionen porten prefixos IPv6 per un enllaç ascendent només IPv4.

El que el camí exterior sí que limita és l’assolibilitat i el pas per NAT. Si la passarel·la només anuncia una adreça IPv4, un client en una xarxa només IPv6 no es pot connectar de cap manera, per molts pools que hàgiu configurat. Decidiu la família exterior segons la vostra població de clients, no segons el pla d’adreces intern.

Doneu al client una adreça a cada família

Demanar les dues famílies és una frase d’una línia al costat del client, sempre que la passarel·la tingui alguna cosa per repartir. Els pools amb nom mantenen les fonts separades de les xarxes de servei, i aquesta és la propietat que fa llegibles les regles de tallafocs sis mesos després.

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 }
    }
  }
}

El vips valor demana una adreça de cada família, i la llista de pools decideix d’on vénen aquestes adreces. La documentació de strongSwan sobre IP virtual cobreix diverses sol·licituds i l’assignació de pools, inclòs el punt que un client que demana una adreça concreta expressa una preferència que el responedor pot anul·lar. No construïu una regla d’accés que assumeixi que el client sempre rep el mateix valor.

Genereu el vostre propi prefix local únic en lloc de copiar el de l’exemple. Dues organitzacions que totes dues fd42::/16 despleguin descobriran la col·lisió la primera vegada que s’interconnectin, i diagnosticar-ho no és agradable.

Els selectors descriuen destinacions, no fonts

Els selectors de trànsit locals de la SA filla diuen quines xarxes protegides hi ha darrere la passarel·la, i els selectors remots descriuen què pot fer servir el client com a font. Una adreça de pool virtual pertany al costat d’origen d’aquesta política; posar-la a la llista de destinacions és una mala lectura habitual de la configuració.

Totes dues famílies necessiten rutes de retorn i reenviament permès a la passarel·la. Afegir un prefix a un selector sense una ruta de tornada al pool produeix un túnel que s’estableix, passa un sol sentit del trànsit i descarta la resposta en silenci. El selector és política, no encaminament.

Manteniu els pools i els prefixos de servei en blocs separats del vostre pla d’adreces. Quan se superposen, una ruta que hauria d’arribar a un host protegit pot coincidir amb una adreça de pool i desaparèixer dins del túnel.

El DNS i el camí de resposta decideixen si sembla acabat

Les respostes del resolutor són independents del transport utilitzat per arribar-hi. Un nom pot retornar un registre A, un registre AAAA o tots dos, i el client tria segons les seves pròpies regles de preferència . Si un servei intern publica un registre AAAA però res no encamina aquest prefix, els clients en xarxes de doble pila provaran primer el camí IPv6 i s’hi quedaran fins que falli. Res de la configuració del túnel no sembla incorrecte mentre això passa.

Així, decidiu per a cada nom quines famílies haurien de ser utilitzables i després comproveu que el prefix corresponent és al selector i té una ruta de retorn. Aquesta és una decisió servei per servei. Publicar tots dos tipus de registre indiscriminadament és com un servei que funciona només amb IPv4 comença a esgotar el temps d’espera per a la meitat dels seus usuaris.

Verifiqueu les dues famílies abans de donar-ho per fet

Una configuració que es carrega no és una configuració que funciona. Llegiu l’estat que informa el dimoni, confirmeu les assignacions de pool i després mireu les rutes que el client ha instal·lat realment.

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

Les dues primeres ordres mostren les SA filles establertes i quins pools encara tenen adreces disponibles, de manera que un pla que funciona per al primer client i falla per al desè es fa visible. Les dues últimes mostren si el client ha rebut una adreça IPv6 global del pool i on aniria realment el trànsit cap a un prefix protegit. Compareu l’adreça assignada amb el pool que heu configurat, no amb l’adreça que esperàveu. Si el responedor ha triat un valor diferent segons la seva política, les rutes i les regles de tallafocs han de continuar encaixant amb el que ha triat.

Després proveu un host protegit per família, i proveu un nom que es resolgui a totes dues. Una prova d’una sola família no us diu res sobre la meitat del pla que no heu exercitat, i aquesta meitat sol ser on viu la ruta que falta.

Articles relacionats