SoftEther-ի լոկալ կամուրջը կամ SecureNAT-ը՝ որն է միացնել

Բացեք SoftEther Manager-ը, և hub-ի մասին առաջին իրական որոշումը վանդակ չէ, դա տոպոլոգիայի հարց է։ Լոկալ կամուրջը այդ hub-ը կապում է ֆիզիկական ադապտերի և թույլ է տալիս գոյություն ունեցող սեգմենտին ապահովել հասցեավորումը, մինչ SecureNAT-ը hub-ին տալիս է իր սեփական վիրտուալ երթուղիչը, NAT-ը և DHCP-ն։ Նրանց միջև ընտրությունը փոխում է, թե որտեղից են գալիս հասցեները և որ սարքն է պատասխանում դրանց համար։ Երկուսն էլ միացնելը և հույս ունենալ, որ մեկը կհաղթի, այն ուղին է, որով աշխատող լաբորատորիան դառնում է աջակցության թեմա։

Սկսեք այն hub-ից, որը դուք իրականում խմբագրում եք

Manager-ը ցույց է տալիս սերվերների և hub-երի ծառ, և հեշտ է կարգավորել լռելյայն hub-ը, մինչ կլիենտները միանում են այլ անունով մեկին։ Սեղմեք hub-ի վրա, կարդացեք նրա անունը և հաստատեք, որ ներքևում թվարկված սեսիաները հենց այն կլիենտներն են, որոնց ցանկանում եք սպասարկել։ Այս մեկ ստուգումը կանխում է շփոթության մեծ մասը, որը հետո վերագրվում է արձանագրությանը։

Ապա որոշեք, թե ինչ է պետք կլիենտին հեռավոր ծայրից։ Համօգտագործվող Ethernet-վարքագիծը հեռարձակմամբ և LAN ծառայություններով մատնանշում է կամուրջ, դեպի փոքր հասցեների տիրույթ ուղղորդված մասնավոր հասանելիությունը՝ SecureNAT, իսկ ինտերնետ ելքը երթուղավորման որոշում է, որը երկու դասավորություններն էլ կարող են վատ կրել։

Գրեք պատասխանը նախքան որևէ բանի սեղմելը, որովհետև այդ երկու կարգավորումները փոխարինելի չեն, և հետարկելը ավելի երկար է տևում, քան որոշումը։ Երկու րոպե գրելը խնայում է մեկ ժամ վերամիացում։

Ինչ է անում լոկալ կամուրջը հասցեավորման հետ

Լոկալ կամուրջը hub-ը կապում է ֆիզիկական ադապտերի, ուստի hub-ը դառնում է այդ Ethernet սեգմենտի մասը։ Կլիենտները հասցեներ են ստանում նրանից, ինչ արդեն սպասարկում է սեգմենտը, իսկ նրանց դարպասը սեգմենտի երթուղիչն է։ Կլիենտի տեսանկյունից այն միացել է գրասենյակի LAN-ին՝ այդ ամենով պայմանավորված ողջ հասանելիությամբ և ողջ ազդեցությամբ։

Դա նաև նշանակում է, որ կամուրջին պետք է իրական ադապտեր՝ համապատասխան դրայվերի աջակցությամբ, և ադմինիստրատորը պետք է լիազորված լինի ընդլայնելու այդ սեգմենտը։ VPN մուտքը ապացուցում է նույնականացումը, ոչ թե արտադրական VLAN-ում հոսթ տեղադրելու իրավունքը։ Ստուգեք, որ դրայվերի անունը համապատասխանում է նախատեսված ադապտերին, քանի որ սխալ պորտը կամրջելը արագ իջեցնում է սեգմենտը։ Եթե ադապտերների ցանկը դատարկ է կամ կամուրջը հաղորդում է ձախողման մասին, պատճառը սովորաբար կապված է դրայվերի կամ լիազորությունների հետ, ոչ գաղտնագրության։

Կարդացեք կամուրջների աղյուսակը հրամանի տողից, երբ գրաֆիկական ծառը երկիմաստ է։ Արդյունքը նշում է ադապտերի անունը, ինչը ծառը միշտ չէ, որ անում է։

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Միացված սեսիաներով դատարկ կամուրջների ցանկը օգտակար պատկեր է. կլիենտները վիրտուալ hub-ի ներսում են, և դեռ ոչինչ այն չի ընդլայնում սեգմենտի վրա։

Ինչ է ավելացնում SecureNAT-ը և ինչ է թաքցնում

SecureNAT-ը hub-ին տալիս է վիրտուալ երթուղիչ, NAT ֆունկցիա և DHCP ծառայություն՝ բոլորը SoftEther գործընթացի ներսում։ Կլիենտները հասցեներ են ստանում վիրտուալ DHCP տիրույթից, վիրտուալ երթուղիչը պատասխանում է լռելյայն դարպասի համար, և դուրս գալու կարիք ունեցող տրաֆիկը թարգմանվում է։ Ֆիզիկական ադապտեր ներգրավված չէ, դրա համար է այն աշխատում մեկ ցանցային քարտով և առանց անջատիչի կարգավորման հոսթի վրա։

