SoftEther SecureNAT: DHCP и NAT са две отделни решения

SecureNAT е една отметка, която включва две услуги, и точно оттам идва по-голямата част от объркването около него. Виртуален DHCP сървър дава на клиента адрес, маска, шлюз и често резолвер. Виртуален NAT препраща пакети през този шлюз, използвайки собствения мрежов стек на хост сървъра. Те стоят една до друга в конфигурацията и се провалят независимо: клиент може да има безупречен наем и никакъв работещ път, или работещ път с настройки, сочещи към грешен резолвер. Проверете ги като две решения и диагнозата става кратка.

Две услуги зад една отметка

Страната на виртуалния DHCP отговаря на въпрос за конфигурацията: какви настройки получава този клиент вътре в този виртуален хъб. Страната на виртуалния NAT отговаря на въпрос за препращането: когато клиент изпрати пакет до адрес извън хъба, сървърът превежда ли го и го препраща. Първото е местно за хъба и не се нуждае от мрежа нагоре. Второто зависи изцяло от хоста.

Виртуалният интерфейс на хоста принадлежи на първото решение, не на второто. Неговият адрес, често нещо като 192.168.30.1 по подразбиране, е шлюзът, който DHCP услугата предлага. Това не е публичният адрес за слушане на сървъра и бъркането на двете създава правила за защитна стена и клиентски настройки, насочени към машина, която не съществува в тази мрежа.

Решение 1: кой доставя адреса

Ако виртуалният DHCP е включен, клиентите трябва да получат наем в пула, който сте настроили, с виртуалния интерфейс на хоста като шлюз и с резолвера, който сте подали. Разглеждайте наема, а не статусния текст на клиента, защото «свързано» описва тунела, а не назначаването на адрес:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

Припокриващите се пулове също са тук. Ако пулът на виртуалния DHCP се припокрива с LAN подмрежата на хоста или с пула на друг хъб, клиентът получава адрес, който се маршрутизира двусмислено, и всеки следващ тест е неубедителен.

Решение 2: кой препраща отвъд виртуалния шлюз

С включен виртуален NAT изходящият трафик от хъба се превежда от сървъра и се изпраща през таблицата за маршрутизация на хоста. Това означава, че веригата на препращане е: клиент към виртуален шлюз, виртуален NAT към стека на хоста, стекът на хоста към маршрута си по подразбиране. Всяка връзка може да се провали, без да засяга другите, и подписите на отказа се различават.

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

Собственият път на хоста е трето нещо

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

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

Семействата адреси заслужават собствена проверка. Работещ пример за IPv4 DHCP не доказва, че в вашата сборка присъства всяка възможност на IPv6, затова прочетете ръководството за версията, която действително пускате, преди да обещавате поведение с двоен стек. Разделът за SecureNAT в ръководството обхваща функциите на виртуалния NAT и DHCP за текущото издание.

Проверете всяко решение със собствен тест

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

След това запишете разделението в бележката за дизайна: кой компонент доставя адреса, кой компонент препраща и през кой интерфейс на хоста трафикът излиза. Когато рестарт промени поведението, тази бележка ви казва кое от трите да проверите, вместо да рестартирате всичко и да се надявате симптомът да се премести.

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