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-а, јер ауторизација, чланство у чворишту, додела адреса и повратне руте у сваком случају остају ваша одговорност.

Запишите име домаћина, протокол, подешавања функције и запажени транспорт. Управо тај запис од четири дела омогућава следећој особи да репродукује радну везу.

Повезани чланци