Két telephely, egy alhálózat: készítsen külön alias-nézetet mindegyiknek

Két ügyféltelephely egyaránt 192.168.50.0/24 hálózatot használ, és egy távoli mérnöknek mindkettőben ugyanazon a címen lévő nyomtatót kell elérnie. Egyetlen útválasztási trükk sem oldja meg ezt a kétértelműséget önmagában. Minden telephelynek külön címnézetre van szüksége, és az átjárónak ebből a nézetből kell kiválasztania a telephelyet, mielőtt bármit továbbít.

A tervnek négy része van: alias-előtagok, mindkét fordítási irány, átfedési szabályzat és nevek. Mindegyiknek egyeznie kell a többivel.

Válasszon egy alias-előtagot telephelyenként

Rendeljen minden telephelyhez egy teljes alias-előtagot, amely a környezetben senki máshoz nem tartozik. Egy kéttelphelyes terv az A telephely 192.168.50.0/24 hálózatát 172.21.10.0/24-re, a B telephely azonos LAN-ját pedig 172.21.20.0/24-re képezheti le. Ellenőrizze a jelölteket minden részt vevő hálózattal szemben, beleértve a felhős VPC-ket és a többi VPN-készletet. A privát címteret minden szervezet megosztja, ezért az, hogy egy tartomány RFC 1918-as, nem mond semmit arról, hogy itt szabad-e.

Az aliast tegye közzé, ne az eredeti alhálózatot, a távoli felhasználók számára. Az eredeti tartomány helyi tény marad.

Fordítson mindkét irányban

Fordítson mindkét irányban. A célleképezés az alias-címet az eredeti címre írja át a tulajdonos telephelyen. A forrásleképezés a távoli hívót olyan aliasra írja át, amelyet a többi telephely meg tud különböztetni.

A statikus egy-az-egyhez leképezés determinisztikus, és ez nem teszi állapotmentessé a megvalósítást. A fordított fordítás függhet a kapcsolat állapotától, és a feladatátvétel vagy az aszimmetrikus útvonalak megtörhetnek egy olyan tervet, amely ezt figyelmen kívül hagyja. A platform dokumentációja dönti el, hogy ezek közül melyik érvényes.

A pontos szakasz, ahol a szabályzat, a szelektorok és az útvonalak érvényesülnek, eltér a szabályzatalapú IPsec, az útvonalalapú alagutak és más termékek között. Ahhoz tervezzen, amelyiket üzemeltet.

Vigye át a tervet az átfedésen

Egy hubban rendelje minden alias-előtagot ahhoz a telephelyútvonalhoz, amely birtokolja, és csak a feladat által igényelt tranzitot engedélyezze. Egy mesh hálózatban minden érintett peernek ugyanarra az előtagra és szabályzatismeretre van szüksége. Az alagutak hozzáadása önmagában nem javítja a kétértelmű címzést.

A teljes alhálózat közzététele szélesebb, mint egyetlen szolgáltatás közzététele. Ha csak néhány gép vagy port kell, tartsa a hozzáférési szabályokat szűkebben, mint a leképezés.

A fejlécfordítás nem írja át az alkalmazás hasznos terheit. Az átirányítások, a konfigurációs fájlokba ágyazott címek és a forrásalapú engedélyek továbbra is hordozhatják az eredeti címet. Tesztelje az alkalmazás útvonalát, ne csak a pinget. Egy működő ICMP-válasz bizonyítja, hogy a leképezés létezik, és semmit sem mond arról, hogy az alkalmazás elfogadja-e az aliast.

Javítsa ki a neveket, amelyeket minden hívó lát

Adjon a karbantartási neveknek a hívó nézetének megfelelő válaszokat. Ha a távoli mérnök egy hosztnevet old fel, akkor az adott telephely alias-címét kell visszaadnia, nem a megosztott eredeti tartományt.

Ellenőrizze a DNS-nézeteket telephelyenként az első karbantartási ablak előtt. Egy név, amely az eredeti alhálózatra oldódik fel, visszaküldi a hívót abba a kétértelműségbe, amelyet a tervnek meg kellett szüntetnie.

Rögzítsen és ellenőrizzen telephelyenként

Fogadjon el minden telephelyet külön-külön egy valódi hívótól, és erősítse meg, melyik gép válaszolt. Rögzítse együtt az eredeti címet, az aliast, a tulajdonos átjárót és az engedélyezett szolgáltatást.

Ez a leltár az, ami megőrzi a megkülönböztetést, amikor egy harmadik telephely ugyanazzal az alapértelmezett LAN-nal érkezik. A szabályzatalapú IPsec NAT útmutató egy konkrét fordítási modellt dokumentál; ez nem szerződés minden platformra.