Два обекта, една подмрежа: изградете изглед с псевдоним за всеки

Два клиентски обекта използват 192.168.50.0/24 и отдалечен инженер трябва да достигне до принтер на същия адрес във всеки от тях. Нито един трик за маршрутизация не решава тази двусмисленост сам по себе си. Всеки обект се нуждае от отделен изглед на адресите и шлюзът трябва да избере обекта от този изглед, преди да препрати каквото и да е.

Планът има четири части: префикси за псевдоними, двете посоки на транслация, политика на наслагването и имена. Всяка трябва да е съгласувана с останалите.

Изберете един префикс за псевдоним на обект

Задайте на всеки обект цял префикс за псевдоним, който не принадлежи на никой друг в средата. План за два обекта може да съпостави 192.168.50.0/24 на обект A с 172.21.10.0/24, а идентичната локална мрежа на обект B — с 172.21.20.0/24. Проверете кандидатите срещу всяка участваща мрежа, включително облачни VPC и други VPN пулове. Частното адресно пространство се споделя от всяка организация, така че фактът, че диапазон е RFC 1918, не означава, че е свободен тук.

Публикувайте псевдонима, а не родната подмрежа, на отдалечените потребители. Родният диапазон остава местен факт.

Транслирайте в двете посоки

Транслирайте в двете посоки. Съпоставянето на дестинацията пренаписва адрес на псевдоним в родния адрес на притежаващия обект. Съпоставянето на източника пренаписва отдалечения извикващ в псевдоним, който другите обекти могат да различат.

Статичното съпоставяне едно към едно е детерминирано и това не прави реализацията безсъстоянийна. Обратната транслация може да зависи от състоянието на връзката, а превключването при отказ или асиметричните пътища могат да счупят план, който я игнорира. Документацията на платформата решава кой от тези случаи се прилага.

Точният етап, в който се прилагат политиката, селекторите и маршрутите, се различава между IPsec, базиран на политики, тунели, базирани на маршрути, и други продукти. Проектирайте за това, което използвате.

Проведете плана през наслагването

В хъб задайте всеки префикс за псевдоним на пътя на обекта, който го притежава, и разрешете само транзита, който задачата изисква. В мрежа всеки съответен партньор се нуждае от същия префикс и знания за политиката. Добавянето на тунели само по себе си не поправя двусмислената адресация.

Публикуването на цялата подмрежа е по-широко от публикуването на една услуга. Ако са нужни само няколко машини или порта, дръжте правилата за достъп по-тесни от съпоставянето.

Транслацията на заглавката не пренаписва полезния товар на приложението. Пренасочванията, вградените адреси в конфигурационни файлове и разрешенията, базирани на източника, все още могат да носят родния адрес. Тествайте пътя на приложението, а не само ping. Работещият ICMP отговор доказва, че съпоставянето съществува, и не казва нищо за това дали приложението приема псевдонима.

Поправете имената, които всеки извикващ вижда

Давайте на имената за поддръжка отговори, които съответстват на изгледа на извикващия. Ако отдалеченият инженер резолвва име на хост, то трябва да върне адреса на псевдонима за този обект, а не споделения роден диапазон.

Проверете DNS изгледите за всеки обект преди първия прозорец за поддръжка. Име, което се резолвва към родната подмрежа, връща извикващия обратно в двусмислието, което планът е трябвало да премахне.

Записвайте и проверявайте за всеки обект

Приемайте всеки обект поотделно от реален извикващ и потвърдете коя машина е отговорила. Запишете родния адрес, псевдонима, притежаващия шлюз и разрешената услуга заедно.

Този инвентар е това, което запазва разликата, когато трети обект пристигне със същата локална мрежа по подразбиране. Ръководството за IPsec NAT, базиран на политики, документира един конкретен модел на транслация; то не е договор за всяка платформа.