1. Алгоритм встановлення UDP сесії між 2 хостами знаходяться за NAT [ правити ]
2. Алгоритм встановлення TCP з'єднання між 2 хостами знаходяться за NAT [ правити ]

NAT - Network Address Translation, метод трансляції мережевих адрес, описаний в стандарті RFC 3022 , RFC тисячі шістсот тридцять одна . RFC 3022 російською мовою.

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

2. Ця функція дозволяє обмежити спілкування зовні до внутрішніх хостів, при цьому можливість спілкуватися зсередини назовні залишається.

3. Дає можливість приховати внутрішні сервіси внутрішніх хостів / серверів. Можна підмінити внутрішній порт офіційно зареєстрованої служби (наприклад, 80-й порт TCP (HTTP-сервер) на зовнішній 54055-й). Таким чином, зовні можна буде потрапити на сайт за адресою виду http://example.org:54055 , Але на внутрішньому сервері, що знаходиться за NAT, робота HTTP-сервера буде відбуватися на звичайному 80-м порту, тобто 80-й порт серверу не буде доступним з Інтернету для прямого вхідного з'єднання.

Комп'ютер може бути підключений до Інтернету безпосередньо (білий IP-адреса, зазвичай при підключенні безпосередньо до модему), або через NAT - тоді комп'ютер має локальний IP-адресу, з Інтернету недоступний (приватний, сірий). До сірим адресами відносяться адреси з наступних діапазонів:

Діапазон Кількість хостів 10.0.0.0 - 10.255.255.255/8 16 777 216 хостів 172.16.0.0 - 172.31.255.255/12 1 048 576 хостів 192.168.0.0 - 192.168.255.255/16 65 536 хостів

Перетворення адреси методом NAT може проводитися майже будь-яким маршрутизирующий пристроєм - маршрутизатором, сервером доступу, фаєрволом. Беручи пакет від локального комп'ютера, роутер дивиться на IP-адресу призначення. Якщо це локальний адресу, то пакет пересилається іншому локальному комп'ютеру. Якщо немає, то пакет треба переслати назовні в інтернет. Але ж зворотною адресою в пакеті вказано локальну адресу комп'ютера, який з інтернету буде недоступний. Тому роутер «на льоту» транслює (підміняє) зворотний IP-адреса пакета на свій зовнішній (видимий з інтернету) IP-адреса і змінює номер порту (щоб розрізняти відповідні пакети, адресовані різним локальним комп'ютерів). Комбінацію, потрібну для зворотного підстановки, роутер зберігає у себе в тимчасовій таблиці. Через деякий час після того, як клієнт і сервер закінчать обмінюватися пакетами, роутер зітре у себе в таблиці запис про n-му порте за терміном давності.

Один внутрішній адреса перетворюється в один зовнішній, всі запити, що приходять на зовнішню адресу транслюватимуться на внутрішній, як ніби хост і є володарем білого IP-адреси. Такий підхід буває корисним, коли всередині приватної мережі є сервер, до якого необхідний повний доступ ззовні. Мінус підходу в тому, що він ніяк не допомагає зберегти білі адреси.

Є пул білих адрес, наприклад, провайдер виділив мережу 198.51.100.0/28 з 16-ю адресами. Два з них (перший і останній) - адреса мережі і широкомовна, ще дві адреси призначаються на обладнання для забезпечення маршрутизації. Дванадцять залишилися адрес можна використовувати для NAT і випускати через них своїх користувачів.

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

Наступний тип має кілька назв: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT. Суть цього типу в тому, що через один зовнішній адресу виходить назовні багато приватних. Цей підхід, на відміну від попередніх, дозволяє вирішити проблему з нестачею зовнішніх адрес.

• Принцип мережевих адрес ніяк не вписується в архітектуру IP, яка має на увазі, що кожен IP-адреса унікальним чином ідентифікує тільки одну машину в світі.
• NAT порушує «наскрізний» принцип, згідно з яким кожен хост повинен вміти відправляти пакет будь-якого іншого хосту в будь-який момент часу. Оскільки відображення адрес в NAT задається вихідними пакетами, що входять пакети не приймаються до тих пір, поки не відправлені вихідні.
• NAT перетворює Інтернет з мережі без встановлення з'єднання в щось подібне мережі, орієнтованої на з'єднання. Проблема в тому, що NAT-блок повинен підтримувати таблицю відображення для всіх з'єднань, що проходять через нього. Запам'ятовувати стан з'єднання - справа мереж, орієнтованих на з'єднання, але ніяк не мереж без встановлення з'єднань.
• При використанні NAT порушується одне з фундаментальних правил побудови багаторівневих протоколів: рівень [math] k [/ math] не повинен будувати ніяких припущень щодо того, що саме рівень [math] k + 1 [/ math] помістив в поле корисного навантаження.
• Процеси в Інтернеті зовсім не зобов'язані використовувати тільки TCP або UDP. Якщо користувач машини [math] A [/ math] вирішить придумати новий протокол транспортного рівня для спілкування з користувачем машини [math] B [/ math], то йому доведеться якось боротися з тим, що NAT не зможе коректно обробити поле Порт джерела TCP.

Hole punching - метод для прямого з'єднання двох хостів, які знаходяться за NAT-ами. Для ініціації з'єднання потрібно третя сторона - сервер, який видно обох комп'ютерів. Зазвичай використовуються публічні STUN-сервери.

