WireGuard-profil egy IPsec-átjáróhoz: mit kérdezzünk helyette

Egy csendes átjáróval szembeni kézfogási időtúllépések általában két protokollt jelentenek, amelyek soha nem találkoznak. A WireGuard-társ Noise-t beszél, míg az IPsec-átjáró IKE-re vár. A helyes cím és port ezen nem változtat.

A végpont újrafelhasználása egy profilban nem hidalja át a kettőt. A következő lépés egy kérés ahhoz, aki az átjárót üzemelteti.

Első kérés: a protokoll verziója

Az IPsec egy családot jelöl, nem egyetlen munkafolyamatot. Az IKEv2 és az IKEv1 különbözik a cseréiben, a hitelesítési lehetőségeiben és a hálózatváltás során tanúsított viselkedésében. Egy átjáró, amely csak IKEv1-et zár le, egészen másként viselkedik, mint amely IKEv2-t kínál. A kliens konfigurációja ezzel együtt változik.

Kérdezze meg, melyik verziót zárja le a szolgáltatás, és hogy szabványalapú megvalósítást vagy saját klienssel rendelkező szállítói változatot futtat-e. Az operációs rendszerek menüi gyakran egyetlen címke mögé rejtik ezt a választ. A címke nem a protokoll.

Második kérés: a kliens hitelesítési módja

A hitelesítés az a hely, ahol a valódi munka nagy része van. A szolgáltatás elvárhat egy adott kiterjesztett kulcshasználatú gépi tanúsítványt, felhasználói tanúsítványt, IKEv2 feletti EAP-módszert vagy egy identitáshoz kötött előre megosztott kulcsot. Hogy melyik érvényes, eldönti, mire van szüksége a kliensnek.

A WireGuard privát kulcsa egyik sem ezek közül. Ez egy Curve25519 kulcs, amelyet egyetlen meghatározott kézfogásban használnak. Semmilyen átalakítás nem teszi tanúsítvánnyá vagy EAP-hitelesítő adattá. Egy olyan eszköz, amely mást állít, átnevezi a fájlt vagy valami nem kapcsolódót állít elő.

Az IKEv2 specifikációja az RFC 7296-ban leírja, mit kell támogatnia az adott verzió megvalósításának. Ez egy homályos üzemeltetői válasz referenciája, nem klienskonfigurációs útmutató.

Harmadik kérés: a megbízható identitás és a célok

Kérje az átjáró identitását úgy, ahogy a kliensnek látnia kell, valamint az azt érvényesítő bizalmi horgonyt. Ezután kérdezze meg, milyen privát tartományokat és feloldókat küld a szolgáltatás. Ez a két válasz dönti el, mit szállít valójában az alagút.

Ezek nélkül egy működő kapcsolat is elbukhat a feladatban. A küldött feloldó nélkül felálló alagút válasz nélkül hagyja a belső neveket. A hiányzó forgalomválasztó az alagúton kívül hagyja a célt, pedig a kézfogás sikerült.

A végpont vizsgálata más kérdésre válaszol, mint a kliens hibája. Egy elérhető port társítás nélkül a hitelesítésre utal, míg egy elérhetetlen port az útvonalra.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Futtassa ezt a vizsgálatot, mielőtt bármit módosít a kliensben. Ha a portok válaszolnak és a társítás továbbra is meghiúsul, a probléma a hitelesítő adatokban vagy a szabályzatban van. Ha egyáltalán nem válaszolnak, semmilyen profilmódosítás nem segít.

Amikor mindkét protokollnak együtt kell léteznie

Mindkét hálózat igazgatása jogos ok mindkét protokoll megtartására. A szokásos kialakítás külön interfészeken vagy külön átjárókon zárja le a WireGuardot és az IPsecet. A jóváhagyott forgalom ezután közöttük kerül továbbításra.

Ez a kialakítás bizalmi és engedélyezési határt vezet be, és ezt így kell rögzíteni. Mely társak léphetnek át, milyen irányban és kinek a szabályzata alatt, az útválasztási és tűzfal-döntés. Egyik protokoll sem nyújtja ezt.

Ami ez nem, az az átlátható átalakítás. A WireGuardon érkező forgalom újra létrejön az IPsec-alagútban, és minden köztes szabályzat vonatkozik rá.

Először tisztázza a szerver protokoll- és hitelesítési követelményeit. Ezután használja azt a klienst és regisztrációs útvonalat, amelyet az üzemeltető támogat, és tartsa távol a privát kulcsokat a webes átalakítóktól, miközben ez történik.