IPsec IPsecben: milyen címeket kell a külső alagútnak vinnie

A beágyazott IPsec könnyebben átgondolható, ha a két réteg különböző gépeken végződik. Négy átjáró, két alagút és egyetlen kérdés, amely eldönti, működik-e a terv: mit lát valójában a külső alagút, amikor a belső végzett a csomaggal? Válaszoljon erre, és a szelektorok, az útvonalak és a hibaelhárítási sorrend következnek. Ha elvéti, egy napot tölt egy technikailag élő alagút hibakeresésével.

A négy átjárós modell

A külső A és B átjáró építi az első alagutat a két telephely között. A mögött a belső C átjáró áll, átmeneti címe 10.60.0.2; B mögött a belső D átjáró áll, átmeneti címe 10.70.0.2. Az alkalmazáshálózatok C és D mögött élnek, és a példában minden cím szándékosan nem fedi egymást.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

A rétegek négy hosztra osztása azt jelenti, hogy minden gép egy határt kényszerít ki. Egyetlen hoszt, amely mindkét réteget futtatja, két házirend-készletet, két útválasztási táblát és két hibaállapotot kénytelen egy gépen összeegyeztetni, ami lehetséges és sokkal nehezebben figyelhető meg.

Minden réteg csak a saját védelmét távolítja el

A C titkosít egy alkalmazáscsomagot a D számára. Az eredmény C-től D felé címzett, és ez érkezik meg az A-hoz. Minden további a felülíráson múlik.

Az A újra titkosítja a B számára. A B visszafejti a külső réteget, lát egy C-től D felé tartó csomagot, és továbbítja még mindig titkosítva. A D eltávolítja a belső védelmet, és kézbesíti az alkalmazáscsomagot.

Így az A és a B látja a belső végpontokat és metaadataikat, de nem ők azok, akik az alkalmazás hasznos terhét visszafejtik. Ez a terv valódi tulajdonsága, nem annak állítása, hogy a C, a D vagy az alkalmazáshosztok megbízhatók.

A külső szelektorok a belső átjárókat nevezik meg

Itt bukik el a legtöbb ilyen építmény. Házirend-alapú külső alagútnál a tárgyalt szelektoroknak azokat a címeket kell tartalmazniuk, amelyeket az A és a B valóban kezel: 10.60.0.2/32 és 10.70.0.2/32, a helyes helyi és távoli sorrendben.

A végleges alkalmazás-alhálózatok külső szelektorokba tétele nem működik, mert mire egy csomag eléri az A-t, a belső beágyazás már felülírta azt, amit az A-nak védenie kell. A külső házirend ekkor semmire sem illeszkedne, és az alagút adatok nélkül jönne fel.

Ne szűkítse a külső engedélyt UDP 500-ra sem. A belső kapcsolatnak saját adatútja van, amely a tárgyaltaktól függően ESP-t vagy UDP-beágyazást használ, és a külső házirendnek engedélyeznie kell ezt a protokollt.

Ellenőrizze az eredményt swanctl --list-sas segítségével minden átjárón, és erősítse meg, hogy a gyermek biztonsági társulások a szándékolt címeket jelentik, nem azokat, amelyeket feltételezett. Ha a lista az alkalmazás-alhálózatokat mutatja, a külső házirend a rossz réteghez készült. Javítsa a szelektorokat, mielőtt az útválasztást hibakeresi, mert az útválasztás rendben lévőnek tűnik, a számlálók pedig nem mozdulnak.

Továbbítás és a rekurzió csapdája

A szelektorok nem helyettesítik az útválasztást. Az A-nak és a B-nek mindkét irányban továbbítania kell a forgalmat a C és a D között, ami engedélyezett IP-továbbítást, az alagútra mutató útvonalakat és a túloldalon létező visszaútvonalat jelent.

Ha a külső alagút XFRM-interfészeket használ, az útvonalak az interfészt választják, miközben a tárgyalt házirendek továbbra is korlátozzák, mit szállít. Az interfész nem szélesíti a védett területet; csak azt változtatja meg, hogyan veszi fel a kernel a csomagot.

A csapda a rekurzió. Az A útvonalának a B külső végpontjához az alapréteget kell követnie, nem az A által épített alagutat, különben a beágyazás önmagában próbál utazni, és a kapcsolat soha nem jön létre.

Vizsgálja meg a fordítást, mielőtt rétegeket ad hozzá

Nézzen meg minden forrás-NAT-ot az A-n és a B-n, mielőtt bármi mást hangolna. Egy szabály, amely a C címét az IPsec-házirend alkalmazása előtt átírja, megtörheti a megállapodott szelektorokat, és megváltoztathatja azt is, amit a D a túloldalon kap.

A széles maszkolás nem lesz biztonságosabb két rétegtől. Elrejti, melyik címet látja a távoli fél, és pontosan erre az információra van szüksége, amikor az alagút él, az alkalmazás pedig nem.

Ha egy NAT-szabály valóban szükséges, írja le, melyik címmel hiszi mindkét fél, hogy beszél. Ez az egy sor eldönti a viták többségét arról, hogy az alagút vagy a fordítás a hibás. Megmondja a következő mérnöknek azt is, hova nézzen, amikor a szabályt egy év múlva eltávolítják. Egy ping ezek egyikét sem teszi meg.

Bizonyítsa a fail-closedot, és ellenőrizze az MTU-t

Egy útvonal eltűnése önmagában nem fail-closed házirend. Egy másik tábla, egy alapértelmezett útvonal vagy egy házirend-szabály csendben biztosíthat tartalékot, és ennek egyetlen módja, hogy megtudja, a külső alagút leállítása és az alkalmazásforgalom viselkedésének megfigyelése. Tegye ezt szándékosan, egy ablakban, ahelyett hogy véletlenül fedezi fel.

Teszteljen három állapotot: külső alagút le, belső alagút le, és helyreállás, miután mindkettő visszatér. Használjon házirend-számlálókat minden átjárón, mert két létrejött IKE-munkamenet csak azt bizonyítja, hogy a vezérsík tárgyalása sikerült.

Kalkuláljon mindkét beágyazással. A működő IKE kis csomagos eredmény, és a teljes méretű alkalmazáscsomagok két fejléc hozzáadása után is meghiúsulhatnak; ismert hasznos tehermérettel teszteljen a valódi útvonalon, ahelyett hogy feltételezné, hogy a számok összeadódnak. A számtan könnyű, az útvonal nem.