Pishina VPN me dy shtresa: adresimi i të dyja familjeve në strongSwan

Pishinat e brendshme IPv4 dhe IPv6, prefikset e mbrojtura dhe familja e tunelit të jashtëm janë tri vendime të ndara. Planifikoni secilin përpara se ta quani dy shtresa.

Një portë mund t’i japë një përdoruesi në lëvizje një adresë virtuale IPv4 dhe një IPv6 njëkohësisht, ndërsa tuneli i jashtëm ende udhëton mbi IPv4. Këto janë vendime të pavarura, dhe trajtimi i tyre si një i vetëm është pika ku planet me dy shtresa zakonisht shpërbëhen. Familjet e brendshme të klientit, prefikset e mbrojtura që mund të arrijë dhe transporti që mbart inkapsulimin janë tri zgjedhje të ndara.

Shumica e konfuzionit vjen nga zbatimi i fjalës dy shtresa në një dizajn që është me dy shtresa vetëm në një vend. Një shërbim mund të jetë me dy shtresa nga brenda, me një shtresë në adresën e tij të jashtme, dhe prapë të funksionojë shumë mirë për klientët. Ajo që nuk mund të bëjë është të funksionojë rastësisht.

Dy familje brenda, një rrugë jashtë

Lidhja e jashtme është IKE mbi UDP, dhe i duhet një familje adresash e arritshme nga kudo që ndodhet klienti. Një adresë IPv6 e brendshme nuk kërkon një ofrues me IPv6, sepse paketa e brendshme është ngarkesa brenda asaj të jashtme. Shumë instalime që funksionojnë transportojnë prefikse IPv6 përmes një lidhjeje lart vetëm IPv4.

Ajo që rruga e jashtme vërtet kufizon është arritshmëria dhe kalimi përmes NAT. Nëse porta shpall vetëm një adresë IPv4, një klient në një rrjet vetëm IPv6 nuk mund të lidhet fare, sado pishina të keni konfiguruar. Vendosni familjen e jashtme sipas popullatës tuaj të klientëve, jo sipas planit të adresave të brendshme.

Jepini klientit një adresë në çdo familje

Kërkimi i të dyja familjeve është një rresht në anën e klientit, me kusht që porta të ketë çfarë të shpërndajë. Pishinat me emër i mbajnë burimet të ndara nga rrjetet e shërbimit, dhe kjo është vetia që i bën rregullat e firewall-it të lexueshme gjashtë muaj më vonë.

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

Vlera vips kërkon një adresë nga çdo familje, dhe lista e pishinave vendos nga vijnë ato adresa. Dokumentacioni i strongSwan për IP-të virtuale mbulon kërkesa të shumta dhe caktimin e pishinave, duke përfshirë pikën që një klient që kërkon një adresë të caktuar shpreh vetëm një preferencë që përgjigjësi mund ta anulojë. Mos ndërtoni një rregull hyrjeje që supozon se klienti merr gjithmonë të njëjtën vlerë.

Generoni prefiksin tuaj unik lokal në vend që të kopjoni shembullin. Dy organizata që të dyja fd42::/16 e zbatojnë do të zbulojnë përplasjen herën e parë që ndërlidhen, dhe diagnostikimi i saj nuk është i këndshëm.

Përzgjedhësit përshkruajnë destinacione, jo burime

Përzgjedhësit lokalë të trafikut të SA fëmijë thonë cilat rrjete të mbrojtura qëndrojnë pas portës, dhe përzgjedhësit e largët përshkruajnë çfarë klienti mund të përdorë si burim. Një adresë e pishinës virtuale i takon anës së burimit të asaj politike; vendosja e saj në listën e destinacioneve është një lexsim i gabuar i zakonshëm i konfigurimit.

Të dyja familjeve u duhen rrugë kthimi dhe përcjellje e lejuar në portë. Shtimi i një prefiksi te një përzgjedhës pa një rrugë kthimi te pishina krijon një tunel që vendoset, kalon një drejtim të trafikut dhe e hedh përgjigjen në heshtje. Përzgjedhësi është politikë, jo rrugëtim.

Mbani pishinat dhe prefikset e shërbimit në blloqe të ndara të planit tuaj të adresave. Kur mbivendosen, një rrugë që duhet të arrijë një host të mbrojtur mund të përputhet me një adresë pishine dhe të zhduket në tunel.

DNS-ja dhe rruga e përgjigjes vendosin nëse duket e përfunduar

Përgjigjet e zgjidhësit janë të pavarura nga transporti i përdorur për ta arritur atë. Një emër mund të kthejë një regjistrim A, një regjistrim AAAA ose të dyja, dhe klienti zgjedh sipas rregullave të tij të preferencës. Nëse një shërbim i brendshëm publikon një regjistrim AAAA por asgjë nuk e rrugëton atë prefiks, klientët në rrjetet me dy shtresa do të provojnë fillimisht rrugën IPv6 dhe do të qëndrojnë atje derisa ajo të dështojë. Asgjë në konfigurimin e tunelit nuk duket e gabuar ndërkohë që kjo ndodh.

Prandaj vendosni për çdo emër cilat familje duhet të jenë të përdorshme, pastaj verifikoni që prefiksi përkatës është në përzgjedhës dhe ka një rrugë kthimi. Ky është një vendim për çdo shërbim. Publikimi i të dy llojeve të regjistrimeve pa dallim është mënyra se si një shërbim që funksionon vetëm me IPv4 fillon të skadojë për gjysmën e përdoruesve të tij.

Verifikoni të dyja familjet përpara se ta quani të përfunduar

Një konfigurim që ngarkohet nuk është një konfigurim që funksionon. Lexoni gjendjen që raporton daemoni, konfirmoni caktimet e pishinave, pastaj shikoni rrugët që instaloi vërtet klienti.

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

Dy komandat e para tregojnë SA fëmijë të vendosura dhe cilat pishina kanë ende adresa të lira, kështu që një plan që funksionon për klientin e parë dhe dështon për të dhjetin bëhet i dukshëm. Dy të fundit tregojnë nëse klienti mori një adresë IPv6 globale nga pishina dhe ku do të shkonte vërtet trafiku drejt një prefiksi të mbrojtur. Krahasoni adresën e caktuar me pishinën që konfiguruat, jo me adresën që shpresuat. Nëse përgjigjësi zgjodhi një vlerë tjetër sipas politikës së tij, rrugët dhe rregullat e firewall-it duhet të përputhen gjithsesi me atë që ai zgjodhi.

Pastaj provoni një host të mbrojtur për çdo familje dhe një emër që zgjidhet në të dyja. Një provë me një familje nuk ju thotë asgjë për gjysmën e planit që nuk e keni ushtruar, dhe pikërisht aty zakonisht ndodhet rruga që mungon.

Artikuj të ngjashëm