Kettős verem VPN-készletek: mindkét címcsalád kezelése a strongSwanban

A belső IPv4- és IPv6-készletek, a védett előtagok és a külső alagút családja három külön döntés. Tervezze meg mindegyiket, mielőtt kettős veremnek nevezné.

Egy átjáró adhat egy utazó felhasználónak IPv4 és IPv6 virtuális címet is, miközben a külső alagút továbbra is IPv4 fölött halad. Ezek független döntések, és éppen az, hogy egyként kezeljük őket, az a pont, ahol a kettős verem tervei általában szétesnek. Az ügyfél belső családjai, a védett előtagok, amelyeket elérhet, és a burkolást hordozó átvitel három külön választás.

A legtöbb zavar abból ered, hogy a kettős verem szót olyan kialakításra alkalmazzák, amely csak egy helyen kettős verem. Egy szolgáltatás belül kettős verem lehet, a külső címén egyetlen verem, és mégis tökéletesen működhet az ügyfelek számára. Amit nem tud, az a véletlen működés.

Két család belül, egy útvonal kívül

A külső kapcsolat IKE UDP fölött, és egy elérhető címcsaládra van szüksége onnan, ahol az ügyfél éppen van. A belső IPv6-cím nem igényel IPv6-képes szolgáltatót, mert a belső csomag a külső csomagon belüli hasznos teher. Sok működő telepítés IPv6-előtagokat csak IPv4-es felső kapcsolaton keresztül szállít.

Amit a külső útvonal valóban korlátoz, az az elérhetőség és a NAT-átjárás. Ha az átjáró csak IPv4-címet hirdet, a csak IPv6-os hálózaton lévő ügyfél egyáltalán nem tud csatlakozni, akármilyen készleteket állított be. A külső családot az ügyfélkör alapján döntse el, nem a belső címterv alapján.

Adjon az ügyfélnek címet minden családban

Mindkét család kérése egyetlen sor az ügyfél oldalán, feltéve hogy az átjárónak van mit kiosztania. A nevesített készletek külön tartják a forrásokat a szolgáltatáshálózatoktól, és ez az a tulajdonság, amely fél évvel később is olvashatóvá teszi a tűzfal-szabályokat.

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

A vips érték minden családból egy címet kér, és a készletlista dönti el, honnan származnak ezek a címek. A strongSwan virtuális IP-címekről szóló dokumentációja több kérést és a készletkiosztást is tárgyalja, beleértve azt a pontot, hogy a konkrét címet kérő ügyfél csak egy preferenciát fejez ki, amelyet a válaszadó felülbírálhat. Ne építsen olyan hozzáférési szabályt, amely feltételezi, hogy az ügyfél mindig ugyanazt az értéket kapja.

Hozzon létre saját egyedi helyi előtagot ahelyett, hogy a példát másolná. Két szervezet, amely mindkettő fd42::/16 bevezeti, az első összekapcsolódáskor felfedezi az ütközést, és ennek diagnosztizálása nem kellemes.

A szelektorok célokat írnak le, nem forrásokat

A gyermek-SA helyi forgalomszelektorai megmondják, mely védett hálózatok vannak az átjáró mögött, a távoli szelektorok pedig leírják, mit használhat az ügyfél forrásként. Egy virtuális készletcím ehhez a házirendhez tartozó forrásoldalon van; a célok listájába tenni a konfiguráció gyakori félreértelmezése.

Mindkét családnak visszatérő útvonalakra és engedélyezett továbbításra van szüksége az átjárón. Ha egy előtagot úgy adunk egy szelektorhoz, hogy nincs útvonal vissza a készletbe, olyan alagút jön létre, amely felépül, egy irányban átengedi a forgalmat, és csendben eldobja a választ. A szelektor házirend, nem útvonalválasztás.

Tartsa a készleteket és a szolgáltatási előtagokat a címtérv külön blokkjaiban. Ha átfedik egymást, egy védett gazdagépet elérni hivatott útvonal illeszkedhet egy készletcímre, és eltűnhet az alagútban.

A DNS és a válaszútvonal dönti el, hogy késznek tűnik-e

A feloldó válaszai függetlenek attól az átviteltől, amellyel a feloldót elérjük. Egy név visszaadhat A-rekordot, AAAA-rekordot vagy mindkettőt, és az ügyfél a saját preferenciaszabályai szerint választ. Ha egy belső szolgáltatás AAAA-rekordot tesz közzé, de semmi nem irányítja azt az előtagot, a kettős verem hálózatain lévő ügyfelek először az IPv6-útvonalat próbálják, és ott maradnak, amíg az meg nem hibásodik. Eközben semmi sem tűnik hibásnak az alagút konfigurációjában.

Határozza meg tehát névenként, mely családok legyenek használhatók, majd ellenőrizze, hogy a megfelelő előtag szerepel-e a szelektorban, és van-e visszatérő útvonala. Ez szolgáltatásonkénti döntés. Mindkét rekordtípus válogatás nélküli közzététele az, ahogy egy működő csak IPv4-es szolgáltatás elkezd időtúllépni a felhasználói felénél.

Ellenőrizze mindkét családot, mielőtt késznek nyilvánítja

A betöltődő konfiguráció nem működő konfiguráció. Olvassa el a démon által jelentett állapotot, erősítse meg a készletkiosztásokat, majd nézze meg, milyen útvonalakat telepített az ügyfél valójában.

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

Az első két parancs a felépült gyermek-SA-okat és azt mutatja, mely készletekben van még szabad cím, így láthatóvá válik az a terv, amely az első ügyfélnél működik, a tizediknél pedig elbukik. Az utolsó kettő azt mutatja, kapott-e az ügyfél globális IPv6-címet a készletből, és hová menne valójában a forgalom egy védett előtag felé. Hasonlítsa össze a kiosztott címet azzal a készlettel, amelyet beállított, nem azzal a címmel, amelyet remélt. Ha a válaszadó a házirendje szerint más értéket választott, az útvonalaknak és a tűzfalszabályoknak akkor is ehhez kell illeszkedniük.

Ezután teszteljen egy védett gazdagépet családonként, és egy nevet, amely mindkettőre feloldódik. Az egycsaládos teszt semmit sem mond a terv azon feléről, amelyet nem gyakorolt, és a hiányzó útvonal általában ott lakik.

Kapcsolódó cikkek