STUN (скор. Від англ. Session Traversal Utilities for NAT, Програми проходження сесій для NAT) - це мережевий протокол, який дозволяє клієнту, що знаходиться за сервером трансляції адрес (або за декількома такими серверами), визначити свій зовнішній IP-адреса, спосіб трансляції адреси і порту в зовнішній мережі, пов'язаний з певним внутрішнім номером порту. Ця інформація використовується для встановлення з'єднання UDP між двома хостами в разі, якщо вони обидва знаходяться за маршрутизатором NAT.

Алгоритм встановлення UDP сесії між 2 хостами знаходяться за NAT [ правити ]

Hole punching передбачає, що два клієнти, [math] A [/ math] і [math] B [/ math], вже мають UDP сесію з сервером [math] S [/ math]. Коли клієнт починає сесію з [math] S [/ math], сервер зберігає дві пари значень для цього клієнта: пару IP адреса і UDP порт, які клієнт вказує при відправці пакета в поле відправника, щоб говорити з [math] S [/ math ], і пару IP адреса і UDP порт відправника, які сервер спостерігає при отриманні пакету. Першу пару будемо називати приватним адресою, а другу публічним. Приватний адреса сервер може отримати від самого клієнта в тексті листа в поле реєстрації клієнта, а публічний адресу клієнта він може подивитися в поле відправника в заголовках IP і UDP цього повідомлення. Якщо клієнт не за NAT, то його приватний і публічний адресу повинні збігатися.

Припустимо, що клієнт [math] A [/ math] хоче встановити UDP сесію безпосередньо з клієнтом [math] B [/ math]. Hole punching відбувається наступним чином:

• [Math] A [/ math] спочатку не знає, як зв'язатися з [math] B [/ math], тому [math] A [/ math] просить допомоги у [math] S [/ math] в створенні UDP сесії з [ math] B [/ math].
• [Math] S [/ math] відповідає [math] A [/ math] повідомленням, що містить приватний і публічний адресу [math] B [/ math]. У той же час, [math] S [/ math] відправляє повідомлення [math] B [/ math] із запитом на з'єднання, що містить приватний і публічний адресу [math] A [/ math]. Після того, як ці повідомлення будуть отримані, [math] A [/ math] і [math] B [/ math] знають приватні і публічний адреси один одного.
• Коли [math] A [/ math] отримує приватний і публіний адреси [math] B [/ math] від [math] S [/ math], [math] A [/ math] починає посилати UDP пакети по обом адресами, і фіксує як правильний ту адресу, з якого першим прийшла відповідь від [math] B [/ math]. Аналогічним чином, коли [math] B [/ math] отримує приватний і публічний адресу [math] A [/ math], він починає посилати UDP пакети по обом адресами. Порядок і час доставки цих повідомлень не має вирішального значення, так як вони є асинхронними.

Якщо [math] A [/ math] і [math] B [/ math] знаходяться за одним і тим же NAT-ом, то вони з'єднаються через приватні адреси, інакше через публічні. На зображенні показаний приклад, коли [math] A [/ math] і [math] B [/ math] знаходяться за різними NAT-ами.

Алгоритм встановлення TCP з'єднання між 2 хостами знаходяться за NAT [ правити ]

Припустимо, що клієнт [math] A [/ math] хоче встановити TCP з'єднання з клієнтом [math] B [/ math]. Як і в UDP, ми припускаємо, що у [math] A [/ math] і [math] B [/ math] вже є TCP з'єднання з відомим сервером [math] S [/ math]. Сервер записує приватний і публічний адреси кожного зареєстрованого клієнта, так само як і для UDP. На рівні протоколу, TCP hole punching працює майже так само, як для UDP:

• Клієнт [math] A [/ math] використовує TCP з'єднання з [math] S [/ math], щоб попросити про допомогу для підключення до [math] B [/ math].
• [Math] S [/ math] відповідає [math] A [/ math], відправляючи приватний і публічний адреси [math] B [/ math], і в той же час посилає [math] B [/ math] приватний і публічний адреси [math] A [/ math].
• З тих же самих локальних портів TCP, які [math] A [/ math] і [math] B [/ math] використовують для з'єднання з [math] S [/ math], [math] A [/ math] і [math ] B [/ math] кожен асинхронно здійснюють спроби підключення один до одного з публічного і приватному адресами, і одночасно слухають ці порти на вхідні з'єднання.
• Коли TCP з'єднання встановлюється, клієнти ідентифікують один одного, щоб переконатися, що вони підключені до потрібного клієнту. Якщо перевірка справжності завершується невдало, клієнти закривають цей зв'язок і продовжують очікування. Клієнти використовують перше успішне з'єднання.

На відміну від UDP, де кожен клієнт тільки вимагає одного сокеті, щоб взаємодіяти з [math] S [/ math] і будь-яким числом хостів одночасно, в TCP додаток повинен керувати кількома сокетами прив'язаними до одного локального TCP порту на клієнті. Кожен клієнт має потребу в сокеті, який з'єднує його з [math] S [/ math], слухаючому сокеті, який буде приймати вхідні з'єднання, і в двох додаткових сокетах, за допомогою яких клієнт буде ініціювати витікаючі з'єднання з публічними і приватними TCP адресами іншого клієнта .

Джерела інформації [ правити ]