Գինն այն է, որ վիրտուալ հասցեները պատկանում են hub-ին և ուրիշ ոչ մեկին։ Գրասենյակի LAN-ի մեքենան առանց օգնության չի կարող երթուղավորել դեպի կլիենտի SecureNAT հասցեն, և ամեն ինչ, որ գրանցում է աղբյուրի հասցեները, տեսնում է SoftEther հոսթի թարգմանված հասցեն։ Եթե ձեր մուտքի կանոնները կամ աուդիտի հետքը կախված են կլիենտի իրական հասցեից, դա նախագծի փոփոխություն է, ոչ մանրամասն։ Դա նաև որոշում է, թե արդյոք աղբյուրի հասցեի կանոնը երբևէ կտեսնի կլիենտին։

Այն նաև DHCP սերվեր է։ Այն սեգմենտում գործարկելը, որտեղ արդեն կա մեկը, կամ այդ սեգմենտը միաժամանակ կամրջելը ստեղծում է երկու պատասխանող և անկանխատեսելի վարձակալություններ։ Ձեռնարկը երկու ֆունկցիաները դիտարկում է որպես առանձին ընտրություններ հենց այդ պատճառով։

Ստուգեք, թե hub-ը հիմա ինչ է սպասարկում, նախքան ուրիշ բան միացնելը։ Յուրաքանչյուր հրաման տպում է ընթացիկ վիճակը, ոչ նախատեսվածը։

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Միացնել մեկը՝ չկոտրելով մյուսը

Ընտրեք դասավորությունը, միացրեք այն, իսկ մյուսը թողեք անջատված։ Այն hub-ը, որտեղ և՛ կամուրջը, և՛ SecureNAT-ը ակտիվ են, hub է, որն ունի նույն հարցի երկու հնարավոր պատասխան, և կլիենտը կհավատա նրան, որն առաջինը կհասնի։ Մեկից մյուսին տեղափոխվելիս անջատեք հին ֆունկցիան և վերամիացրեք կլիենտին, փոխարենը ենթադրելու, որ նոր կարգավորումը գործում է գոյություն ունեցող սեսիայի վրա։

Դասավորեք փոփոխությունն այնպես, որ կլիենտների լողավազանը չհատվի LAN տիրույթի հետ։ Հատվող ենթացանցերը թունելի երկրորդ ամենատարածված պատճառն են, որը միանում է, ապա ոչ մի տեղ չի հասնում, և դրանք անտեսանելի են, քանի դեռ չեք համեմատել երկու հասցեային պլանները կողք կողքի։

Ապա վերամիացեք կլիենտից և կարդացեք, թե ինչ է ստացել, որովհետև hub-ի պատկերացումը սեսիայի մասին կլիենտի պատկերացումը չէ իր սեփական ցանցի մասին։ Վերամիացումը թարմ վարձակալություն պարտադրելու միակ հուսալի միջոցն է։

Ստուգեք դարպասը և լուծիչը կլիենտի վրա

Հաջող նույնականացումը ձեզ ասում է, որ հավատարմագրերն աշխատում են, և hub-ը ընդունել է սեսիան։ Այն ոչինչ չի ասում այն մասին, թե արդյոք կլիենտը որևէ տեղ հասնում է, որովհետև դա կախված է ստացված հասցեից, դիմակից, դարպասից և DNS սերվերից։ Կարդացեք այդ չորս արժեքները կլիենտի վրա նախքան սերվերի կարգավորմանը նորից դիպչելը։

Windows-ում ադապտերի մանրամասները ցույց են տալիս վարձակալությունը և լուծիչը, իսկ երթուղիների աղյուսակը՝ արդյոք թունելը իսկապես լռելյայն ուղին է։

ipconfig /all
route print -4
nslookup intranet.corp.internal

Linux կլիենտում նույն տեղեկությունը գալիս է հասցեների, երթուղիների և լուծիչի ֆայլերից։ Լռելյայն երթուղին այն արժեքն է, որը որոշում է՝ տրաֆիկը ընդհանրապես դուրս է գալիս թունելով։ Եթե դարպասը մատնանշում է գրասենյակի երթուղիչին, մինչ թունելը սպասում է տրաֆիկը կրելուն, տոպոլոգիան անվամբ կամրջված է և գործնականում կոտրված։ Նախ ուղղեք հասցեների աղբյուրը, ապա նորից փորձարկեք հավելվածը, և միայն դրանից հետո մտածեք մյուս ռեժիմը փոխելու մասին։