Divkāršas kaudzes VPN kopas: abu adrešu saimju adresēšana strongSwan

Iekšējās IPv4 un IPv6 kopas, aizsargātie prefiksi un ārējā tuneļa saime ir trīs atsevišķi lēmumi. Izplānojiet katru, pirms to saukt par divkāršu kaudzi.

Vārteja var piešķirt ceļojošam lietotājam gan IPv4, gan IPv6 virtuālo adresi, kamēr ārējais tunelis joprojām iet pāri IPv4. Tie ir neatkarīgi lēmumi, un tieši to uztveršana kā vienu ir vieta, kur divkāršas kaudzes plāni parasti sabrūk. Klienta iekšējās saimes, aizsargātie prefiksi, kurus tas var sasniegt, un transports, kas nes iekapsulējumu, ir trīs atsevišķas izvēles.

Lielākā daļa apjukumu rodas tāpēc, ka vārds divkārša kaudze tiek attiecināts uz dizainu, kas ir divkārša kaudze tikai vienā vietā. Pakalpojums var būt divkāršas kaudzes iekšienē, vienas kaudzes savā ārējā adresē un tomēr lieliski darboties klientiem. Ko tas nevar, ir darboties nejauši.

Divas saimes iekšā, viens ceļš ārā

Ārējais savienojums ir IKE pāri UDP, un tam vajadzīga viena sasniedzama adrešu saime no vietas, kur klients atrodas. Iekšējā IPv6 adrese neprasa pakalpojumu sniedzēju ar IPv6, jo iekšējā pakete ir lietderīgā slodze ārējās iekšienē. Daudzas strādājošas ieviešanas pārvieto IPv6 prefiksus pa tikai IPv4 augšupceļu.

Tas, ko ārējais ceļš patiešām ierobežo, ir sasniedzamība un NAT šķērsošana. Ja vārteja reklamē tikai IPv4 adresi, klients tīklā, kurā ir tikai IPv6, nevar pievienoties vispār, neatkarīgi no tā, kādas kopas esat konfigurējis. Ārējo saimi izvēlieties pēc savas klientu populācijas, nevis pēc iekšējā adrešu plāna.

Dodiet klientam adresi katrā saimē

Abu saimju pieprasījums klienta pusē ir viena rinda, ar nosacījumu, ka vārtejai ir ko sadalīt. Nosauktās kopas tur avotus atsevišķi no pakalpojumu tīkliem, un tieši šī īpašība padara ugunsmūra noteikumus lasāmus arī pēc sešiem mēnešiem.

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

Vērtība vips pieprasa adresi no katras saimes, un kopu saraksts nosaka, no kurienes šīs adreses nāk. Dokumentācija strongSwan par virtuālajām IP adresēm aptver vairākus pieprasījumus un kopu piešķiršanu, tostarp to, ka klients, kas pieprasa konkrētu adresi, izsaka tikai priekšroku, ko atbildētājs var atcelt. Neveidojiet piekļuves noteikumu, kas pieņem, ka klients vienmēr saņem to pašu vērtību.

Ģenerējiet savu unikālo lokālo prefiksu, nevis kopējiet piemēru. Divas organizācijas, kas abas fd42::/16 to ievieš, atklās sadursmi pirmajā savstarpējā savienojumā, un to diagnosticēt nav patīkami.

Selektori apraksta galamērķus, nevis avotus

Bērna SA lokālie trafika selektori norāda, kuri aizsargātie tīkli atrodas aiz vārtejas, un attālinātie selektori apraksta, ko klients drīkst izmantot kā avotu. Virtuālās kopas adrese pieder šīs politikas avota pusei; tās ievietošana galamērķu sarakstā ir izplatīta nepareiza konfigurācijas lasīšana.

Abām saimēm vajadzīgi atgriešanās maršruti un atļauta pāradresācija vārtejā. Prefiksa pievienošana selektoram bez maršruta atpakaļ uz kopu rada tuneli, kas izveidojas, izlaiž vienu trafika virzienu un klusi izmet atbildi. Seleektors ir politika, nevis maršrutēšana.

Turiet kopas un pakalpojumu prefiksus atsevišķos sava adrešu plāna blokos. Kad tie pārklājas, maršruts, kam būtu jāsasniedz aizsargāts resursdators, var sakrist ar kopas adresi un pazust tunelī.

DNS un atbildes ceļš nosaka, vai tas šķiet pabeigts

Atrisinātāja atbildes nav atkarīgas no transporta, kas tiek izmantots, lai to sasniegtu. Nosaukums var atgriezt A ierakstu, AAAA ierakstu vai abus, un klients izvēlas pēc saviem priekšroku noteikumiem. Ja iekšējais pakalpojums publicē AAAA ierakstu, bet nekas nemaršrutē šo prefiksu, klienti divkāršas kaudzes tīklos vispirms mēģinās IPv6 ceļu un paliks tur, līdz tas neizdosies. Tikmēr tuneļa konfigurācijā nekas neizskatās nepareizi.

Tāpēc izlemiet katram nosaukumam, kuras saimes ir jābūt izmantojamām, pēc tam pārbaudiet, vai attiecīgais prefikss ir selektorā un tam ir atgriešanās maršruts. Tas ir lēmums katram pakalpojumam atsevišķi. Abu ierakstu tipu publicēšana bez izšķirības ir veids, kā strādājošs tikai IPv4 pakalpojums sāk izsmelt laiku pusei savu lietotāju.

Pārbaudiet abas saimes, pirms to nosaukt par gatavu

Konfigurācija, kas ielādējas, nav konfigurācija, kas darbojas. Izlasiet stāvokli, ko ziņo dēmons, apstipriniet kopu piešķīrumus, pēc tam apskatiet maršrutus, ko klients faktiski instalēja.

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

Pirmās divas komandas parāda izveidotās bērna SA un to, kurās kopās vēl ir brīvas adreses, tāpēc plāns, kas strādā pirmajam klientam un neizdodas desmitajam, kļūst redzams. Pēdējās divas parāda, vai klients saņēma globālu IPv6 adresi no kopas un kur trafiks uz aizsargātu prefiksu patiešām dotos. Salīdziniet piešķirto adresi ar kopu, kuru konfigurējāt, nevis ar adresi, uz kuru cerējāt. Ja atbildētājs saskaņā ar savu politiku izvēlējās citu vērtību, maršrutiem un ugunsmūra noteikumiem joprojām jāatbilst viņa izvēlei.

Pēc tam pārbaudiet vienu aizsargātu resursdatoru katrai saimei un nosaukumu, kas atrisinās abās. Vienas saimes tests neko nepasaka par to plāna pusi, kuru neesat trenējis, un tieši tur parasti atrodas trūkstošais maršruts.

Saistītie raksti