Маловідомі подробиці роботи nat - nat - програмні продукти
Таким чином, в таблиці зіставлень NAT кожен запис складається з двох значень - IL і IG.
Історично склалося так, що саме його, як правило, мають на увазі, коли вживають термін "NAT", і про нього ми і будемо говорити в подальшому, з огляду на його поширеності.
До цих пір мова йшла про речі загальновідомих. Однак, якщо подивитися на NAT ближче, виникають нові питання. Візьмемо найпростішу мережу, з одним комп'ютером і одним шлюзом, який виконує NAT. Модель маршрутизатора в даному випадку не дуже важлива - припустимо, що це давно застаріла, але все ще популярна Cisco 1601R.
interface Serial0
ip address 11.22.33.44 255.255.255.252
ip nat outside
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip nat inside source list MyNetwork interface Serial0 overload
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any
В результаті цього в таблиці NAT з'явиться приблизно такий запис:
Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53
До речі кажучи - ну добре, допустимо такого додатка немає, а якби воно було? Як добре відомо користувачам таких програм, як eMule і eDonkey, вони вимагають, щоб їм була надана можливість безперешкодно отримувати UDP пакети з портом призначення 4661, або 4242, або 4321 - точний номер порту залежить від налаштувань. І, що також добре відомо їх користувачам, ці програми погано працюють, будучи запущені з локальної мережі, що знаходиться за NAT. Так ось, це може відбуватися, в тому числі і тому, що не дивлячись на успішне встановлення локальних клієнтом з'єднання з сервером, через специфіку даної конкретної реалізації NAT інші клієнти, що знаходяться в зовнішньому світі, не можуть встановлювати з'єднання з локальним клієнтом.
З цієї ж причини може не працювати DCC chat в клієнтах IRC, передача файлів в ICQ і тому подібні речі, для яких потрібне забезпечення безперешкодного проходження пакетів безпосередньо між призначеними для користувача комп'ютерами.
Отже, відповідаючи на питання, "чи отримає наш хост 192.168.0.141 пакет, спрямований на 11.22.33.44 від стороннього хоста", - може бути, отримає, а може бути, і немає; відповідь на це питання залежить від реалізації NAT на прикордонному маршрутизаторі.
протокол STUN
Запустивши його і вказавши в якості параметра командного рядка один з публічних STUN-серверів, ви дізнаєтеся тип вашого NAT:
STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9
Наведений вище результат отриманий на комп'ютері, що знаходиться за маршрутизатором ZyXEL Prestige 645R.
Результат для маршрутизатора Cisco тисячі сімсот двадцять один з IOS версії 12.2 в свою чергу виглядає так:
STUN client version 0.94
.
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
Такий же результат отримано для маршрутизатора, побудованого на основі FreeBSD, на якій NAT виконувалася демоном natd.
А ось як виглядає результат для PIX (прим. HunSolo)
STUN client version 0.94
.
Primary: Port Restricted Nat, rundom port, no hairpin
Return value is 0xb
Залишилося пояснити, що таке "random port", "preserves ports" і "no hairpin" в наведених вище результати.
Подивимося ще раз на рядок з таблиці NAT в нашому прикладі:
Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53
Як видно з прикладу, наш маршрутизатор намагається зберігати номер порту незмінним (11.22.33.44:1053 і 192.168.0.141:1053), з чого випливає, що запущений в його локальної мережі STUN-клієнт повідомив би про нього preserves ports. До слова, на FreeBSD цей результат досягається ключем "-same_ports" або "-s" в рядку запуску або файлі конфігурації демона natd.
Відповідь на це питання залежить від того, підтримує маршрутизатор функцію "hairpin" або не підтримує. Якщо він її підтримує, пакет буде звичайним чином оброблений і (якщо на маршрутизаторі використовується реалізація NAT Full Cone або Port Restricted) потрапить за призначенням - на хост 192.168.0.141. Якщо ж немає ( "no hairpin"), пакет буде знищений маршрутизатором. Назва функції "hairpin" (шпилька для волосся) походить від того, що, якщо зобразити проходження такого пакета на малюнку, форма його траєкторії буде схожа на U-подібну шпильку. Інше пояснення - слово "hairpin" перекладається так само, як "розворот на 180 градусів". За підтримки маршрутизатором функції "hairpin" підпадають під її дію пакети, дійсно, будуть розгорнуті на 180 градусів і відправлені назад в локальну мережу.
NAT і шлюзи додатків
На жаль, не у всіх мережевих протоколів взаємодія з NAT протікає безболісно. Найбільш часто зустрічається приклад - це FTP. Тут можливі два випадки.
Проблема тут виникає, коли клієнт намагається використовувати активний режим FTP. Сесія протікає при цьому наступним чином. В деякий момент по керуючому з'єднанню серверу передається команда FTP-клієнта: PORT 192,16,0,101,4,211.
Подальший діалог виглядає приблизно так:
Server: 200 PORT command successful. Consider using PASV.
Client: RETR file.zip
Server: 150 Opening BINARY mode data connection for file.zip (1334109 bytes).
ля боротьби з описаною проблемою може використовуватися перемикання сервера в так званий пасивний режим. Оскільки в цьому режимі ініціатором з'єднання даних виступає клієнт, проблема зникає. Саме тому в Microsoft Internet Explorer, як і консольний FTP-клієнт, вбудований в Windows, використовують за замовчуванням пасивний режим (вони автоматично вставляють перед командами RETR і NLST команду PASV, перемикає сервер в пасивний режим).
Аналогічну ALG функціональність в маршрутизаторах на основі ОС Linux забезпечують додаткові завантажувані модулі і патчі до ядра (такі, як ip_masq_ftp, ip_masq_irc і т. П.).