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 լողավազանը համընկնում է հոսթի LAN ենթացանցի կամ մեկ այլ հանգույցի լողավազանի հետ, հաճախորդը ստանում է հասցե, որը երկիմաստորեն երթուղվում է, և յուրաքանչյուր հաջորդ թեստ անորոշ է։

Որոշում 2՝ ով է փոխանցում վիրտուալ դարպասից այն կողմ

Միացված վիրտուալ NAT-ի դեպքում սերվերը թարգմանում է հանգույցից դուրս եկող երթևեկությունը և ուղարկում այն հոսթի երթուղավորման աղյուսակով։ Դա նշանակում է, որ փոխանցման շղթան այսպիսին է՝ հաճախորդից դեպի վիրտուալ դարպաս, վիրտուալ NAT-ից դեպի հոսթի շերտ, հոսթի շերտից դեպի իր լռելյայն երթուղի։ Յուրաքանչյուր օղակ կարող է ձախողվել՝ չդիպչելով մյուսներին, և ձախողման նշանները տարբեր են։

Փորձարկեք երկրորդ որոշումը մի բանով, որ պետք է լքի հանգույցը, ոչ թե հանգույցին տեղային բանով։ Վիրտուալ դարպասին ping անելը ապացուցում է միայն առաջին օղակը և ոչ ավելին՝

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-ը և տեղական կամուրջը տարբեր ձևավորումներ են նույն հանգույցի համար, և հանգույցը, որին պետք են երկուսն էլ, այն հանգույցն է, որին պետք է այլ ծրագիր։ Ընտրեք գիտակցաբար, գրեք ինչու, և հաջորդ մարդը ստիպված չի լինի այն հակադարձ ինժեներիայով վերականգնել գործող կոնֆիգուրացիայից։

Առնչվող հոդվածներ