5.1.5.1.Типи тунелів

Тунелі можуть створюватися різним чином.

• Добровільні тунелі. Комп’ютер користувача або клієнта може вислати VPN-запит для конфігурування і створення добровільного тунелю. У цьому випадку комп’ютер користувача є кінцевим пунктом тунелю і діє як клієнт тунелю.

• Вимушені тунелі. Сервер доступу через комутовані канали, оснащений VPN, конфігурує і створює вимушений тунель. При цьому комп’ютер користувача не є кінцевим пунктом тунелю; ним є інший пристрій – віддалений сервер доступу, який діє як клієнт тунелю і розташований між комп’ютером користувача і тунельним сервером.

Добровільні тунелі більш популярні. Нижче кожен із цих типів тунелів описаний більш детально.

5.1.5.2.Добровільні тунелі

Добровільний тунель з’являється у тому випадку, коли робоча станція або сервер раутінгу використовує програмне забезпечення тунельного клієнта для створення віртуального сполучення до доцільового тунельного сервера. Для здійснення цього на комп’ютері клієнта повинен бути встановлений відповідний тунельний протокол. Для протоколів, які тут розглядаються, добровільні тунелі потребують IP-сполучення (через LAN або комутований канал). Для комутованого каналу клієнт повинен встановити сполучення до об’єднання мереж, перш ніж він може встановити тунель. Це найбільш поширений випадок. Найкращим прикладом є користувач Internet через комутований канал, який повинен викликати Internet-провайдера і встановити Internet-сполучення, перш ніж буде створений тунель через Internet. Для комп’ютера, під’єднаного до локальної мережі, клієнт завжди має сполучення з об'єднанням мереж, яке забезпечує раутінг інкапсульованого корисного навантаження до вибраного тунельного сервера LAN. Це може бути у випадку, коли клієнт корпоративної LAN ініціює тунель, щоб досягнути приватну або невидиму підмережу у тій самій LAN.

Поширене непорозуміння, що віртуальні приватні мережі вимагають сполучення саме через комутовані канали. У дійсності вимагається лише взаємодія мереж на рівні IP. Окремі комп’ютери, наприклад, домашні, використовують сполучення через комутовані канали до Internet для встановлення IP-транспорту. Це вступний крок у підготовці до створення тунелю, а не частина самого тунельного протоколу.

5.1.5.3.Вимушені тунелі

Певна кількість виробників, які торгують серверами доступу через комутовані канали, впровадили до них здатність створення тунелю від імені клієнта комутованого каналу. Комп’ютер або мережевий пристрій, який забезпечує тунель для комп’ютера клієнта, відомий під назвами Front End Processor (FEP) для PPTP, L2TP Assess Concentrator (LAC) для L2TP або IP Security Gateway для IPSec. Тут термін FEP вживається для опису функційних властивостей незалежно від протоколу тунелювання.

Для здійснення своїх функцій FEP повинен мати встановлений відповідний тунельний протокол і бути здатним до створення тунелю при під’єднанні комп’ютера клієнта. Для прикладу Internet, комп’ютер клієнта поміщає виклик комутованого сполучення у сервер мережевого доступу ISP, оснащений можливістю тунелювання. Така конфігурація відома як “вимушене тунелювання”, бо клієнт змушений використовувати тунель, утворений FEP. Як тільки початкове з’єднання встановлене, мережевий трафік до і від клієнта автоматично висилається через тунель. При вимушеному тунелюванні комп’ютер клієнта здійснює звичайне PPP-сполучення і коли клієнт викликає сервер мережевого доступу, то тунель встановлюється і трафік автоматично маршрутується через тунель. FEP може бути сконфігурований для тунелювання всіх клієнтів комутованих каналів до визначеного тунельного сервера. В іншому випадку FEP може тунелювати індивідуальних клієнтів, базуючись на імені користувача або на призначенні.

Р ис. . Вимушене тунелювання.

На відміну від окремих тунелів, утворених добровільно кожним клієнтом, тунель між FEP і тунельним сервером може спільно використовуватися багатьма клієнтами комутованих каналів. Коли другий клієнт викликає сервер доступу (FEP), для досягнення призначення, до якого тунель вже існує, то не потрібно знову створювати тунель. Замість цього трафік даних від нового клієнта переноситься через чинний тунель. Оскільки можливі декілька клієнтів в одному тунелі, то тунель не закривається доти, доки останній користувач не від’єднається від тунелю.

Адресація та раутінг у VPN

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

VPN-сполучення із віддаленим доступом

Для сполучення VPN із віддаленим доступом комп’ютер створює сполучення з віддаленим доступом до сервера VPN. Протягом процесу сполучення VPN-сервер призначає IP-адресу для VPN-клієнта віддаленого доступу і змінює маршрут за замовчуванням до віддаленого клієнта так, щоб відповідний трафік висилався через віртуальний інтерфейс.

