Pool-uri VPN dual-stack: adresarea ambelor familii în strongSwan

Pool-urile IPv4 și IPv6 interne, prefixele protejate și familia tunelului exterior sunt trei decizii separate. Planificați fiecare înainte de a-i spune dual stack.

O poartă poate oferi unui utilizator mobil atât o adresă virtuală IPv4, cât și una IPv6, în timp ce tunelul exterior merge încă peste IPv4. Acestea sunt decizii independente, iar tratarea lor ca una singură este locul unde planurile dual-stack se destramă de obicei. Familiile interne ale clientului, prefixele protejate pe care le poate atinge și transportul care poartă încapsularea sunt trei alegeri separate.

Cea mai mare parte a confuziei vine din aplicarea cuvântului dual stack la un design care este dual stack într-un singur loc. Un serviciu poate fi dual stack în interior, single stack pe adresa sa exterioară și totuși să funcționeze perfect pentru clienți. Ce nu poate face este să funcționeze din întâmplare.

Două familii înăuntru, o singură cale afară

Conexiunea exterioară este IKE peste UDP și are nevoie de o familie de adrese accesibilă de oriunde s-ar afla clientul. O adresă IPv6 internă nu necesită un furnizor cu IPv6, deoarece pachetul intern este încărcătura din interiorul celui extern. Multe implementări funcționale transportă prefixe IPv6 printr-o legătură ascendentă doar IPv4.

Ceea ce calea exterioară limitează cu adevărat este accesibilitatea și traversarea NAT. Dacă poarta anunță doar o adresă IPv4, un client într-o rețea doar IPv6 nu se poate conecta deloc, indiferent ce pool-uri ați configurat. Decideți familia exterioară după populația de clienți, nu după planul de adrese intern.

Dați clientului o adresă în fiecare familie

Cererea ambelor familii este o singură linie la client, cu condiția ca poarta să aibă ce distribui. Pool-urile cu nume țin sursele separate de rețelele de serviciu, iar această proprietate face regulile de firewall lizibile șase luni mai târziu.

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

Valoarea vips cere o adresă din fiecare familie, iar lista de pool-uri decide de unde vin acele adrese. Documentația strongSwan despre IP-uri virtuale acoperă mai multe cereri și alocarea pool-urilor, inclusiv faptul că un client care cere o adresă anume exprimă doar o preferință pe care respondența o poate anula. Nu construiți o regulă de acces care presupune că clientul primește mereu aceeași valoare.

Generați propriul prefix local unic în loc să copiați exemplul. Două organizații care ambele fd42::/16 îl implementează vor descoperi coliziunea la prima interconectare, iar diagnosticarea ei nu este plăcută.

Selectorii descriu destinații, nu surse

Selectorii de trafic locali ai SA copil spun ce rețele protejate se află în spatele porții, iar selectorii la distanță descriu ce poate clientul să folosească drept sursă. O adresă de pool virtual aparține laturii sursă a acelei politici; plasarea ei în lista de destinații este o citire greșită obișnuită a configurației.

Ambele familii au nevoie de rute de retur și de redirecționare permisă pe poartă. Adăugarea unui prefix la un selector fără o rută înapoi la pool produce un tunel care se stabilește, trece o singură direcție a traficului și aruncă răspunsul în tăcere. Selectorul este politică, nu rutare.

Țineți pool-urile și prefixele de serviciu în blocuri separate ale planului de adrese. Când se suprapun, o rută care ar trebui să ajungă la un host protejat poate coincide cu o adresă de pool și poate dispărea în tunel.

DNS-ul și calea răspunsului decid dacă pare terminat

Răspunsurile resolverului sunt independente de transportul folosit pentru a-l atinge. Un nume poate returna o înregistrare A, o înregistrare AAAA sau ambele, iar clientul alege după propriile reguli de preferință. Dacă un serviciu intern publică o înregistrare AAAA, dar nimic nu rutează acel prefix, clienții din rețelele dual-stack vor încerca mai întâi calea IPv6 și vor rămâne acolo până când eșuează. Nimic din configurația tunelului nu pare greșit în timp ce se întâmplă asta.

Așadar decideți pentru fiecare nume ce familii ar trebui să fie utilizabile, apoi verificați că prefixul corespunzător este în selector și are o rută de retur. Este o decizie pentru fiecare serviciu. Publicarea ambelor tipuri de înregistrări fără discernământ este modul în care un serviciu funcțional doar pe IPv4 începe să dea timeout pentru jumătate dintre utilizatorii săi.

Verificați ambele familii înainte de a-l declara terminat

O configurație care se încarcă nu este o configurație care funcționează. Citiți starea raportată de demon, confirmați alocările de pool-uri, apoi uitați-vă la rutele pe care clientul le-a instalat efectiv.

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

Primele două comenzi arată SA copil stabilite și care pool-uri mai au adrese disponibile, astfel încât un plan care funcționează pentru primul client și eșuează pentru al zecelea devine vizibil. Ultimele două arată dacă clientul a primit o adresă IPv6 globală din pool și unde ar merge de fapt traficul către un prefix protejat. Comparați adresa alocată cu pool-ul pe care l-ați configurat, nu cu adresa la care sperați. Dacă respondența a ales o altă valoare conform politicii sale, rutele și regulile de firewall trebuie totuși să corespundă alegerii ei.

Apoi testați un host protejat pentru fiecare familie și un nume care se rezolvă la ambele. Un test cu o singură familie nu vă spune nimic despre jumătatea de plan pe care nu ați exersat-o, iar acea jumătate este de obicei locul unde se află ruta lipsă.

Articole similare