GRE/IPSEC терминация зад NAT

Да предположим , че ни трябва (по каквато и да било причина; ) ) site-to-site VPN, на който едната страна да е зад NAT. Следната диаграма илюстрира този сценарий:

GRE over IPSEC, terminating both behind NAT

GRE/IPSEC terminating behind NAT

Трябва да имаме IPSEC SA между RLeft и RRight и също така трябва да имаме GRE тунел между същите два рутера, върху тази IPSEC SA. IPSEC асоцияцията ще енкапсулира и защитава само GRE трафика за тунелния интерфейс.

Начални бележки

Ако искаме RRight да бъде зад NAT, има някои потенциални проблеми пред нормалната работа на IPSEC. Source адреса на пакетите от RRight се замества с публичното IP, което NATRouter използва за адресната транслация. Понеже RLeft не знае за никакви NAT-ове по пътя, той ще вижда пакети идващи от публичното NAT IP 172.16.20.3, а не от същинския интерфейс на RRight. Следователно, за да работят нещата нормално, RRight ще трябва да се аутентикира като 172.16.20.3, и поради тази причина трябва да вдинем loopback на RRight, който да държи този IP адрес. По същата причина, тази ситуация не би могла да работи с NAT interface overloading на NATRouter, когато NATRouter ще използва своя собствен интерфейс за публичен адрес при адресната транслация – в този случай адреса на loopback интерфейса на RRight би бил същия, като IP адреса на fa0/0 интерфейса на NATRouter, и в този случай ще има проблем с рутираните на пакетите обратно до RRight.

NAT traversal

IPSEC има вградена NAT-transparency функционалност, също известна на някои места кат “UDP wrapper”, или “UDP енкапсулация” – тази функционалност е включена по подразбиране от IOS 12.2(13)T нататък. Тази функционалност позволява на IPSEC крайните точки да засичат дали някъде по мрежата между тях има NAT. Това става, като си обменят хешове на source и destination IP адреса и порта, на всеки край на IPSEC Security Association-а. След това всеки от двата рутера рекалкулира хешовете локално, и ги сравнява с получените хешове от отсрещтната страна. Ако се появи разлика, значи адресите са били променени някъде по мрежата и следователно някъде по пътя има NAT. Следващата стъпка е да се договори изполването на NAT-T, при положение, че и двата рутера го поддържат. Последната (и може би нй-важна) стъпка е да се енкапсулира всеки IPSEC SA и ISAKMP пакет в нов UDP хедър. IPSEC NAT-T  използва UDP порт 4500.

Конфигурации

(more…)