IP-адреси і VPN-клієнт із доступом через комутовані канали.

Для VPN-клієнта із доступом через комутовані канали, який з’єднується з Internet перед створенням VPN-сполучення з VPN-сервером у Internet, виділяються дві IP-адреси:

• коли створюється PPP-сполучення, то IPCP-узгодження із сервером мережевого доступу ISP призначає публічну IP-адресу;

• коли створюється VPN-сполучення, то IPCP-узгодження з VPN-сервером призначає IP-адресу в intranet; ця адреса, призначена VPN-сервером, може бути публічною або приватною, залежно від того, від кого організація впровадила публічну або приватну адресацію для свого intranet.

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

Тунельовані дані, які висилаються через VPN, заадресовані від адрес джерел, призначених VPN-клієнтам VPN-сервером, до intranet-адрес призначення. Зовнішній IP-заголовок заадресований між IP-адресою VPN-клієнта, виділеною ISP, і публічною адресою VPN-сервера. Оскільки раутери в Internet обробляють тільки зовнішній IP-заголовок, то раутери Internet пересилають тунельовані дані до публічних адрес VPN-серверів. Прклад адресації для клієнта комутованих каналів показаний на рис. , де організація використовує приватні адреси в intranet і тунельовані дані – це IP-данограми.

Р ис. . Публічні та приватні адреси в тунельованих даних PPTP.

Маршрути за замовчуванням і клієнти комутованих каналів.

Коли типовий клієнт комутованих каналів викликає ISP, то він приймає публічну IP-адресу від NAS ISP. Адреса шлюзу за замовчуванням не виділяється як частина процесу узгодження IPCP. Тому для досягнння всіх Internet-адрес клієнт комутованих каналів додає маршрут за замовчуванням до своєї таблиці раутінгу, використовуючи інтерфейс комутованого каналу, сполученого з ISP. У результаті клієнт може пересилати IP-данограми до NAS ISP, звідки вони маршрутуються до свого Internet-призначення. Для клієнтів комутованих каналів без інших TCP/IP-інтерфейсів це оголошена поведінка, однак вона може викликати плутанину для клієнтів комутованих каналів, які мають чинне сполучення з intranet через LAN. У цьому сценарії маршрут за замовчуванням завжди існує, вказючи локальний раутер intranet. Коли клієнт комутованих каналів створює сполучення із своїм ISP, то початковий маршрут за замовчуванням залишається в таблиці раутінгу, але його метрика збільшується. Новий маршрут за замовчуванням додається із меншим значенням метрики через сполучення з ISP. Внаслідок цього intranet-розміщення, які не є мережами, безпосередньо під’єднаними до клієнта комутованих каналів, недосяжні протягом тривання сполучення до ISP. Якщо новий маршрут за замовчуванням не створений, то всі intranet-розміщення досяжні, але Internet-розміщення – ні.

Щоб досягнути сполучності як з intranet-, так і з Internet-розміщеннями, коли ISP-сполучення активне, слід залишити опцію Use default gateway для віддаленої мережі і додати маршрути intranet до таблиці раутінгу клієнта комутованих каналів. Маршрути intranet можна додати через постійні статичні маршрути з використанням утиліти route, або, якщо як протокол раутінгу intranet вживається RIPv1, то можна використати Route Listening Service для прослуховування трафіку раутінгу і динамічного додавання маршрутів intranet. При під’єднанні до ISP всі intranet- та Internet-розміщення досяжні із використанням маршрутів за замовчуванням.

Маршрути за замовчуванням і віртуальні приватні мережі через Internet.

Коли клієнт комутованих каналів викликає ISP, то він додає маршрут за замовчуванням, використовуючи сполучення до ISP, як це показано на рис. .

Рис. Маршрути за замовчуванням при виклику ISP через комутовані канали.

Від цього пункту він може досягнути всі Internet-адреси через раутер в NAS ISP.

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

Рис. . Маршрути за замовчуванням при ініціюванні VPN.

Як у випадку сполучення клієнта комутованих каналів з Internet, коли клієнт, використовуючи добровільний тунель, створює VPN-сполучення до приватного intranet через Internet, наступає одна із таких подій:

• Internet-розміщення досяжні, а intranet-розміщення недосяжні, коли VPN-сполученя неактивне;

• Internet -розміщення недосяжні, а intranet-розміщення досяжні, коли VPN-сполученя активне.

Для більшості VPN-клієнтів, сполучених через Internet, така поведінка не створює проблем, бо вони звичайно використовують одну із intranet- або Internet-комунікацій, а не обидві. Для VPN-клієнтів, які хочуть одночасно мати доступ як до intranet-, так і до Internet-ресурсів, розв’язання залежить від способу IP-адресації в intranet. У всіх випадках об’єкт VPN-сполучення конфігурується так, що він не додає шлюзу за замовчуванням. Оли VPN-сполучення створене, маршрут за замовчуванням продовжує вказувати на NAS ISP, дозволяючи доступ до всіх адрес Internet.

