SoftEther зад NAT: директно преминаване или релей на VPN Azure?

Динамичният DNS, преминаването през NAT и VPN Azure вършат различни задачи. Изберете пътя, преди да редактирате потребители, после потвърдете кой транспорт всъщност използва сесията.

Вашият SoftEther сървър стои зад рутер на доставчик, който не можете да промените, а клиентите все още се свързват, затова предполагате, че релей носи всичко. Дали това е вярно, зависи от това кой механизъм е свършил работата: DNS име, координиран UDP път или изходящ тунел към релей. И трите могат да дадат свързан клиент и се провалят при различни условия. Решете кой път купувате, преди да пипате потребители или хъбове.

Три механизма, три различни обещания

Динамичният DNS е именуване. Той държи име на хост насочено към променящ се адрес, за да спрат хората да гонят номера, и не прави нищо друго. Родното преминаване през NAT е координация: две крайни точки на SoftEther обменят информация и се опитват да отворят използваем UDP път през устройствата за транслация между тях. VPN Azure е релей: сървърът се свързва изходящо към услугата, а клиентите идват през име на хост в инфраструктурата на релея.

Трите се допълват, а не са версии на една функция. Едно внедряване може да използва именуване, докато връзката му всъщност зависи от преминаването или от релея.

Решавайте от клиента и от мрежата

Изборът започва от клиента, защото преминаването съществува само в родния механизъм за свързване на SoftEther. OpenVPN, L2TP/IPsec и SSTP слушатели на същия сървър не го наследяват, макар да делят един хост. Вижте какво ще стартира потребителят, после какво позволява мрежата. Корпоративна мрежа, която разрешава само TCP 443, ви тласка към релей на този порт, докато мрежа, която пропуска UDP портовете, нужни за преминаване, може да опита директен път; потвърдете и двете спрямо действителната политика за изход.

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

Потвърдете кой транспорт е избрала сесията

Състоянието на връзката е единственият честен източник за използвания път. Прочетете го на сървъра и резолвнете името на хоста, което клиентът е получил.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList показва кои сесии са свързани, а SessionGet върху една от тях съобщава типа на връзката, включително дали сесията е дошла през релея. Запис, който се резолвва към инфраструктурата на релея, ви казва, че сесията минава през трета страна, което можете да потвърдите, като блокирате този маршрут в тест. С роден клиент UDP ускорението може да отмести пътя на данните от пътя на управление, така че едно наблюдение не описва цялата сесия. Остаряло динамично DNS име след промяна на адреса и релей, който отговаря при липсващ маршрут към бекенда, са два режима на отказ, които си струва да се тестват отделно. Записвайте какво сте измерили, а не какво е предвиждал дизайнът.

Планирайте от какво зависи избраният път

Всеки път носи зависимост. Директното преминаване може да се промени след мрежов преход или ново устройство за транслация, докато релей сесия се проваля, когато услугата или достъпният ѝ порт се провалят. Свържете се отново от друга мрежа и потвърдете идентичността на сървъра, която клиентът е проверил, като задържите предишния работещ път в същия тест. После тествайте частния ресурс зад VPN, защото оторизацията, членството в хъба, назначаването на адреси и обратните маршрути остават ваша отговорност и в двата случая.

Запишете името на хоста, протокола, настройките на функцията и наблюдавания транспорт. Именно този четириделен запис позволява на следващия човек да възпроизведе работеща връзка.

Подобни статии