Dual-stack VPN laugar: ávarpa báðar fjölskyldur í strongSwan

Gátt getur gefið faranda notanda bæði IPv4 og IPv6 sýndarfang, á meðan ytri göngin fer enn yfir IPv4. Þetta eru óháðar ákvarðanir, og að meðhöndla þær sem eina er einmitt þar sem dual-stack áætlanir hrynja yfirleitt. Innri fjölskyldur biðlarans, vernduðu forskeytin sem hann getur náð í, og flutningurinn sem ber hjúpunina eru þrjár aðskildar ákvarðanir.

Mest ruglið kemur af því að orðið dual-stack er notað um hönnun sem er dual-stack á einum stað eingöngu. Þjónusta getur verið dual-stack að innan, single-stack á ytra vistfangi sínu, og samt unnið fullkomlega fyrir biðlara. Það sem hún getur ekki gert er að vinna fyrir tilviljun.

Tvær fjölskyldur inni, ein leið úti

Ytri tengingin er IKE yfir UDP, og hún þarf eina aðgengilega vistfangafjölskyldu frá því stað sem biðlarinn er á. Innra IPv6 vistfang krefst ekki þjónustuaðila með IPv6, því innri pakkinn er farmur inni í þeim ytri. Margar virkar uppsetningar flytja IPv6 forskeyti í gegnum uppstreng sem er aðeins IPv4.

Það sem ytri leiðin takmarkar í raun er aðgengi og NAT yfirferð. Ef gáttin auglýsir aðeins IPv4 vistfang getur biðlari á neti sem er aðeins IPv6 alls ekki tengst, sama hvaða laugar þú stillir. Ákveddu ytri fjölskylduna út frá biðlarahópnum þínum, ekki innri vistfangaáætluninni.

Gefðu biðlaranum vistfang í hverri fjölskyldu

Að biðja um báðar fjölskyldurnar er ein lína hjá biðlaranum, að því gefnu að gáttin hafi eitthvað til að úthluta. Nefndar laugar halda upprunanum aðskildum frá þjónustunetunum, og það er eiginleikinn sem gerir eldveggjareglur læsilegar sex mánuðum síðar.

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

Gildið vips biður um vistfang úr hverri fjölskyldu, og laugalistinn ákveður hvaðan þessi vistföng koma. Skjöl strongSwan um sýndar IP-vistföng ná yfir margar beiðnir og úthlutun lauga, þar á meðal þá staðreynd að biðlari sem biður um tiltekið vistfang lýsir aðeins ósk sem svarandinn má hnekkja. Byggðu ekki aðgangsreglu sem gerir ráð fyrir að biðlarinn fái alltaf sama gildið.

Búðu til þitt eigið einstaka staðbundna forskeyti í stað þess að afrita dæmið. Tvær stofnanir sem báðar fd42::/16 taka það upp munu uppgötva áreksturinn í fyrsta skipti sem þær tengjast sín á milli, og að greina það er ekki ánægjulegt.

Veljarar lýsa áfangastöðum, ekki upprunum

Staðbundnir umferðarveljarar barns-SA segja hvaða vernduðu net liggja bak við gáttina, og fjarlægu veljararnir lýsa því sem biðlarinn má nota sem uppruna. Vistfang sýndarlauagrinnar tilheyrir upprunahlið þeirrar stefnu; að setja það í áfangastöðulistann er algengur mistúlkun á stillingunni.

Báðar fjölskyldurnar þurfa bakleiðir og leyfða framsendingu á gáttinni. Að bæta forskeyti við veljara án leiðar til baka í laugina býr til göng sem koma upp, hleypa einni umferðarstefnu í gegn og varpa svarinu hljóðlaust. Veljarinn er stefna, ekki leiðsögn.

Haltu laugunum og þjónustuforskeytunum í aðskildum blokkum í vistfangaáætluninni þinni. Þegar þau skarast getur leið sem á að ná til varins hýsis passað við vistfang laugar og horfið inn í göngin.

DNS og svarleiðin ákveða hvort þetta virkar fullbúið

Svör leysisins eru óháð flutningnum sem notaður er til að ná í leysinn. Nafn getur skilað A-færslu, AAAA-færslu eða báðum, og biðlarinn velur samkvæmt eigin forgangsreglum. Ef innri þjónusta birtir AAAA-færslu en ekkert beinir því forskeyti munu biðlarar á dual-stack netum prófa IPv6 leiðina fyrst og sitja þar þangað til hún mistekst. Ekkert í stillingu ganganna virðist rangt á meðan þetta gerist.

Ákveddu því fyrir hvert nafn hvaða fjölskyldur eigi að vera nothæfar, og athugaðu svo að viðeigandi forskeyti sé í veljaranum og hafi bakleið. Þetta er ákvörðun fyrir hverja þjónustu. Að birta báðar færslur ótæpilega er leiðin sem virk þjónusta með aðeins IPv4 fer að ná tímanum út hjá helmingi notenda sinna.

Staðfestu báðar fjölskyldurnar áður en þú segir þessu lokið

Stilling sem hleðst er ekki stilling sem virkar. Lestu stöðuna sem dæmoninn tilkynnir, staðfestu úthlutun lauganna og skoðaðu svo leiðirnar sem biðlarinn setti í raun upp.

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

Fyrstu tvær skipanirnar sýna uppsett barn-SA og hvaða laugar hafa enn laus vistföng, þannig að áætlun sem virkar fyrir fyrsta biðlarann og bregst hjá þeim tíunda verður sýnileg. Síðustu tvær sýna hvort biðlarinn fékk alheims IPv6 vistfang úr lauginni og hvert umferðin til varins forskeytis myndi í raun fara. Berðu úthlutaða vistfangið saman við laugina sem þú stilltir, ekki við vistfangið sem þú vonaðir eftir. Ef svarandinn valdi annað gildi samkvæmt stefnu sinni verða leiðirnar og eldveggjareglurnar samt að passa við val hans.

Prófaðu svo einn varinn hýsi fyrir hverja fjölskyldu, og prófaðu nafn sem leysist í báðar. Próf á einni fjölskyldu segir þér ekkert um þann helming áætlunarinnar sem þú hefur ekki æft, og þar er yfirleitt leiðin sem vantar.