Кога NAT вътре в VPN сайт-към-сайт си заслужава мястото
Транслацията може да спаси припокриващ се префикс или едностранен обратен път, но променя адресите, които вижда всяка политика. Проектирайте преобразуването изрично.
Двата обекта използват един и същ частен диапазон и тунелът се вдига, докато нищо полезно не го пресича. Транслацията е обичайният отговор и е истински: представянето на различен диапазон на далечната страна може да реши припокриване или обратен път, който другата мрежа не може да маршрутизира. Пропусканата част е, че транслацията променя адресите, които вижда всяко следващо решение. Отнасяйте се към нея като към документирано проектно решение с писмено преобразуване, а не като правило, добавяно, докато ping не успее.
Решете кой адрес се пренаписва
Транслацията на източника променя това, което отдалечената услуга и нейните журнали виждат като клиент, така че хостващият филиал пристига като адрес на шлюз. Транслацията на дестинация или префикс вместо това представя алтернативен адрес за отдалечен ресурс. Някои внедрявания се нуждаят от координирана транслация от двете страни, за да разделят две иначе идентични мрежи, и комбинацията е мястото, където започва повечето объркване.
Запишете източника преди транслацията, дестинацията, както я нарича приложението, и двойката адреси, по която съпоставя всеки шлюз. Три колони са достатъчни, а третата колона е тази, която хората пропускат.
Редът на селекторите също е важен. Изборът и транслацията на IPsec политика се извършват на определени етапи, така че селектор, написан за адреси преди транслация може никога да не съвпадне с пакета на етапа, който сте предположили. Проверявайте инсталираната политика, а не политиката, която сте възнамерявали да инсталирате, защото двете се разминават точно когато правило е прието от един компонент и игнорирано от друг:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
Следвайте полезния товар и обратния път
Сървър, който записва транслатирания източник вместо отделния филиален хост, ще счупи всяко правило или отчет, обвързани с оригиналния адрес. Преди да промените преобразуването, разберете дали нещо надолу по веригата взема решение от това поле: списъци за достъп, одитни отчети, ограничения на скоростта, проверки на лицензи. Всяко от тях е място, където транслацията по-късно се проявява като необясним отказ.
Протоколите, които носят адреси в полезния си товар, се нуждаят от отделно планиране, защото пренаписването на външния заглавен блок не докосва вътрешната референция. Активният FTP, SIP и някои продукти за отдалечен достъп са класическите случаи и проект, който ги пренебрегва, ще работи за уеб трафик и ще се провали за приложението, което е имало значение.
Обратният трафик зависи от преобразувания със състояние. Преминаването на шлюза може да загуби това състояние, асиметричното маршрутизиране може да го заобиколи, а рестартирането може да го изчисти, докато сесиите остават отворени от далечната страна. Затова заявката, която достига дестинацията, и сесията, която завършва, са два различни резултата от приемането.
Претеглете го срещу преномериране на обект
Преномерирането на един конфликтен обект премахва преобразуването напълно и оставя адресен план, който може да се чете без таблици за транслация. То е оперативно скъпо: DNS записи, статични назначения, правила на защитната стена и всеки документиран адрес трябва да се променят заедно. Разходът идва веднъж, в планиран прозорец, с ясно крайно състояние. Това, което купувате, е възможността да прочетете запис на пакети години по-късно без справочна таблица.
Транслацията избягва повечето локални промени и създава преобразуване, което трябва да се поддържа в DNS, документация и отстраняване на неизправности завинаги. Разходът идва непрекъснато, под формата на всеки бъдещ инженер, който трябва да научи, че един префикс означава нещо друго вътре в тунела.
За временна връзка или партньорска мрежа, която не контролирате, непрекъснатият разход обикновено си заслужава. За два обекта, които притежавате и ще притежавате години, преномерирането често е по-евтиното решение, след като миграцията се преброи честно.
Докажете двете посоки с реална сесия
Тествайте сесия на приложение, а не единична сонда. Успешна ехо заявка доказва, че една посока на един протокол работи, и е напълно съвместима с обратен път, който се проваля за всичко със състояние. Използвайте услугата, която мотивира проекта, и прочетете журнала ѝ в далечния край, за да видите кой адрес на източника е записала.
tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20
След това потвърдете, че през преобразуването са достъпни само предвидените услуги. Транслацията променя адресирането и не прави нищо за оторизацията, така че политиката на защитната стена все още решава какво е разрешено. Проект, който разчита на неясен транслатиран префикс като контрол на достъпа, изобщо няма контрол на достъпа.
Запишете преобразуването, тестваната сесия и адресите, които всяка страна е наблюдавала. Следващият човек, който ще отстранява неизправности по този тунел, се нуждае от тези три факта повече, отколкото от конфигурационния файл.