SoftEther-ը 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-ի հետևի մասնավոր ռեսուրսը, որովհետև լիազորումը, հանգույցի անդամակցությունը, հասցեների բաշխումը և վերադարձի ուղիները ամեն դեպքում մնում են ձեր պատասխանատվությունը։

Գրեք հոսթի անունը, արձանագրությունը, գործառույթի կարգավորումները և դիտարկված տրանսպորտը։ Հենց այդ քառամաս գրառումն է, որ թույլ է տալիս հաջորդ մարդուն վերարտադրել աշխատող միացում։