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 перасякаецца з лакальнай падсеткай хоста або пулам іншага хаба, кліент атрымлівае адрас, які маршрутызуецца неадназначна, і кожны наступны тэст неадназначны.

Рашэнне 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 і лакальны мост — гэта розныя схемы для аднаго хаба, а хаб, якому патрэбныя абодва, — гэта хаб, якому патрэбны іншы план. Выбірайце свядома, запішыце чаму, і наступнаму чалавеку не давядзецца рэверс-інжынірыць гэта з працоўнай канфігурацыі.