Відмінності між версіями «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.gif

Рис.1. Схема тунелювания пакетів. Квадратними дужками відзначено вкладення пакетів. У чисельнику наводиться адреса місця призначення, в знаменнику адреса відправника. Адреса поза дужками - адреса місця призначення.

З малюнка видно, що простий тунель може породити асиметричний маршрут, при якому шлях туди і назад не збігаються. Щоб такого не сталося, застосовується техніка "маскараду" (маскування). Для цього "маршрутизатор кінця тунелю" повинен витягти вкладений пакет (як це він робить - рис.1) і вкласти його в пакет з адресою місця призначення IP3, вказавши при цьому в якості відправника себе (IP3 / IP2 [IP3 / IP1]). Тоді кінцевий адресат IP3 буде посилати відгуки за адресою IP2, а не IP1. А вже маршрутизатор кінця тунелю буде пересилати їх першоджерела запиту IP1.

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


Тунель2.gif Рис.2. Схема транспортування запитів при використанні проксі-сервера

Схема з "невидимим" проксі-сервером працює таким чином. Спочатку запит надходить в маршрутизатор, там він аналізується і, якщо з'ясовується що це HTTP або FTP-запити, переадресовується проксі-сервера. Якщо запитуваний файл знаходиться в буфері сервера, замовлення клієнта задовольняється локально. В іншому випадку запит знову надсилається маршрутизатору. Запити проксі-сервера маршрутизатор переправляє в зовнішню мережу. У разі використання персональної ЕОМ в якості проксі-сервера можна її забезпечити двома мережевими інтерфейсами для прийому і посилки запитів, що зробить роботу більш ефективною. Якщо маршрутизатор не підтримує описаний режим, то при конфігурації мережевого програмного забезпечення клієнта можна явно прописати адресу проксі-сервера і всі відповідні запити підуть безпосередньо туди.

Тунелі широко використовуються і при передачі мультимедійних даних.