Една и съща подмрежа от двете страни: съпоставете отдалечената 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. Трето, потвърдете, че локалният рутер и отдалеченият ресурс остават различими от клиента, тъй като това беше първоначалната цел.

Ако клиентът не може да извърши транслацията, поискайте помощ от страната на шлюза или приемете преномериране. Добавянето на още маршрути за същия адрес не е дизайн.