Dual-stapel-VPN-poole: beide adresfamilies in strongSwan hanteer

Binne-IPv4- en IPv6-poole, beskermde prefikse en die buitenste tonnelfamilie is drie afsonderlike besluite. Beplan elkeen voordat jy dit dual-stapel noem.

’n Gateway kan aan ’n reisende gebruiker beide ’n IPv4- en ’n IPv6-virtuele adres gee terwyl die buitenste tonnel steeds oor IPv4 loop. Dit is onafhanklike besluite, en om dit as een te behandel, is waar dual-stapel-planne gewoonlik uitmekaarval. Die kliënt se binneste adresfamilies, die beskermde prefikse wat dit kan bereik, en die vervoer wat die inkapseling dra, is drie afsonderlike keuses.

Die meeste verwarring kom daarvan dat die woord dual-stapel toegepas word op ’n ontwerp wat net op een plek dual-stapel is. ’n Diens kan intern dual-stapel wees, enkelstapel op sy buitenste adres, en steeds heeltemal goed vir kliënte werk. Wat dit nie kan doen nie, is per ongeluk werk.

Twee families binne, een pad buite

Die buitenste verbinding is IKE oor UDP, en dit het een bereikbare adresfamilie nodig van waar die kliënt ook al is. ’n Binne-IPv6-adres vereis nie ’n ISP met IPv6-vermoë nie, want die binne-pakket is vrag binne die buitenste een. Baie werkende ontplooiings dra IPv6-prefikse deur ’n slegs-IPv4-opskakel.

Wat die buitenste pad wel beperk, is bereikbaarheid en NAT-deurgang. As die gateway net ’n IPv4-adres adverteer, kan ’n kliënt op ’n slegs-IPv6-netwerk glad nie konnekteer nie, maak nie saak watter poele jy opgestel het nie. Besluit die buitenste familie op grond van jou kliëntpopulasie, nie op grond van die binne-adresplan nie.

Gee die kliënt ’n adres in elke familie

Om albei families te versoek, is ’n eenreëlverklaring aan die kliëntkant, mits die gateway iets het om uit te deel. Benoemde poele hou die bronne apart van die diensnetwerke, en dit is die eienskap wat firewallreëls ses maande later leesbaar maak.

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

Die vips waarde vra vir ’n adres van elke familie, en die poellys besluit waar daardie adresse vandaan kom. Die strongSwan-dokumentasie oor virtuele IP’s dek veelvuldige versoeke en poeltoewysing, insluitend die punt dat ’n kliënt wat ’n spesifieke adres vra, net ’n voorkeur uitdruk wat die responder mag ignoreer. Moenie ’n toegangsreël bou wat aanvaar dat die kliënt altyd dieselfde waarde kry nie.

Genereer jou eie unieke-lokale prefiks in plaas daarvan om die voorbeeld een te kopieer. Twee organisasies wat albei fd42::/16 ontplooi, sal die botsing ontdek die eerste keer dat hulle aan mekaar koppel, en die diagnose daarvan is onaangenaam.

Selektors beskryf bestemmings, nie bronne nie

Die kind-SA se plaaslike verkeersselektors sê watter beskermde netwerke agter die gateway sit, en die remote-selektors beskryf wat die kliënt as bron mag gebruik. ’n Virtuele poeladres hoort aan die bronkant van daardie beleid; om dit in die bestemmingslys te sit, is ’n algemene wanlees van die konfigurasie.

Albei families het terugroetes en toegelate forwardering op die gateway nodig. Om ’n prefiks by ’n selektor te voeg sonder ’n roete terug na die poel, lewer ’n tonnel wat vestig, een rigting verkeer deurlaat en die antwoord stilweg laat val. Die selektor is beleid, nie roetering nie.

Hou die poele en die diensprefikse in aparte blokke van jou adresplan. Wanneer hulle oorvleuel, kan ’n roete wat ’n beskermde gasheer moet bereik, ’n poeladres pas en in die tonnel verdwyn.

DNS en die antwoordpad bepaal of dit klaar voel

Resolver-antwoorde is onafhanklik van die vervoer wat gebruik word om die resolver te bereik. ’n Naam kan ’n A-rekord, ’n AAAA-rekord of albei teruggee, en die kliënt kies volgens sy eie voorkeurreëls . As ’n interne diens ’n AAAA-rekord publiseer maar niks daardie prefiks routeer nie, sal kliënte op dual-stapel-netwerke die IPv6-pad eerste probeer en daar sit tot dit misluk. Niks in die tonnelkonfigurasie lyk verkeerd terwyl dit gebeur nie.

Besluit dus per naam watter families bruikbaar moet wees, en kontroleer dan dat die ooreenstemmende prefiks in die selektor is en ’n terugroete het. Dit is ’n besluit per diens. Om albei rekordtipes blindelings te publiseer, is hoe ’n werkende slegs-IPv4-diens vir die helfte van sy gebruikers begin uittime.

Verifieer albei families voordat jy dit klaar noem

Konfigurasie wat laai, is nie konfigurasie wat werk nie. Lees die toestand wat die daemon rapporteer, bevestig die poeltoewysings en kyk dan na die roetes wat die kliënt werklik geïnstalleer het.

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

Die eerste twee opdragte wys die gevestigde kind-SA’s en watter poele nog adresse beskikbaar het, sodat ’n plan wat vir die eerste kliënt werk en vir die tiende misluk, sigbaar word. Die laaste twee wys of die kliënt ’n globale IPv6-adres uit die poel gekry het en waar verkeer na ’n beskermde prefiks werklik sou gaan. Vergelyk die toegewysde adres met die poel wat jy opgestel het, nie met die adres waarop jy gehoop het nie. As die responder onder sy beleid ’n ander waarde gekies het, moet die roetes en firewallreëls steeds by sy keuse pas.

Toets dan een beskermde gasheer per familie, en toets ’n naam wat na albei resolve. ’n Enkelfamilie-toets sê niks oor die helfte van die plan wat jy nie geoefen het nie, en daardie helfte is gewoonlik waar die ontbrekende roete sit.

Verwante artikels