NAT VPN սերվերո՞ւմ, թե՞ երթուղիչում։ Երկուսն էլ կարող են աշխատել

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

Առասպել. հաճախորդի երթուղին կառուցում է ելքը

Հարկադիր թունելավորումը հաճախորդի կողմի քաղաքականություն է. այն որոշում է, որ տրաֆիկը գնում է VPN ադապտեր, այլ ոչ թե ֆիզիկական։ Microsoft-ի VPN երթուղավորման փաստաթղթերը նկարագրում են այդ բաժանումն ու հարկադրական վարքը, և սա հայտարարություն է հաճախորդի երթուղիների աղյուսակի մասին, ոչ թե սերվերի փոխանցման կանոնների։ Հաճախորդի տեսանկյունից թունելը այն տեղն է, որտեղ ապրում է ինտերնետը. դարպասի տեսանկյունից փաթեթը եկել է հասցեից, որի մասին վերևում ոչ ոք երբեք չի լսել։ Ոչ մի կողմ առանձին սխալ կարգավորված չէ, և դրա համար էլ ձախողումը լապտոպի մոտ գտնվող մարդուն թվում է կոտրված սերվեր։

Այդ անհամապատասխանությունը հենց այն ամբողջ խնդիրն է, որը լուծում է այս հոդվածի մնացած մասը։ Ինչ-որ բան պետք է հաճախորդի մասնավոր հասցեն դարձնի վերադարձելի, և ընտրությունը այն է, թե որտեղ։

Նախ գծեք պատասխանի ուղին

Գրեք ուղին իրական հասցեներով, նախքան որևէ կարգավորման դիպչելը, և նշեք դրա վրա թարգմանության երկու հնարավոր կետերը։ Այս լաբորատորիան օգտագործում է 10.70.0.0/24 VPN լողավազան մեկ հաճախորդով 10.70.0.37 հասցեում, սերվերի LAN հասցեն 172.16.40.10, երթուղիչ 172.16.40.1 հասցեում և հանրային ելք 203.0.113.40 հասցեում։

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

Տարբերակ A. թարգմանություն VPN սերվերում

Այստեղ սերվերը թարգմանում է հաճախորդի աղբյուրը իր սեփական LAN հասցեի, նախքան փաթեթը երթուղիչին հանձնելը, և երթուղիչը ելքի ճանապարհին կիրառում է իր սովորական թարգմանությունը։ Պատասխանի ժամանակ երթուղիչի քարտեզագրումը վերականգնում է սերվերի հասցեն, իսկ սերվերի քարտեզագրումը՝ հաճախորդի հասցեն։ Հաջորդականությամբ երկու վիճակով թարգմանություն նորմալ և աշխատունակ է, պայմանով, որ երկուսն էլ գրանցվեն. երթուղիչը երբեք լողավազան տանող երթուղու կարիք չունի, և դա է այս կարգավորման գրավչությունը։

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Օգտագործեք այս ընթերցումները՝ տեսնելու, թե ինչ արդեն ունի սերվերը, փոխարեն ենթադրելու, որ NAT կա։ Բլոգից պատճենված Linux masquerade կանոնը Windows կարգավորում չէ, և VPN լսողի համար հոսթի հրապարակի թույլտվությունը նույն քաղաքականությունը չէ, ինչ հաճախորդի հարցումն առաջ փոխանցելու թույլտվությունը։ Հաստատեք սերվերի փոխանցման դերը նրա սեփական կառավարման մակերեսից, ապա թարգմանությունը դիտեք առանձին, որովհետև երկուսը հաճախ միացվում են տեղակայման տարբեր մասերի կողմից։

Տարբերակ B. լողավազանը երթուղիչ տանելը

Երկրորդ կարգավորման մեջ սերվերը փոխանցում է հաճախորդի իրական աղբյուրի հասցեն, և երթուղիչը թարգմանում է այն։ Սա հաճախորդների լողավազանը տեսանելի է պահում եզրում, ինչը օգնում է, եթե երթուղիչը հենց այն տեղն է, որտեղ ապրում են տրաֆիկի քաղաքականությունը, գրանցումը կամ ստուգումը։ Սա նաև նշանակում է, որ երթուղիչին պետք է վերադարձի երթուղի 10.70.0.0/24-ի համար, որը ցույց է տալիս 172.16.40.10-ին, գումարած ինտերնետի քաղաքականություն, որն իսկապես ներառում է այդ նախածանցը. LAN ենթացանցի համար գրված կանոնը լուռ չի տարածվում լողավազանի վրա։

Ընտրեք սա, երբ եզրային սարքը քաղաքականության նախատեսված տերն է և կարող է ընդունել ևս մեկ նախածանց իր երթուղավորման և թարգմանության աղյուսակներում։ Ընտրեք սերվերի կողմի թարգմանությունը, երբ լողավազանը պետք է մնա անտեսանելի վերևում, և երթուղիչը չի կառավարվում նույն թիմի կողմից։ Ոչ մի տարբերակ չի բխում հաճախորդի որևէ նշիչից, և ոչ մեկը ընդհանուր առմամբ ավելի ապահով չէ. նրանք տեսանելիությունն ու սպասարկումը դնում են տարբեր տեղերում։

Դարձրեք DNS-ը, IPv6-ը և ընդունումը բացահայտ

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

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

Ընդունման համար հետևեք մեկ թույլատրված հաճախորդի հարցմանը և պատասխանին երկու սահմաններով, և գրեք, թե յուրաքանչյուր սահման այդ պահին ինչ հասցե պետք է տեսնի։ Հենց այդ գրառումն է հաջորդ լողավազանի փոփոխությունը դարձնում հինգ րոպեանոց խմբագրում՝ բացակա վերադարձի երթուղու տիրոջ մասին վեճի փոխարեն։ Պահեք գրառումը հաճախորդի պրոֆիլի հետ, ոչ թե տոմսի մեջ, որովհետև պրոֆիլն այն է, ինչ հաջորդ ինժեները կգտնի առաջինը։