Віддалений доступ чи VPN між сайтами: що підходить?

Працівник у дорозі та філія потребують різних тунелів, і неправильний вибір дає дизайн, який працює в лабораторії та відмовляє першого понеділка. Віддалений доступ з’єднує пристрій зі шлюзом. З’єднання між сайтами з’єднує два шлюзи, що представляють мережі. Контрольний список нижче визначає, який із них насправді описує вимога.

Хто встановлює з’єднання і що стоїть за ним

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

Зупиніться тут, якщо вимога полягає в тому, щоб кожна машина в одному офісі досягала іншого офісу без налаштування на кожному пристрої. Це з’єднання між сайтами, і купа входів віддаленого доступу — погана заміна.

Адресація та зворотний шлях

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

Зворотний шлях не менш важливий за вихідний. Сервер може отримати запит і все одно не мати шляху назад до мережі клієнта.

Задокументуйте, який маршрутизатор знає віддалений префікс, особливо з хмарними мережами та кількома шлюзами. Зелена піктограма тунелю не може відповісти, чи має призначення робочий зворотний шлях, і ping в одному напрямку теж не може. У віддаленому доступі шлюз зазвичай володіє маршрутом пулу; у з’єднанні між сайтами кожен проміжний маршрутизатор, що несе префікс, має погодитися. Трансляція може приховати відсутній маршрут, доки не зламається застосунок із вбудованими адресами.

Вихід в інтернет — окреме рішення

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

Повний тунель і розділений тунель — це відповіді на те питання, а не на питання віддаленого доступу проти з’єднання між сайтами. Внутрішні імена потребують відповідного DNS в обох дизайнах, бо публічний резолвер не має відповіді для приватного імені офісу. Надсилання резолвера й надсилання маршруту за замовчуванням — пов’язані налаштування, і зміна одного без іншого породжує збої, схожі на проблеми з DNS.

Звужуйте несправність за допомогою топології

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

Спершу перевірте встановлення тунелю, потім маршрути, потім дозволений трафік, потім розв’язання імен, потім вхід у застосунок і зупиніться на першому кроці, що відмовляє. ip route get 10.60.8.15 відповідає на питання маршрутизації, перш ніж ви прочитаєте бодай один журнал застосунку. Налаштування шифрування не виправляють помилку дозволу на спільний доступ до файлів, а робочий ping не доводить, що застосунок авторизовано. Фіксований порядок запобігає випадковим змінам конфігурації, які перетворюють одну несправність на три.

Насамкінець, тримайте визначення чіткими, читаючи матеріали постачальників: комерційний сервер виходу в інтернет — це інша послуга, ніж приватний шлюз компанії, і він не дає доступу до мережі цієї компанії.