Локален мост на SoftEther срещу SecureNAT: кое да включите

Отворете SoftEther Manager и първото истинско решение за даден хъб не е отметка, а въпрос на топология. Локалният мост свързва този хъб с физически адаптер и оставя съществуващия сегмент да осигурява адресирането, докато SecureNAT дава на хъба собствен виртуален рутер, NAT и DHCP. Изборът между тях променя откъде идват адресите и кое устройство отговаря за тях. Да включите и двете и да се надявате, че едното ще победи, е начинът работеща лаборатория да се превърне в тема за поддръжка.

Започнете от хъба, който наистина редактирате

Manager показва дърво от сървъри и хъбове и лесно е да настроите хъба по подразбиране, докато клиентите се свързват към друг с различно име. Щракнете върху хъба, прочетете името му и потвърдете, че сесиите под него са клиентите, на които искате да служите. Тази една проверка предотвратява повечето объркване, което после се приписва на протокола.

След това решете какво му трябва на клиента от далечната страна. Споделено Ethernet поведение с broadcast и LAN услуги сочи към мост, маршрутизиран частен достъп до малък диапазон адреси сочи към SecureNAT, а изходът към интернет е решение за маршрутизация, което и двете подредби могат да понесат лошо.

Запишете отговора, преди да щракнете нещо, защото двете настройки не са взаимозаменяеми и отмяната отнема повече време от решението. Две минути писане спестяват час повторно свързване.

Какво прави локалният мост с адресирането

Локалният мост свързва хъба с физически адаптер, така че хъбът става част от този Ethernet сегмент. Клиентите получават адреси от това, което вече обслужва сегмента, а шлюзът им е рутерът на сегмента. От гледна точка на клиента той се е присъединил към офисната LAN с цялата достъпност и цялата изложеност, които това предполага.

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

Четете таблицата на мостовете от командния ред, когато графичното дърво е двусмислено. Изходът посочва адаптера, което дървото не винаги прави.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Празен списък с мостове при свързани сесии е полезна картина: клиентите са вътре във виртуалния хъб и нищо още не го разширява към сегмент.

Какво добавя SecureNAT и какво скрива

SecureNAT дава на хъба виртуален рутер, NAT функция и DHCP услуга, всички вътре в процеса SoftEther. Клиентите получават адреси от виртуалния DHCP диапазон, виртуалният рутер отговаря за шлюза по подразбиране, а трафикът, който трябва да излезе, се транслатира. Не участва физически адаптер и затова работи на хост с една мрежова карта и без конфигурация на комутатор.

Цената е, че виртуалните адреси принадлежат на хъба и на нищо друго. Машина в офисната LAN не може да маршрутизира към SecureNAT адреса на клиент без помощ, а всичко, което записва адреси на източника, вижда транслатирания адрес на хоста SoftEther. Ако правилата ви за достъп или одиторската следа зависят от реалния адрес на клиента, това е промяна в дизайна, а не подробност. Това също решава дали правило за адрес на източника изобщо ще види клиента.

Той е и DHCP сървър. Пускането му в сегмент, който вече има такъв, или мостването на този сегмент едновременно създава двама отговарящи и непредвидими leases. Ръководството третира двете функции като отделни избори точно поради тази причина.

Проверете какво обслужва хъбът в момента, преди да включите нещо друго. Всяка команда отпечатва текущото състояние, а не желаното.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Включване на едното без да счупите другото

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

Подредете промяната така, че пулът от клиенти да не се застъпва с LAN диапазона. Застъпващите се подмрежи са втората най-честа причина за тунел, който се свързва и после не достига до нищо, и са невидими, докато не сравните двата плана за адресиране един до друг.

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

Проверете шлюза и резолвера на клиента

Успешната автентикация ви казва, че данните за достъп работят и хъбът е приел сесията. Тя не казва нищо за това дали клиентът достига до нещо, защото това зависи от адреса, маската, шлюза и DNS сървъра, които е получил. Прочетете тези четири стойности на клиента, преди отново да пипате настройка на сървъра.

В Windows подробностите за адаптера показват lease и резолвера, а таблицата за маршрутизация показва дали тунелът наистина е пътят по подразбиране.

ipconfig /all
route print -4
nslookup intranet.corp.internal

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