FortiGate зад NAT: local-gw, localid и публичният IP

FortiGate зад NAT може да притежава 10.0.0.2 на WAN интерфейса си, докато интернет го представя като 198.51.100.40, и двете числа са реални. Адресът, към който устройството се свързва, и идентичността, която изпраща при IKE удостоверяване, са отделни решения, взети в отделни полета за отделни аудитории. NAT пренаписва външната адресация по пътя, но не пренаписва удостоверена идентичност в това, което очаква далечният партньор. Повечето откази на фаза 1 в тази форма идват от поставянето на правилната стойност в грешното поле.

Три стойности, три собственика

Започнете с именуване на трите стойности и кой притежава всяка. local-gw е адресът, който FortiGate използва като източник за IKE на външния си интерфейс, и трябва да е адрес, който устройството наистина притежава. Публичният край е адресът на NAT устройството и се притежава от това, което извършва транслацията. IKE идентичността е низ, който партньорът сравнява със собствената си конфигурация, и изобщо не е задължително да е IP адрес.

Имената на полетата са достатъчно близки, за да подтикват към замяна, и това е капанът. localid и localid-type описват идентификация; local-gw описва локално свързване.

Пример прави разликата конкретна. На FortiGate отворете config vpn ipsec phase1-interface, след това set interface "wan1" и set local-gw 10.0.0.2 — адрес, който устройството притежава, и точно това кара IKE сокета да се свърже успешно. Оставете local-gw на 0.0.0.0 и се използва адресът на интерфейса, което обикновено е същото, но по-малко явно. Не задавайте local-gw на 198.51.100.40, защото устройството не притежава този адрес и сокетът няма да се свърже с него. Да направите две стойности еднакви на хартия не е конфигурация.

Стъпка 1: изберете идентичността, която партньорът ще приеме

Сега идентичността, което е различно решение. set localid приема стойността, която партньорът ще сравни, а set localid-type казва на FortiGate как да я тълкува: адрес, FQDN, потребителски FQDN или ключов ID. С auto устройството я извежда, обикновено от адреса на изходящия интерфейс, който е точно стойността, която NAT устройството ще промени.

Това извеждане е причината явната идентичност да е важна в тази топология. Ако партньорът очаква адресна идентичност, задайте localid-type address и localid на публичния адрес, който партньорът ще види, след което потвърдете, че партньорът приема тази стойност като идентичност, а не като цел за маршрутизиране. Ако партньорът очаква FQDN, използвайте localid-type fqdn и името, с което е конфигуриран. Проверете какво действително е изпратено с diagnose vpn ike gateway list, която показва състоянието на шлюза и използваните идентификатори, а не това, което сте смятали да напишете. Не предполагайте, че опция за тип идентичност приема произволен нелокален адрес; първо проверете документираната семантика на изданието.

Стъпка 2: пренасочете UDP 500 и 4500 към устройството

Третата стойност принадлежи на NAT устройството и е тази, която хората забравят да проверят. Публичният край трябва да пренасочва UDP 500 и UDP 4500 към FortiGate, защото откриването на NAT-T и инкапсулираният ESP след него зависят от пристигането на тези портове. Едно-към-едно съответствие е това, което този дизайн предполага; споделянето на един публичен адрес между няколко партньора по портове е различна топология с различни ограничения.

Потвърдете пренасочването със заснемане, а не с надежда: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 показва дали пакетите пристигат и дали отговорите излизат.

Google Cloud VPN документира NAT едно-към-едно с NAT-T като поддържана схема за партньор зад NAT и това е ограничението, спрямо което трябва да проектирате, ако далечният край е Cloud VPN шлюз. Споделянето едно-към-много или по портове не е същата поддържана топология и никакво локално настройване на идентичността не променя това. Ако далечната страна е друго устройство, собствената му документация определя какво ще приеме като идентичност и дали търпи трансфериран адрес на партньора. Прочетете това, преди да промените локално поле, защото локалната страна не може да договори правило, което далечната страна не прилага.

Стъпка 3: проверете какво фаза 1 не решава

Преносът през NAT вдига тунела, съгласието за идентичност решава дали партньорът ще го приеме, а маршрутизирането на вътрешния префикс решава какво действително преминава. Правилен локален ID не може да осигури липсващ статичен маршрут или липсващ селектор на трафик.

Затова проверявайте на слоеве. get vpn ipsec tunnel details показва дали тунелът е вдигнат и кои селектори са договорени, а несъответствието между конфигурираната отдалечена подмрежа и договорения селектор е проблем с маршрутизирането в костюм на фаза 2. execute vpn ike gateway clear принуждава ново договаряне, така че тествате текущата конфигурация, а не сесия, установена преди последната ви промяна. След това изпратете трафик към хост в отдалечения префикс и потвърдете, че броячите се движат, защото вдигнат тунел, който не пропуска нищо, изглежда идентичен на работещ, докато не проверите.

Дръжте трите стойности на едно място в бележките си: локалния адрес, който устройството притежава, публичния край, който NAT устройството представя, и низа на идентичността, който партньорът очаква. Те се променят по различни причини и по различно време.

Преномерирането на NAT устройство не е причина да пипате local-gw на FortiGate, а промяната на идентичност не е причина да преномерирате нищо. Смесването на двете е начинът, по който работещ тунел се преизгражда по време на несвързан прозорец за поддръжка. Ръководството на Cloud VPN за NAT е справката за поддържаната топология от онази страна.

Тестът, който решава въпроса, е скучен и бърз: заснемете на външния интерфейс, потвърдете, че UDP 500 и 4500 пристигат от партньора, потвърдете, че идентичността в IKE размяната съвпада с това, което партньорът е конфигуриран да очаква, след което потвърдете, че договорените селектори покриват подмрежите, които ви интересуват. Ако първата проверка се провали, заподозряното е NAT устройството. Ако втората се провали, това са полетата за идентичност. Ако третата се провали, нито NAT, нито идентичността някога са били проблемът.