Dual-stack VPN-pools: beide adresfamyljes yn strongSwan oansprekke

Ynderlike IPv4- en IPv6-pools, beskerme prefiksen en de bûtenste tunnel-famylje binne trije aparte besluten. Plan elk ien foardat jo it dual-stack neame.

In gateway kin in reizgjende brûker sawol in IPv4- as in IPv6-firtuële adres jaan, wylst de bûtenste tunnel noch oer IPv4 giet. Dat binne ûnôfhinklike besluten, en it behanneljen fan har as ien is wêr’t dual-stack-plannen meastentiids útinoar falle. De ynderlike famyljes fan ’e klant, de beskerme prefiksen dy’t it berikke kin, en it ferfier dat de ynkapseling draacht binne trije aparte karren.

It measte betizing komt fan it wurd dual-stack dat tapast wurdt op in ûntwerp dat mar op ien plak dual-stack is. In tsjinst kin yntern dual-stack wêze, single-stack op syn bûtenadres, en dochs perfekt wurkje foar klanten. Wat it net kin, is by ûngelok wurkje.

Twa famyljes binnen, ien paad bûten

De bûtenste ferbining is IKE oer UDP, en dy hat ien berikbere adresfamylje nedich fan wêr’t de klant ek is. In ynderlik IPv6-adres freget gjin provider mei IPv6, om’t it ynderlike pakket lading is yn it bûtenste. In soad wurkjende ynstallaasjes drage IPv6-prefiksen troch in uplink dy’t allinnich IPv4 hat.

Wat it bûtenste paad wol beheind, is berikberens en NAT-trochgong. As de gateway allinnich in IPv4-adres oankundiget, kin in klant op in netwurk mei allinnich IPv6 hielendal net ferbine, hokker pools jo ek konfigurearre hawwe. Beslis de bûtenste famylje op basis fan jo klantpopulaasje, net fan it ynderlike adresplan.

Jou de klant in adres yn elke famylje

It freegjen fan beide famyljes is oan ’e klantkant ien rigel, mits de gateway wat te ferpartsjen hat. Neamde pools hâlde de boarnen apart fan ’e tsjinstnetwurken, en dat is de eigenskip dy’t firewallregels seis moannen letter lêsber makket.

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

De vips wearde freget in adres fan elke famylje, en de poallist beslút wêr’t dy adressen wei komme. De strongSwan-dokumintaasje oer firtuële IP’s behannelt meardere oanfragen en pooltawizing, ynklusyf it punt dat in klant dy’t in spesifyk adres freget allinnich in foarkar útdrukt dy’t de responder oerskriuwe mei. Bou gjin tagongsregel dy’t oannimt dat de klant altyd deselde wearde krijt.

Generearje jo eigen unike-lokale prefiks ynstee fan it foarbyld te kopiearjen. Twa organisaasjes dy’t beide fd42::/16 it útrôle, sille de botsing ûntdekke de earste kear dat se mei-inoar ferbine, en it diagnoaze dêrfan is net noflik.

Selektors beskriuwe bestimmingen, net boarnen

De lokale ferkiersselektors fan ’e bern-SA sizze hokker beskerme netwurk efter de gateway sitte, en de selektors op ôfstân beskriuwe wat de klant as boarne brûke mei. In firtuële pooladres heart by de boarnkant fan dy belied; it yn ’e bestimmingslist sette is in foarkommende ferkearde lêzing fan ’e konfiguraasje.

Beide famyljes hawwe weromrûtes en tastiene trochstjoering op ’e gateway nedich. In prefiks oan in selektor taheakje sûnder rûte werom nei de pool smyt in tunnel op dy’t him fêstiget, ien rjochting ferkier trochlit en it antwurd stilwei weilitten. De selektor is belied, gjin routing.

Hâld de pools en de tsjinstprefiksen yn aparte blokken fan jo adresplan. As se oerlaapje, kin in rûte dy’t in beskerme host berikke moat in pooladres treffe en yn ’e tunnel ferdwine.

DNS en it antwurdpaad beslisse oft it klear fielt

Antwurden fan de resolver binne ûnôfhinklik fan it ferfier dat brûkt wurdt om de resolver te berikken. In namme kin in A-record, in AAAA-record of beide weromjaan, en de klant kliest neffens syn eigen foarkarsregels. As in ynderlike tsjinst in AAAA-record publisearret mar neat dat prefiks rûtet, sille klanten op dual-stack-netwurken earst it IPv6-paad besykje en dêr sitte oant it mislearret. Neat yn ’e tunnelkonfiguraasje liket ferkeard wylst dat bart.

Beslis dus per namme hokker famyljes brûkber wêze moatte, en kontrolearje dan dat it oerienkommende prefiks yn ’e selektor sit en in weromrûte hat. Dat is in beslissing per tsjinst. It sûnder ûnderskied publisearjen fan beide recordtypen is hoe’t in wurkjende tsjinst mei allinnich IPv4 foar de helte fan syn brûkers begjint te ferfallen.

Ferifiearje beide famyljes foardat jo it klear neame

Konfiguraasje dy’t lade, is gjin konfiguraasje dy’t wurket. Lês de status dy’t de daemon rapportearret, befêstigje de pooltawizingen en besjoch dan de rûtes dy’t de klant eins ynstallearre hat.

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

De earste twa opdrachten litte de fêstige bern-SA’s sjen en hokker pools noch adressen frij hawwe, sadat in plan dat foar de earste klant wurket en foar de tsiende mislearret sichtber wurdt. De lêste twa litte sjen oft de klant in globale IPv6-adres út ’e pool krigen hat en wêr’t ferkier nei in beskerme prefiks eins hinne soe. Ferlykje it tawiisde adres mei de pool dy’t jo konfigurearre hawwe, net mei it adres dêr’t jo op hope hiene. As de responder ûnder syn belied in oare wearde keas, moatte de rûtes en firewallregels noch altyd by syn kar passe.

Test dan ien beskerme host per famylje, en test in namme dy’t nei beide resolvet. In test mei ien famylje seit jo neat oer de helte fan it plan dy’t jo net oefene hawwe, en dy helte is meastentiids wêr’t de ûntbrekkende rûte wennet.

Relatearre artikelen