Базуючись на типі intranet-адресації, яка вживається, можна отримати доступ до intranet- або Internet-ресурсів таким чином:

• Публічні адреси. Додати статичні постійні маршрути до ідентифікаторів публічних мереж в intranet, використовуючи IP-адресу віртуального інтерфейсу VPN-сервера як IP-адресу шлюзу.

• Приватні адреси. Додати статичні постійні маршрути до ідентифікаторів приватних мереж в intranet, використовуючи IP-адресу віртуального інтерфейсу VPN-сервера як IP-адресу шлюзу.

• Суміщені або нелегальні адреси. Якщо в intranet використовуються суміщені або нелегальні адреси (ідентифікатори IP-мережі не є приватними і не зареєстровані в Internet Network Information Center (InterNIC) або не отримані від ISP), то ці IP-адреси можуть бути здубльовані публічними адресами в Internet. Якщо статичні постійні маршрути додані VPN-клієнту для суміщення ідентифікаторів мережі в intranet, то розміщення в Internet для суміщених адрес недосяжні.

У кожному із цих випадків статичні постійні маршрути для мережевих ідентифікаторів з intranet необхідно додати до VPN-клієнта. Коли постійні маршрути додані, то вони зберігаються в реєстрі. У Windows NT 4.0 та Windows 2000 постійні маршрути тепер не додаються до IP-таблиці раутінгу (та невидимі з командою route print для Windows 2000), доки IP-адреса шлюзу досяжна. IP-адреса шлюзу стає досяжною, коли встановлене VPN-сполучення.

Для кожного маршруту слід ввести таку команду для Windows 2000:

ROUTE ADD <intranet Network ID> <IP address of VPN server’s virtual interface> -p

IP-адреса шлюза в команді route для кожного intranet-маршруту – це IP-адреса, призначена віртуальному інтерфейсу VPN-сервера, а не IP-адреса Internet-інтерфейсу VPN-сервера.

У всіх цих випадках слід дуже старанно додавати маршрути, щоб приватний трафік intranet був пересланий через VPN-сполучення, а не через PPP-сполучення до ISP. Якщо додані неправильні маршрути, то трафік, який слід було вислати через VPN у зашифрованій формі, буде пересилатися незашифрованим через Internet. Наприклад, якщо intranet використовує публічний ідентифікатор мережі 207.46.130.0/24 (маска підмережі 255.255.255.0) і помилково додано постійний статичний маршрут для 207.46.131.0/24, то весь трафік до intranet-мережі 207.46.130.0/24 буде вислано через Internet відкритим текстом.

VPN-сполучення раутер-раутер

Для VPN раутер-раутер інтерфейс раутінгу, який вживається для висилання пакетів - це інтерфейс через комутовані канали на вимогу, який конфігурується таким чином:

• у таблиці General вказати ім’я госта або IP-адресу VPN-сервера;

• у таблиці Security вибрати або Secure my password and Data, або Custom;

• у таблиці Networking вибрати відповідний тип сервера і протоколи, які будуть маршрутовані. Якщо тип сервера встановлено в Automatic, то спочатку слід спробувати сполучення L2TP через IPSec, а потім сполучення PPTP;

• У Interface credentials (мандати інтерфейсів) ввести ім’я користувача, пароль і доменне ім’я, яке вживається для верифікації раутера, що здійснює виклик.

Створення інтерфейсів через комутовані канали на вимогу автоматизоване через Demand-Dial Interface Wizard. Імена інтерфейсів через комутовані канали на вимогу і мандати раутера, що здійснює виклик, можуть потребувати правильного узгодження, щоб досягнути VPN-сполучення раутер-раутер.

Тимчасові або постійні віртуальні приватні мережі раутер-раутер.

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

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

Віртуальні приватні мережі з використанням сполучень через комутовані канали з ISP.

Якщо VPN-сервер і VPN-клієнт безпосередньо сполучені з Internet через постійний WAN-зв’язокЮ наприклад, через канал E1 або Frame Relay, то VPN-сполучення може бути постійним і чинним 24 години на добу. Однак, коли постійний WAN-зв’язок неможливий або непрактичний, то можна сконфігурувати VPN-сполучення на вимогу, використовуючи доступ через комутовані канали до ISP. VPN-сполучення раутер-раутер на вимогу із використанням сполучення до iSP через комутовані канали має два інтерфейси:

• інтерфейс виклику на вимогу для виклику ISP;

• інтерфейс виклику на вимогу для VPN-сполучення раутер-раутер.

