NAT артындагы SoftEther: түз өтүүбү же 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 аты жана backend жолу жок болгондо жооп берген реле — өзүнчө сыноого татыктуу эки бузулуу режими. Дизайн ниет кылганды эмес, өлчөгөнүңүздү жазыңыз.

Тандалган жол эмнеге көз каранды экенин пландаңыз

Ар бир жол көз карандылыкты алып жүрөт. Түз өтүү тармактык өтүүдөн же жаңы которуу түзмөгүнөн кийин өзгөрүшү мүмкүн, ал эми реле сессиясы кызмат же анын жеткиликтүү порту иштебей калганда иштебейт. Башка тармактан кайра туташып, кардар текшерген сервер идентификаторун ырастаңыз, мурун иштеген жолду ошол эле сыноодо кармаңыз. Анан VPN артындагы жеке ресурсту сынаңыз, анткени авторизация, хаб мүчөлүгү, дарек бөлүштүрүү жана кайтаруу маршруттары кандай болсо да сиздин жоопкерчилигиңизде калат.

Хост атын, протоколду, функция жөндөөлөрүн жана байкалган транспортту жазып алыңыз. Ошол төрт бөлүктүү жазуу кийинки адамга иштеген туташууну кайра жаратууга мүмкүндүк берет.

Тектеш макалалар