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

Запишіть ролі, які вже працюють

Зафіксуйте шлюз за замовчуванням, DHCP-сервер, резолвер і пристрій, на якому тримається голосова реєстрація провайдера. У цьому прикладі роутер провайдера — 10.50.0.1, новий шлюз буде на 10.50.0.2, а віддалений майданчик — 10.60.0.0/24. Ніщо в цьому плані не змінює перші три ролі, і саме в цьому сенс. Потім переконайтеся, що другий пристрій справді може завершити тунель: перегляньте протокол, очікувану пропускну здатність і чи отримує він оновлення прошивки чи пакетів. Пристрій із логотипом VPN і без шляху оновлення — це тягар, а не доповнення.

Якщо ви не можете сказати, кому належить голосова послуга, зупиніться. Заміна роутера з реєстрацією без плану відкату перетворює проєкт VPN на відмову телефонії.

Дайте новому шлюзу одну адресу й одне завдання

Зарезервуйте його LAN-адресу поза пулом DHCP, щоб він не зсунувся після перезавантаження, і не давайте йому власного маршруту за замовчуванням, якщо не хочете зробити його інтернет-шляхом. Його завдання — тримати тунель і відповідати за віддалені префікси. На хостах LAN, яким потрібен віддалений майданчик, доведіть, яким шляхом вони йдуть зараз і який потрібен після зміни; ті самі дві команди до і після — найдешевший доказ.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

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

Виберіть, кому належить маршрут віддаленого префікса

Варіант A — роутер провайдера: він тримає статичний маршрут для 10.60.0.0/24 на шлюз, і кожен хост іде, як раніше, через свій шлюз за замовчуванням. Варіант B — за хостами: лише машини, яким потрібен віддалений майданчик, отримують явний маршрут через 10.50.0.2, а все інше лишається недоторканим. A чистіший за великої кількості хостів, але зазвичай вимагає, щоб роутер провайдера приймав статичний маршрут, а деякі цього не роблять. B не потребує сприяння провайдера, але залишає обслуговування конфігурації хостів вам, тож підходить невеликому погодженому набору машин.

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

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

Забезпечте досяжну вхідну точку

Шлюзу потрібна адреса, до якої віддалений майданчик може дістатися. За роутером провайдера це означає проброс порту або запис DMZ, і обидва залежать від того, чи провайдер справді доставляє трафік. Локальний проброс не долає NAT операторського рівня на боці провайдера. Якщо провайдер не дає досяжної точки, переверніть напрямок: нехай обидва майданчики ініціюють з’єднання до вузла, який ви контролюєте. Це допустимий проєкт, але він додає третю залежність для пробросу, довіри й доступності, а динамічний DNS її не замінює.

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

Прийміть приватну послугу й голосову лінію разом

Перевірте передбачувану роботу з хоста LAN, із приватним DNS і власними обліковими даними застосунку. Маршрутизований тунель не робить віддалений перегляд схожим на локальний сегмент Ethernet, тож виявлення й розв’язання імен потребують власних домовленостей.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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

Схожі статті