Відмінності між версіями «IP-тунелі»
Рядок 4: | Рядок 4: | ||
Техніка IP-тунелів може виявитися іноді корисною і при адмініструванні маршрутизації, так як метрика зовнішніх протоколів маршрутизації може не враховувати пропускну спроможність каналів і деякі інші фактори, наприклад, QoS. У цьому випадку IP-дейтограми вкладаються в IP-дейтограми відправником (початок тунелю) і витягуються звідти в кінці тунелю. Кінець тунелю не обов'язково збігається з місцем призначення пакетів. Така проста схема тунелювання може породжувати деякі проблеми. | Техніка IP-тунелів може виявитися іноді корисною і при адмініструванні маршрутизації, так як метрика зовнішніх протоколів маршрутизації може не враховувати пропускну спроможність каналів і деякі інші фактори, наприклад, QoS. У цьому випадку IP-дейтограми вкладаються в IP-дейтограми відправником (початок тунелю) і витягуються звідти в кінці тунелю. Кінець тунелю не обов'язково збігається з місцем призначення пакетів. Така проста схема тунелювання може породжувати деякі проблеми. | ||
− | + | [[Image:Тунель1.gif|500px|right]] | |
Рис.1. Схема тунелювания пакетів. | Рис.1. Схема тунелювания пакетів. | ||
Рядок 14: | Рядок 14: | ||
− | + | [[Image:Тунель2.gif|500px]] | |
Рис.2. Схема транспортування запитів при використанні проксі-сервера | Рис.2. Схема транспортування запитів при використанні проксі-сервера | ||
Версія за 00:03, 5 грудня 2014
Особливість IP-протоколу (опція примусової маршрутизації) дозволяє переадресовувати IP-дейтограми певним вузлам мережі. На перший погляд ця можливість може здатися зовсім марною, адже існують механізми динамічної маршрутизації, які незрівнянно ефективніше і надійніше забезпечують обмін даними. Але тим не менш існують програми, де примусова маршрутизація на IP-рівні представляє можливості недоступні для традиційних рішень. Це насамперед мережі, що працюють з використанням протоколів IPX / SPX (Novell), де традиційна маршрутизація не передбачена. Для підключень віддалених серверів, що знаходяться поза локальної мережі, тут використовується технологія так званих IP-тунелів. При реалізації цієї технології IPX-пакети інкапсулються в IP-дейтограми і доставляються у відповідність з протоколами TCP / IP. Процедура інкапсуляції здійснюється спеціальним драйвером (IPtunnel; використовує протокол IPXODI), який працює так, як якщо б він був драйвером апаратного мережевого інтерфейсу. При цьому необхідно модифікувати конфігураційний файл net.cfg (Див., Наприклад, www2.ncsu.edu/cc-consult/usinglwp/tunnel.html).
Техніка IP-тунелів може виявитися іноді корисною і при адмініструванні маршрутизації, так як метрика зовнішніх протоколів маршрутизації може не враховувати пропускну спроможність каналів і деякі інші фактори, наприклад, QoS. У цьому випадку IP-дейтограми вкладаються в IP-дейтограми відправником (початок тунелю) і витягуються звідти в кінці тунелю. Кінець тунелю не обов'язково збігається з місцем призначення пакетів. Така проста схема тунелювання може породжувати деякі проблеми.
Рис.1. Схема тунелювания пакетів. Квадратними дужками відзначено вкладення пакетів. У чисельнику наводиться адреса місця призначення, в знаменнику адреса відправника. Адреса поза дужками - адреса місця призначення.
З малюнка видно, що простий тунель може породити асиметричний маршрут, при якому шлях туди і назад не збігаються. Щоб такого не сталося, застосовується техніка "маскараду" (маскування). Для цього "маршрутизатор кінця тунелю" повинен витягти вкладений пакет (як це він робить - рис.1) і вкласти його в пакет з адресою місця призначення IP3, вказавши при цьому в якості відправника себе (IP3 / IP2 [IP3 / IP1]). Тоді кінцевий адресат IP3 буде посилати відгуки за адресою IP2, а не IP1. А вже маршрутизатор кінця тунелю буде пересилати їх першоджерела запиту IP1.
Останнім часом техніка тунелів знайшла застосування при побудові так званих проксі-серверів, популярність яких пов'язана з можливістю помітно скоротити зовнішній (часто зарубіжний) трафік за рахунок запам'ятовування в дисковому буфері файлів, найбільш часто запитуваних клієнтами. Помітно спрощує рішення даної задачі багато сучасних маршрутизатори, які можуть відфільтровувати запити по певних портів і переадресовувати їх проксі-сервера.
Рис.2. Схема транспортування запитів при використанні проксі-сервера
Схема з "невидимим" проксі-сервером працює таким чином. Спочатку запит надходить в маршрутизатор, там він аналізується і, якщо з'ясовується що це HTTP або FTP-запити, переадресовується проксі-сервера. Якщо запитуваний файл знаходиться в буфері сервера, замовлення клієнта задовольняється локально. В іншому випадку запит знову надсилається маршрутизатору. Запити проксі-сервера маршрутизатор переправляє в зовнішню мережу. У разі використання персональної ЕОМ в якості проксі-сервера можна її забезпечити двома мережевими інтерфейсами для прийому і посилки запитів, що зробить роботу більш ефективною. Якщо маршрутизатор не підтримує описаний режим, то при конфігурації мережевого програмного забезпечення клієнта можна явно прописати адресу проксі-сервера і всі відповідні запити підуть безпосередньо туди.
Тунелі широко використовуються і при передачі мультимедійних даних.