Виклик на вимогу VPN-сполучення раутер-раутер автоматично здійснюється, коли трафік, який пересилається крізь VPN-сполучення, приймається раутером у віддаленому офісі.Наприклад, якщо приймається пакет, який повинен маршрутуватися до центрального офісу організації, то раутер віддаленого офісу спочатку використовує зв’язок через комутовані канали, щоб з’єднатися з локальним ISP. Коли Internet-сполучення встановлене, то раутер віддаленого офісу як VPN-клієнт створює VPN-сполучення раутер-раутер з раутером центрального офісу – VPN-сервером.

Щоб сконфігурувати таке сполучення, у раутері віддаленого офісу необхідно:

• створити інтерфейс виклику на вимогу для Internet-сполучення, сконфігурованого для відповідного обладнання (модему або пристрою ISDN), телефонного номера локального ISP та імені користувача і паролю, які вживаються для доступу до Internet;

• створити інтерфейс виклику на вимогу для VPN-сполучення раутер-раутер із раутером центрального офісу, сконфігурованого для PPTP або L2TP, IP-адреси або імені госта інтерфесу VPN-сервера в центральному офісі для доступу до Internet, імені користувача та паролю, які повинні бути верифіковані VPN-сервером. Ім’я користувача повинне повинне бути узгоджене з іменем інтерфейсу виклику на вимогу у VPN-сервері центрального офісу;

• створити статичний маршрут госта для IP-адреси Internet-інтерфейсу VPN-сервера, який використовує інтерфейс виклику на вимогу для виклику локального ISP.

• створити статичний маршрут або маршрути для ідентифікаторів IP-мережі intranet організації, який використовує VPN-інтерфейс виклику на вимогу.

Щоб сконфігурувати раутер центрального офісу, необхідно:

• створити інтерфейс виклику на вимогу для VPN-сполучення з віддаленим офісом, сконфігурованим для VPN-пристрою (порт PPTP або L2TP). Інтерфейс виклику на вимогу повинен мати те ж ім’я, що й ім’я користувача в мандаті автентифікації, який вживається длястворення VPN-сполучення раутером віддаленого офісу;

• створити статичний маршрут або маршрути для ідентифікатора IP-мережі віддаленого офісу, який використовує VPN-інтерфейс виклику на вимогу.

VPN-сполучення раутер-раутер автоматично ініціюється раутером віддаленого офісу з таким процесом:

• Пакети, призначені до розташування мережевого габа організації від користувача у віддаленому офісі, пересилаються користувачем до раутера віддаленого офісу.

• Раутер віддаленого офісу перевіряє свою таблицю раутінгу і знаходить маршрут до ідентифікатора intranet організації, який використовує VPN-інтерфейс виклику на вимогу.

• Раутер віддаленого офісу перевіряє стан VPN-інтерфейсу виклику на вимогу і встановлює, що він є у від’єднаному стані.

• Раутер віддаленого офісу відновлює конфігурацію VPN-інтерфейсу виклику на вимогу.

• Базуючись на конфігурації VPN-інтерфейсу виклику на вимогу, раутер віддаленого офісу пробує ініціювати VPN-сполучення раутер-раутер за IP-адресою VPN-сервера в Internet.

• Для встановлення VPN мусить бути встановлене або TCP/IP-сполучення (з використанням PPTP), або здійснене узгодження IPSec із VPN-сервером. Створюється пакет встановлення VPN.

• Для пересилання пакету встановлення VPN до раутера організації раутер віддаленого офісу перевіряє свою таблицю раутінгу і знаходить маршрут госта, який вживається для ISP-інтерфейсу виклику на вимогу.

• Раутер віддаленого офісу перевіряє стан ISP-інтерфейсу виклику на вимогу і знаходить його у від’єднаному стані.

• Раутер віддаленого офісу відновлює конфігурацію ISP-інтерфейсу виклику на вимогу.

• Базуючись на конфігурації ISP-інтерфейсу виклику на вимогу, раутер віддаленого офісу використовує модем або ISDN-адаптер для виклику і встановлення сполучення із своїм локальним ISP.

• Коли сполучення із ISP встановлене, то раутер віддаленого офісу висилає пакет встановлення VPN до раутера центрального офісу організації.

• VPN узгоджується між раутерами віддаленого офісу і центрального офісу організації.Раутер віддаленого офісу як частину узгодження висилає мандат автентифікації, який верифікується раутером центрального офісу.

• Раутер центрального офісу перевіряє свої інтерфейси виклику на вимогу і знаходить узгоджений із іменем користувача, висланим для автентифікації, і встановлює інтерфейс у стан з’єднання.

• Раутер віддаленого офісу пересилає пакет через VPN і VPN-сервер пересилає пакет до потрібного intranet-розташування.