Маловідомі подробиці роботи NAT

Використовуючи термінологію Cisco, в контексті NAT є чотири основні визначення для IP-адрес. Розглянемо їх на прикладі, показаному на малюнку нижче. На обох маршрутизаторах робиться NAT (network address translation).

При цьому використовуються такі терміни:


Найпростіший випадок NAT – це трансляція адрес Inside Local в Inside Global і навпаки. При цьому маршрутизатор, що виконує NAT, модифікує полі адреси в заголовку IP наступним чином:


Таким чином, в таблиці зіставлень NAT кожен запис складається з двох значень – IL і IG.

Ця або подібна схема іноді застосовується для забезпечення доступу зовні до хостів, що знаходяться в локальній мережі (наприклад, до веб-сервера або FTP-серверу). Вона може також застосовуватися для балансування навантаження шляхом динамічного розподілу пакетів, що приходять на публічний адреса маршрутизатора, між декількома серверами, що знаходяться в локальній мережі, і ще в деяких випадках.

Більш поширений випадок – це NPAT, network and port address translation. При використанні NPAT в таблиці зіставлень кожен запис має не два (як в простому NAT), а п'ять значень:


Це дозволяє використовувати єдиний публічний адреса для надання доступу в Інтернет комп'ютерів, що знаходяться в локальній мережі. У документації Cisco така схема зазвичай називається "NAT with port overload "або коротше – “NAT overload”.

Історично склалося так, що саме його, як правило, мають на увазі, коли вживають термін "NAT", і про нього ми і будемо говорити в подальшому, зважаючи на його поширеності.

До цих пір мова йшла про речі загальновідомих. Однак, якщо подивитися на NAT ближче, виникають нові питання. Візьмемо найпростішу мережу, з одним комп'ютером і одним шлюзом, виконуючим NAT. Модель маршрутизатора в даному випадку не дуже важлива – припустимо, що це давно застаріла, але все ще популярна Cisco 1601R.



У конфігурації маршрутизатора зазначено, що він повинен виконувати NAT для всіх пакетів, з адресами джерела 192.168.0.0/24, що прийшли через інтерфейс Ethernet0 і відправляються далі через інтерфейс Serial0, а також для відповідних пакетів, що прийшли через Serial0, для яких є відповідний запис у таблиці трансляцій:


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


Припустимо, комп'ютер з адресою IL 192.168.0.141 відправляє DNS-запит на зовнішній хост 1.2.3.4 (порт 53, протокол UDP). Як випливає з конфігурації, наш зовнішній адресу IG – 11.22.33.44.

У результаті цього в таблиці 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


Припустимо, після появи такого запису в таблиці, інший хост, 1.2.3.5, відправляє пакет UDP з адресою призначення 11.22.33.44 і портом призначення 1053. Питання – чи отримає наш хост 192.168.0.141 цей пакет?

