Dual-stakaj VPN-putoj: adresi ambaŭ familiojn en strongSwan

Enirejo povas doni al migranta uzanto kaj IPv4 kaj IPv6 virtualan adreson, dum la ekstera tunelo ankoraŭ vojaĝas super IPv4. Tiuj estas sendependaj decidoj, kaj trakti ilin kiel unu estas la loko kie dual-stakaj planoj kutime disfalas. La internaj familioj de la kliento, la protektitaj prefiksoj kiujn ĝi povas atingi, kaj la transporto kiu portas la enkapsuligon estas tri apartaj elektoj.

Plej multo de la konfuzo venas de tio, ke la vorto dual-staka estas aplikata al dezajno kiu estas dual-staka nur en unu loko. Servo povas esti dual-staka interne, unu-staka sur sia ekstera adreso, kaj tamen perfekte bone funkcii por klientoj. Kion ĝi ne povas, estas funkcii hazarde.

Du familioj interne, unu vojo ekstere

La ekstera konekto estas IKE super UDP, kaj ĝi bezonas unu atingeblan adresfamilion de kie ajn la kliento troviĝas. Interna IPv6-adreso ne postulas provizanton kun IPv6, ĉar la interna paketo estas utilaĵo ene de la ekstera. Multaj funkciantaj enkondukoj portas IPv6-prefiksojn tra nur-IPv4-suprenligo.

Kion la ekstera vojo ja limigas, estas atingeblo kaj NAT-trapaso. Se la enirejo anoncas nur IPv4-adreson, kliento en nur-IPv6-reto tute ne povas konektiĝi, kiom ajn da putoj vi agordis. Decidu la eksteran familion laŭ via klientaro, ne laŭ la interna adresplano.

Donu al la kliento adreson en ĉiu familio

Peti ambaŭ familiojn estas unulinia eldiro ĉe la klienta flanko, kondiĉe ke la enirejo havas ion por disdoni. Nomitaj putoj tenas la fontojn aparte de la servaj retoj, kaj tio estas la eco kiu faras fajroŝirmilajn regulojn legeblaj ses monatojn poste.

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

La vips valoro petas adreson el ĉiu familio, kaj la puthistorio decidas de kie tiuj adresoj venas. La dokumentaro de strongSwan pri virtualaj IP-adresoj kovras plurajn petojn kaj putan asignadon, inkluzive la punkton ke kliento petanta specifan adreson esprimas nur preferon kiun la respondanto povas superregi. Ne konstruu alirregulon kiu supozas ke la kliento ĉiam ricevas la saman valoron.

Generu vian propran unikan lokan prefikson anstataŭ kopii la ekzemplan. Du organizaĵoj kiuj ambaŭ fd42::/16 enkondukos ĝin malkovros la kolizion la unuan fojon kiam ili interkonektiĝos, kaj diagnozi tion ne estas agrable.

Selektiloj priskribas celojn, ne fontojn

La lokaj trafikselektiloj de la ida SA diras kiuj protektitaj retoj staras malantaŭ la enirejo, kaj la malproksimaj selektiloj priskribas kion la kliento rajtas uzi kiel fonton. Virtuala puta adreso apartenas al la fonta flanko de tiu politiko; meti ĝin en la celliston estas ofta mislego de la agordo.

Ambaŭ familioj bezonas revenajn vojojn kaj permesitan plusendadon sur la enirejo. Aldoni prefikson al selektilo sen vojo reen al la puto produktas tunelon kiu ekstaras, trapasas unu direkton de trafiko kaj silente faligas la respondon. La selektilo estas politiko, ne enkursigado.

Tenu la putojn kaj la servajn prefiksojn en apartaj blokoj de via adresplano. Kiam ili interkovras, vojo kiu devus atingi protektitan gastiganton povas kongrui kun puta adreso kaj malaperi en la tunelon.

DNS kaj la responda vojo decidas ĉu ĝi sentiĝas finita

Respondoj de la solvilo estas sendependaj de la transporto uzata por atingi la solvilon. Nomo povas redoni A-rikordon, AAAA-rikordon aŭ ambaŭ, kaj la kliento elektas laŭ siaj propraj preferreguloj . Se interna servo publikigas AAAA-rikordon sed nenio enkursigas tiun prefikson, klientoj en dual-stakaj retoj provos la IPv6-vojon unue kaj restos tie ĝis ĝi malsukcesos. Nenio en la tunela agordo aspektas malĝusta dum tio okazas.

Do decidu por ĉiu nomo kiuj familioj estu uzeblaj, poste kontrolu ke la responda prefikso estas en la selektilo kaj havas revenan vojon. Tio estas decido por ĉiu servo aparte. Senbrida publikigado de ambaŭ rikordtipoj estas kiel funkcianta nur-IPv4-servo komencas tempoliberi por duono de siaj uzantoj.

Kontrolu ambaŭ familiojn antaŭ ol nomi ĝin preta

Agordo kiu ŝargiĝas ne estas agordo kiu funkcias. Legu la staton kiun la demono raportas, konfirmu la putajn asignojn, poste rigardu la vojojn kiujn la kliento efektive instaligis.

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

La unuaj du komandoj montras la starigitajn idajn SA-ojn kaj kiuj putoj ankoraŭ havas disponeblajn adresojn, tiel ke plano kiu funkcias por la unua kliento kaj malsukcesas por la deka fariĝas videbla. La lastaj du montras ĉu la kliento ricevis tutmondan IPv6-adreson el la puto kaj kien trafiko al protektita prefikso efektive irus. Komparu la asignitan adreson kun la puto kiun vi agordis, ne kun la adreso kiun vi esperis. Se la respondanto elektis alian valoron laŭ sia politiko, la vojoj kaj fajroŝirmilaj reguloj ankoraŭ devas kongrui kun ĝia elekto.

Poste testu unu protektitan gastiganton por ĉiu familio, kaj testu nomon kiu solviĝas al ambaŭ. Testo de unu familio diras al vi nenion pri la duono de la plano kiun vi ne ekzercis, kaj tiu duono estas kutime kie loĝas la mankanta vojo.