Dual-stack VPN pooly: adresování obou rodin v strongSwan

Vnitřní pooly IPv4 a IPv6, chráněné prefixy a rodina vnějšího tunelu jsou tři samostatná rozhodnutí. Naplánujte každé z nich, než to nazvete dual-stack.

Brána může dát cestujícímu uživateli virtuální adresu IPv4 i IPv6, zatímco vnější tunel stále putuje přes IPv4. To jsou nezávislá rozhodnutí a právě jejich sloučení do jednoho je místo, kde se dual-stack plány obvykle rozpadají. Vnitřní rodiny klienta, chráněné prefixy, na které se může dostat, a transport, který nese zapouzdření, jsou tři samostatné volby.

Většina zmatení pochází z toho, že se slovo dual-stack použije na návrh, který je dual-stack jen na jednom místě. Služba může být dual-stack uvnitř, single-stack na své vnější adrese, a přesto klientům fungovat naprosto dobře. Co nedokáže, je fungovat náhodou.

Dvě rodiny uvnitř, jedna cesta ven

Vnější spojení je IKE přes UDP a potřebuje jednu dostupnou rodinu adres odkudkoli, kde se klient nachází. Vnitřní adresa IPv6 nevyžaduje poskytovatele s podporou IPv6, protože vnitřní paket je užitečné zatížení uvnitř vnějšího. Mnoho funkčních nasazení přenáší prefixy IPv6 přes uplink, který podporuje jen IPv4.

Co vnější cesta omezuje, je dostupnost a průchod přes NAT. Pokud brána inzeruje pouze adresu IPv4, klient v síti pouze s IPv6 se nemůže připojit vůbec, bez ohledu na to, jaké pooly nakonfigurujete. Rodinu vnější cesty vybírejte podle své klientské populace, ne podle vnitřního plánu adres.

Dejte klientovi adresu v každé rodině

Požadavek na obě rodiny je jednořádkový příkaz na straně klienta, pokud má brána co přidělit. Pojmenované pooly drží zdroje oddělené od servisních sítí, a to je vlastnost, která dělá pravidla firewallu čitelná i po šesti měsících.

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

Hodnota vips si vyžádá adresu z každé rodiny a seznam poolů rozhoduje, odkud tyto adresy pocházejí. Dokumentace strongSwan k virtuálním IP adresám pokrývá více požadavků a přidělování z poolů, včetně toho, že klient žádající konkrétní adresu vyjadřuje jen preferenci, kterou responder může přebít. Nestavte přístupové pravidlo, které předpokládá, že klient vždy dostane stejnou hodnotu.

Vygenerujte si vlastní jedinečný lokální prefix místo kopírování příkladu. Dvě organizace, které obě fd42::/16 nasadí, objeví kolizi při prvním vzájemném propojení a diagnostikovat to není příjemné.

Selektory popisují cíle, ne zdroje

Lokální selektory provozu podřízené SA říkají, které chráněné sítě stojí za bránou, a vzdálené selektory popisují, co klient smí použít jako zdroj. Adresa virtuálního poolu patří na zdrojovou stranu této politiky; její zařazení do seznamu cílů je časté chybné čtení konfigurace.

Obě rodiny potřebují zpětné trasy a povolené forwarding na bráně. Přidání prefixu do selektoru bez trasy zpět do poolu vytvoří tunel, který se naváže, propustí jeden směr provozu a tiše zahodí odpověď. Selektor je politika, ne směrování.

Držte pooly a servisní prefixy v oddělených blocích svého adresního plánu. Když se překryjí, trasa, která má dosáhnout chráněného hostitele, může odpovídat adrese poolu a zmizet v tunelu.

DNS a cesta odpovědi rozhodují, zda to vypadá hotové

Odpovědi resolveru jsou nezávislé na transportu použitém k dosažení resolveru. Jméno může vrátit záznam A, záznam AAAA nebo oba a klient vybírá podle svých vlastních pravidel preference . Pokud interní služba publikuje záznam AAAA, ale ten prefix nikdo nesměruje, klienti v dual-stack sítích zkusí nejprve cestu IPv6 a zůstanou tam, dokud to neselže. V konfiguraci tunelu přitom nic nevypadá špatně.

Rozhodněte tedy pro každé jméno, které rodiny mají být použitelné, a pak ověřte, že odpovídající prefix je v selektoru a má zpětnou trasu. To je rozhodnutí pro každou službu zvlášť. Plošné publikování obou typů záznamů je způsob, jak funkční služba pouze s IPv4 začne polovině uživatelů vypršovat časový limit.

Ověřte obě rodiny, než to prohlásíte za hotové

Konfigurace, která se načte, není konfigurace, která funguje. Přečtěte si stav, který démon hlásí, potvrďte přidělení z poolů a pak se podívejte na trasy, které klient skutečně nainstaloval.

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

První dva příkazy ukazují navázané podřízené SA a které pooly ještě mají volné adresy, takže plán, který funguje pro prvního klienta a selže u desátého, se stane viditelným. Poslední dva ukazují, zda klient dostal globální adresu IPv6 z poolu a kam by provoz k chráněnému prefixu ve skutečnosti šel. Porovnejte přidělenou adresu s poolem, který jste nakonfigurovali, ne s adresou, v kterou jste doufali. Pokud responder podle své politiky zvolil jinou hodnotu, trasy a pravidla firewallu musí stále odpovídat jeho volbě.

Potom otestujte jednoho chráněného hostitele pro každou rodinu a jméno, které se překládá do obou. Test jedné rodiny vám neřekne nic o polovině plánu, kterou jste neprocvičili, a právě v ní obvykle sídlí chybějící trasa.

Související články