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 ниту идентитетот никогаш не биле проблем.