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