Здоровий глузд підказує, що начебто не повинен. З іншого боку, в наявності факт: у нашій таблиці NAT чорним по білому записано, що пакет з адресою призначення 11.22.33.44 і портом призначення 1053 потрібно прийняти і транслювати в локальну мережу для хоста 192.168.0.141 (який його прийме і мовчки знищить, оскільки на цьому комп'ютері не запущено мережевого програми, якому був би призначений цей пакет.)

До речі кажучи – ну добре, допустимо такого додатка немає, а якби воно було? Як добре відомо користувачам таких програм, як eMule і eDonkey, вони вимагають, щоб їм була надана можливість безперешкодно отримувати UDP пакети з портом призначення 4661, або 4242, або 4321 – точний номер порту залежить від настройок. І, що також добре відомо їх користувачам, ці програми погано працюють, будучи запущені з локальної мережі, що знаходиться за NAT. Так от, це може відбуватися, в тому числі й тому, що незважаючи на успішне встановлення локальних клієнтом з'єднання з сервером, через специфіку даної конкретної реалізації NAT інші клієнти, що знаходяться у зовнішньому світі, не можуть встановлювати з'єднання з локальним клієнтом.

З цієї ж причини може не працювати DCC chat в клієнтах IRC, передача файлів в ICQ і тому подібні речі, для яких вимагається забезпечення безперешкодного проходження пакетів безпосередньо між призначеними для користувача комп'ютерами.

Отже, відповідаючи на запитання, "чи отримає наш хост 192.168.0.141 пакет, спрямований на 11.22.33.44 від стороннього хоста", – може бути, отримає, а може, й ні; відповідь на це питання залежить від реалізації NAT на прикордонному маршрутизаторі.

Реалізацій ж нараховується чотири:


Як бачимо, реалізації NAT – це справжній зоопарк, в якому кожній тварі по парі. Положення пом'якшується тим, що для більшості мережевих додатків подробиці реалізації NAT великого значення не мають (Особливо для додатків, що використовують транспорт TCP, як відомо, це протокол, що використовує сесії, тому сказане вище для TCP неактуально. Тим не менше з розвитком додатків Peer-to-Peer (EDonkey, eMule, Skype), IPтелефоніі і різноманітною мережевий мультимед.повід (найчастіше використовують транспорт на основі UDP) відмінності в реалізаціях NAT поступово починають відігравати помітну роль. Тому для розробників таких програм прийшла пора задуматися над тим, як їх дітище буде працювати, перебуваючи в локальній мережі за NATом. Одним з плодiв таких роздумів став протокол STUN (Simple Traversal of UDP through NAT), описаний в RFC 3489.

Деяким додатків, особливо призначеним для IP-телефонії (оскільки там це найбільш актуально), важливо знати, чи знаходиться комп'ютер, на якому вони запущені, в локальній мережі за NAT або на комп'ютері з публічним IP адресою, і у випадку NAT – визначити, якого він типу. Для цього в даний час широко використовується протокол STUN, який дозволяє також визначити наявність блокуючого firewall на прикордонному маршрутизаторі або самому комп'ютері.

Протокол STUN


Ідея STUN нескладна – клієнт відправляє на що знаходиться зовні сервер зондувальні повідомлення, використовуючи транспорт UDP. У тілі цих повідомлень містяться IP адреси і номери портів джерела і приймача. Неодмінним умовою роботи сервера є використання ним двох IP-адрес – далі стане зрозуміло, для чого.

Процес визначення типу NAT з використанням STUN протікає в такий спосіб. Припустімо, наш клієнт перебуває за NAT, його локальний адресу 192.168.0.111, публічний адреса NAT – 1.2.3.4, адреси сервера STUN – 11.22.33.1 і 11.22.33.2, номери портів 3478. Відбувається наступне:


Для ілюстрації роботи STUN розглянемо наступний малюнок (узятий із статті "Anatomy: A Look Inside Network Address Translators" в "The IP Journal" Vol.7 Num. 2 за вересень 2004 р.).



Клієнт STUN вбудований в деякі програми IP-телефонії, наприклад, X-Pro і X-Lite від компанії CounterPath, і в деякі інші. Консольний клієнт STUN під ОС Windows може бути завантажений звідси: http://prdownloads.sourceforge.net/stun/client.exe?download.

Запустивши його і вказавши в якості параметра командного рядка один з публічних STUN-серверів, ви дізнаєтеся тип вашого NAT:


C:>client.exe stun.xten.com

STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9


Наведений вище результат отримано на комп'ютері, що знаходиться за маршрутизатором ZyXEL Prestige 645R.

Результат для маршрутизатора Cisco 1721 з IOS версії 12.2 у свою чергу виглядає так:


C:>client.exe stun.xten.net

STUN client version 0.94

Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b


Такий же результат отриманий для маршрутизатора, побудованого на основі FreeBSD, на якій NAT виконувалася демоном natd.

А ось як виглядає результат для PIX (прим. HunSolo)
C:>client.exe stun.xten.net

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


Random port означає, що дана реалізація NAT не піклується про те, щоб номер порту джерела у вихідному назовні пакеті залишався таким же, яким він був отриманий від хоста локальної мережі, і замінює його на випадкове значення в діапазоні від 1024 до 65535. Можна припустити, що за задумом автора ідеї "random ports" така заміна зменшує ймовірність конфлікту між записами, якщо кілька хостів локальної мережі одночасно спробують відправити назовні пакети з співпадаючим номером порту джерела. Оскільки номер порту джерела у вихідних пакетах формується хостами локальної мережі також випадковим чином, переваги такої заміни сумнівні, з недоліків ж можна назвати хоча б потенційну проблему з протоколом RPC, та й не тільки.

Як видно з прикладу, наш маршрутизатор прагне зберігати номер порту незмінним (11.22.33.44:1053 і 192.168.0.141:1053), з чого випливає, що запущений в його локальної мережі STUN-клієнт повідомив би про ньому preserves ports. До слова, на FreeBSD цей результат досягається ключем "-same_ports" або "-s" у рядку запуску або конфігураційному файлі демона natd.

Hairpin ж означає наступне. Припустимо, якщо введення NAT наведеної вище рядки інший хост нашої локальної мережі (наприклад, 192.168.0.241) відправляє UDP-пакет з адресою призначення 11.22.33.44, портом призначення 1053 і портом джерела 53. Що відбудеться в результаті?

Відповідь на це питання залежить від того, підтримує маршрутизатор функцію "hairpin" або не підтримує. Якщо він її підтримує, пакет буде звичайним чином оброблений і (якщо на маршрутизаторі використовується реалізація NAT Full Cone або Port Restricted) потрапить за призначенням – на хост 192.168.0.141. Якщо ж немає ("no hairpin"), пакет буде знищений маршрутизатором. Назва функції "hairpin" (шпилька для волосся) походить від того, що, якщо зобразити проходження такого пакету на малюнку, форма його траєкторії буде схожа на U-образну шпильку. Інше пояснення – слово "hairpin" перекладається так само, як "розворот на 180 градусів ". За підтримки маршрутизатором функції" hairpin "підпадають під її дію пакети, дійсно, будуть розгорнуті на 180 градусів і відправлені назад в локальну мережу.

NAT і шлюзи додатків


На жаль, не у всіх мережевих протоколів взаємодія з NAT протікає безболісно. Найбільш часто зустрічається приклад – це FTP. Тут можливі два випадки.

Перший випадок. Користувач, що знаходиться в локальній мережі за NAT, використовує FTP-клієнт для того, щоб отримати доступ до FTP-сервера з публічним IP-адресою



Проблема тут виникає, коли клієнт намагається використовувати активний режим 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).

