Відмінності між версіями «IP-тунелі»
| (не показані 4 проміжні версії цього учасника) | |||
| Рядок 1: | Рядок 1: | ||
| + | =<h3 style="font-family:verdana;text-align:center;font-size: 20pt; color: blue;">IP-тунелі</h3>= | ||
| − | + | [[Image:Tunnel.gif|250px|right]] | |
| + | <p style="font-family: century;font-size: 14pt;color: purple"> | ||
| − | + | Особливість IP-протоколу (опція примусової маршрутизації) дозволяє переадресовувати [https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B9%D1%82%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 IP-дейтограми] певним вузлам мережі. На перший погляд ця можливість може здатися зовсім марною, адже існують механізми динамічної маршрутизації, які незрівнянно ефективніше і надійніше забезпечують обмін даними. Але тим не менш існують програми, де примусова маршрутизація на IP-рівні представляє можливості недоступні для традиційних рішень. Це насамперед мережі, що працюють з використанням протоколів [http://book.itep.ru/4/42/ipx_4211.htm IPX] / [http://book.itep.ru/4/42/spx_4212.htm SPX] (Novell), де традиційна маршрутизація не передбачена. Для підключень віддалених серверів, що знаходяться поза локальної мережі, тут використовується технологія так званих IP-тунелів. При реалізації цієї технології IPX-пакети інкапсулються в IP-дейтограми і доставляються у відповідність з протоколами TCP / IP. Процедура інкапсуляції здійснюється спеціальним драйвером (IPtunnel; використовує протокол IPXODI), який працює так, як якщо б він був драйвером апаратного мережевого інтерфейсу. При цьому необхідно модифікувати конфігураційний файл net.cfg (Див.,[http://citforum.ru/nets/semenov/4/44/www2.ncsu.edu/cc-consult/usinglwp/tunnel.shtm Наприклад]).</p> | |
| − | + | <p style="font-family: century;font-size: 14pt;color: purple"> | |
| + | Техніка IP-тунелів може виявитися іноді корисною і при адмініструванні маршрутизації, так як метрика зовнішніх протоколів маршрутизації може не враховувати пропускну спроможність каналів і деякі інші фактори, наприклад, QoS. У цьому випадку IP-дейтограми вкладаються в IP-дейтограми відправником (початок тунелю) і витягуються звідти в кінці тунелю. Кінець тунелю не обов'язково збігається з місцем призначення пакетів. Така проста схема тунелювання може породжувати деякі проблеми.</p> | ||
| − | + | [[Image:Тунель1.gif|500px|center]] | |
| − | + | ||
| − | + | <p style="font-family: century;text-align:center;font-size: 14pt;color: purple"> | |
| + | Рис.1. Схема тунелювания пакетів. </p> | ||
| − | Останнім часом техніка тунелів знайшла застосування при побудові так званих проксі-серверів, популярність яких пов'язана з можливістю помітно скоротити зовнішній (часто зарубіжний) трафік за рахунок запам'ятовування в дисковому буфері файлів, найбільш часто запитуваних клієнтами. Помітно спрощує рішення даної задачі багато сучасних маршрутизатори, які можуть відфільтровувати запити по певних портів і переадресовувати їх проксі-сервера. | + | <p style="font-family: century;font-size: 14pt;color: purple"> |
| + | Квадратними дужками відзначено вкладення пакетів. У чисельнику наводиться адреса місця призначення, в знаменнику адреса відправника. Адреса поза дужками - адреса місця призначення.</p> | ||
| + | |||
| + | <p style="font-family: century;font-size: 14pt;color: purple"> | ||
| + | З малюнка видно, що простий тунель може породити асиметричний маршрут, при якому шлях туди і назад не збігаються. Щоб такого не сталося, застосовується техніка "маскараду" (маскування). Для цього "маршрутизатор кінця тунелю" повинен витягти вкладений пакет (як це він робить - рис.1) і вкласти його в пакет з адресою місця призначення IP3, вказавши при цьому в якості відправника себе (IP3 / IP2 [IP3 / IP1]). Тоді кінцевий адресат IP3 буде посилати відгуки за адресою IP2, а не IP1. А вже маршрутизатор кінця тунелю буде пересилати їх першоджерела запиту IP1.</p> | ||
| + | |||
| + | <p style="font-family: century;font-size: 14pt;color: purple"> | ||
| + | Останнім часом техніка тунелів знайшла застосування при побудові так званих проксі-серверів, популярність яких пов'язана з можливістю помітно скоротити зовнішній (часто зарубіжний) трафік за рахунок запам'ятовування в дисковому буфері файлів, найбільш часто запитуваних клієнтами. Помітно спрощує рішення даної задачі багато сучасних маршрутизатори, які можуть відфільтровувати запити по певних портів і переадресовувати їх проксі-сервера.</p> | ||
[[Image:Тунель2.gif|500px]] | [[Image:Тунель2.gif|500px]] | ||
| − | Рис.2. Схема транспортування запитів при використанні проксі-сервера | + | <p style="font-family: century;font-size: 14pt;color: purple"> |
| + | Рис.2. Схема транспортування запитів при використанні проксі-сервера</p> | ||
| + | |||
| + | <p style="font-family: century;font-size: 14pt;color: purple"> | ||
| + | Схема з "невидимим" проксі-сервером працює таким чином. Спочатку запит надходить в маршрутизатор, там він аналізується і, якщо з'ясовується що це HTTP або FTP-запити, переадресовується проксі-сервера. Якщо запитуваний файл знаходиться в буфері сервера, замовлення клієнта задовольняється локально. В іншому випадку запит знову надсилається маршрутизатору. Запити проксі-сервера маршрутизатор переправляє в зовнішню мережу. У разі використання персональної ЕОМ в якості проксі-сервера можна її забезпечити двома мережевими інтерфейсами для прийому і посилки запитів, що зробить роботу більш ефективною. Якщо маршрутизатор не підтримує описаний режим, то при конфігурації мережевого програмного забезпечення клієнта можна явно прописати адресу проксі-сервера і всі відповідні запити підуть безпосередньо туди.</p> | ||
| − | + | <p style="font-family: century;font-size: 14pt;color: purple"> | |
| + | Тунелі широко використовуються і при передачі мультимедійних даних.</p> | ||
| − | + | <p style="font-family: century;font-size: 16pt;color: brown"> Література:</p> | |
| + | *<p style="font-family: century;font-size: 14pt;">[http://citforum.ru/nets/semenov/4/44/tun_4412.shtml Телекоммуникационные технологии Семёнов Ю.А.]</p> | ||
| + | *<p style="font-family: century;font-size: 14pt;">[https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B9%D1%82%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 IP-дейтограми]</p> | ||
| + | *<p style="font-family: century;font-size: 14pt;">[http://book.itep.ru/4/42/ipx_4211.htm Протоколи IPX]</p> | ||
| + | *<p style="font-family: century;font-size: 14pt;">[http://book.itep.ru/4/42/spx_4212.htm Протоколи SPX]</p> | ||
Поточна версія на 00:41, 5 грудня 2014
IP-тунелі
Особливість IP-протоколу (опція примусової маршрутизації) дозволяє переадресовувати IP-дейтограми певним вузлам мережі. На перший погляд ця можливість може здатися зовсім марною, адже існують механізми динамічної маршрутизації, які незрівнянно ефективніше і надійніше забезпечують обмін даними. Але тим не менш існують програми, де примусова маршрутизація на IP-рівні представляє можливості недоступні для традиційних рішень. Це насамперед мережі, що працюють з використанням протоколів IPX / SPX (Novell), де традиційна маршрутизація не передбачена. Для підключень віддалених серверів, що знаходяться поза локальної мережі, тут використовується технологія так званих IP-тунелів. При реалізації цієї технології IPX-пакети інкапсулються в IP-дейтограми і доставляються у відповідність з протоколами TCP / IP. Процедура інкапсуляції здійснюється спеціальним драйвером (IPtunnel; використовує протокол IPXODI), який працює так, як якщо б він був драйвером апаратного мережевого інтерфейсу. При цьому необхідно модифікувати конфігураційний файл net.cfg (Див.,Наприклад).
Техніка IP-тунелів може виявитися іноді корисною і при адмініструванні маршрутизації, так як метрика зовнішніх протоколів маршрутизації може не враховувати пропускну спроможність каналів і деякі інші фактори, наприклад, QoS. У цьому випадку IP-дейтограми вкладаються в IP-дейтограми відправником (початок тунелю) і витягуються звідти в кінці тунелю. Кінець тунелю не обов'язково збігається з місцем призначення пакетів. Така проста схема тунелювання може породжувати деякі проблеми.
Рис.1. Схема тунелювания пакетів.
Квадратними дужками відзначено вкладення пакетів. У чисельнику наводиться адреса місця призначення, в знаменнику адреса відправника. Адреса поза дужками - адреса місця призначення.
З малюнка видно, що простий тунель може породити асиметричний маршрут, при якому шлях туди і назад не збігаються. Щоб такого не сталося, застосовується техніка "маскараду" (маскування). Для цього "маршрутизатор кінця тунелю" повинен витягти вкладений пакет (як це він робить - рис.1) і вкласти його в пакет з адресою місця призначення IP3, вказавши при цьому в якості відправника себе (IP3 / IP2 [IP3 / IP1]). Тоді кінцевий адресат IP3 буде посилати відгуки за адресою IP2, а не IP1. А вже маршрутизатор кінця тунелю буде пересилати їх першоджерела запиту IP1.
Останнім часом техніка тунелів знайшла застосування при побудові так званих проксі-серверів, популярність яких пов'язана з можливістю помітно скоротити зовнішній (часто зарубіжний) трафік за рахунок запам'ятовування в дисковому буфері файлів, найбільш часто запитуваних клієнтами. Помітно спрощує рішення даної задачі багато сучасних маршрутизатори, які можуть відфільтровувати запити по певних портів і переадресовувати їх проксі-сервера.
Рис.2. Схема транспортування запитів при використанні проксі-сервера
Схема з "невидимим" проксі-сервером працює таким чином. Спочатку запит надходить в маршрутизатор, там він аналізується і, якщо з'ясовується що це HTTP або FTP-запити, переадресовується проксі-сервера. Якщо запитуваний файл знаходиться в буфері сервера, замовлення клієнта задовольняється локально. В іншому випадку запит знову надсилається маршрутизатору. Запити проксі-сервера маршрутизатор переправляє в зовнішню мережу. У разі використання персональної ЕОМ в якості проксі-сервера можна її забезпечити двома мережевими інтерфейсами для прийому і посилки запитів, що зробить роботу більш ефективною. Якщо маршрутизатор не підтримує описаний режим, то при конфігурації мережевого програмного забезпечення клієнта можна явно прописати адресу проксі-сервера і всі відповідні запити підуть безпосередньо туди.
Тунелі широко використовуються і при передачі мультимедійних даних.
Література:
