Та сама підмережа на обох кінцях: зіставте віддалений LAN із вільним діапазоном

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

Два погляди на той самий хост

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

Локальні пристрої вдома зберігають свої адреси 192.168.1.x, і в цьому сенс вправи. Принтер у сусідній кімнаті залишається доступним, а офіс з'являється під діапазоном, який не конфліктує.

Порядок аргументів — це вся хитрість

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Маршрут — це те, що надсилає пакети клієнта для нового діапазону в тунель; трансляція переписує призначення по дорозі. Відповідь від 192.168.1.20 переписується назад у 10.203.41.20, щоб сокет на клієнті залишався узгодженим. Один хост працює так само з маскою повної довжини, якщо маршрут і зіставлення описують ту саму адресу.

Це зіставлення адрес, а не зіставлення портів. Дві служби на одному хості ним не розділити, а протокол, що вбудовує IP-адреси у своє корисне навантаження, все одно побачить справжні.

Зіставлення не створює зворотного шляху

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

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

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

Імена та корисні навантаження переживають трансляцію

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

Переспрямування, вбудовані URL і застосунки, що видають власну адресу в корисному навантаженні, можуть ламатися так, що жодне зіставлення пакетів це не виправить. Ставтеся до них як до проблеми застосунку і зважайте на зусилля відповідно, перш ніж обіцяти, що перенумерування не потрібне.

Три перевірки перед зобов'язанням

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

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

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