Найбільший інтерес тут представляє перша команда від клієнта, яка інформує сервер про те, що хост з адресою 192.168.0.101 відкрив для прийому з'єднання даних порт номер (4 * 256) + 211 = 1235. У відповідь на це сервер повинен встановити з'єднання даних зі свого порту номер 20 на вказаний порт хоста 192.168.0.101. Оскільки ця адреса є приватним, таке з'єднання не може бути встановлено. У результаті спостерігається знайомий багатьом системним адміністраторам ефект, коли клієнт начебто успішно підключається до FTP-сервера, але не може стягувати з нього файли або навіть переглядати вміст поточного каталогу (це відбувається тому, що передача лістингу файлів з сервера на клієнт також здійснюється по з'єднанню даних).

Щоб боротьби з описаною проблемою може використовуватися перемикання сервера в так званий пасивний режим. Оскільки в цьому режимі ініціатором з'єднання даних виступає клієнт, проблема зникає. Саме тому в Microsoft Internet Explorer, як і консольний FTP-клієнт, вбудований в Windows, використовують за замовчуванням пасивний режим (вони автоматично вставляють перед командами RETR і NLST команду PASV, перемикає сервер у пасивний режим).

Другий випадок. Користувач, що знаходиться в локальній мережі за NAT, використовує FTP-клієнт для того, щоб отримати доступ до FTP-сервера, який також знаходиться за NAT. У цьому випадку, очевидно, не допоможе і пасивний режим, так як в команді PORT незалежно від того, клієнт або сервер її віддає, завжди буде вказаний приватний IP-адресу, і з'єднання даних ніколи не буде встановлено.

Для вирішення цієї проблеми в деяких реалізаціях NAT існує спеціальна функція – трансляція адрес на рівні додатків, звана також NAT ALG (Application Level Gateways). При задіяної функції ALG маршрутизатор відслідковує і модифікує дані рівня додатків деяких мережевих протоколів.

Так, у наведеному вище прикладі, якщо припустити, що публічний IP-адресу маршрутизатора з NAT 1.2.3.4 і що він зберігає номер порту джерела незмінним, команда PORT 192,16,0,101,4,211 була б змінена маршрутизатором на PORT 1,2,3,4,4,211. Завдяки цьому в обох зазначених вище випадках з'єднання даних буде успішно встановлено.

Функція ALG в маршрутизаторах Cisco дозволяє здійснювати трансляцію адрес рівня додатків не тільки для протоколу FTP, але також і для протоколів SIP, H.323, Skinny і деяких інших (завдяки цьому можна, наприклад, розміщувати в локальній мережі сервери DNS). Для більшої зручності функція ALG в маршрутизаторах Cisco включена за замовчуванням.

Аналогічну ALG функціональність в маршрутизаторах на основі ОС Linux забезпечують додаткові завантажувані модулі і патчі до ядра (такі, як ip_masq_ftp, ip_masq_irc і т. п.).

Висновок


Розуміння принципів роботи різних реалізацій NAT може виявитися корисним при пошуку причини незадовільної роботи деяких додатків, що використовують транспортний протокол UDP. Так, наприклад, поєднання ALG і Symmetric або Port Restricted NAT і IP-телефонів, що використовують протокол установки соедіененія SIP, може часом давати найхимерніші результати (спорадичні відмови в реєстрації на сервері, одностороння чутність між абонентами і т. п.), причому це залежить не тільки від налаштувань IP-телефону, але і від настройок сервера. Інший приклад: компанія Microsoft повідомляє у своїй статті KB817778, що їх реалізація тунелю IPv6 over UDP не буде працювати через Symmetric NAT (адреса статті в Інтернеті: http://support.microsoft.com/kb/817778/EN-US). Таких прикладів можна знайти ще багато, і у всіх випадках розуміння відмінностей в реалізаціях NAT якщо й не допоможе негайно усунути проблему, то хоча б вкаже на можливі шляхи вирішення (наприклад, замінити firmware маршрутизатора на таке, де NAT реалізований у вигляді Full Cone, якщо, звичайно, воно існує, або замінити сам маршрутизатор).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*