RRAS-ի VPN հաճախորդներին պետք է սեփական IPv4 լողավազան և վերադարձի ուղի

VPN հաճախորդը միանում է և ստանում հասցե, սակայն այն LAN հոսթը, որի կարիքը նա ունի, դեռ չի կարող պատասխանել նրան։ Windows Routing and Remote Access-ում VPN հաճախորդների ներքին հասցեն գալիս է լողավազանից, որը կարգավորվում է սերվերի LAN ադապտերից առանձին, և LAN կողմին անհրաժեշտ է վերադարձի երթուղի դեպի այդ լողավազանը։ Երկու փոփոխություն, ոչ մեկը, և դրանք ձախողվում են տարբեր ձևերով։ Անցեք դրանց հերթականությամբ, որպեսզի հասցեների պլանն ու վերադարձի ուղին ապացուցված լինեն նախքան հին միջակայքերի դուրսբերումը։

Ամրագրեք միջակայքը նախքան կոնսոլը բացելը

Ընտրեք նախածանց, որը չի համընկնում LAN-ի, այլ VPN միջակայքերի կամ կայք մուտքագրվող որևէ բանի հետ։ /24-ը հարմար չափ է փորձարկման համար, և առաջին օգտագործելի մասը կարելի է տալ հաճախորդներին, մինչ մնացածը ազատ մնում է աճի համար։ Գրեք այն իր նպատակի և սեփականատիրոջ հետ նախքան կոնսոլում մուտքագրելը։ Թողեք տեղ բլոկի երկու ծայրերում, որպեսզի հետագա բաժանումը չստիպի վերահամարակալել։

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

Սերվերի LAN ադապտերը չի սահմանում այս լողավազանը։ Հանրային լսողի փոփոխությունը կամ LAN-ին ադապտեր ավելացնելը բոլորովին այլ բան է անում։ Այդ պատճառով հաճախորդները կարող են միանալ և այնուամենայնիվ հասցե ստանալ սխալ տեղից։ Լողավազանը ապրում է սերվերի IPv4 հատկություններում, ոչ թե ադապտերների ցանկում։

Մեթոդի փոփոխությունը միջակայք ավելացնելը չէ

RRAS-ն ունի վերագրելու մեթոդ և միջակայքերի հավաքածու։ DHCP-ից ստատիկ լողավազանի անցումը մեթոդի փոփոխություն է։ Եվս մեկ բլոկ ավելացնելը, երբ ստատիկ լողավազանն արդեն ակտիվ է, միջակայքի փոփոխություն է։

Նախադիտեք երկու գործողություններն էլ նախքան որևէ մեկը գործարկելը, և կարդացեք, թե որն է համապատասխանում սերվերի ընթացիկ վիճակին:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Երկրորդ cmdlet-ը ձախողվում է կամ անօգտագործելի լողավազան է ստեղծում, եթե սերվերը դեռ DHCP վերագրման վրա է։ Առաջինը փոխարինում է մեթոդը՝ գոյություն ունեցող լողավազանը ընդլայնելու փոխարեն։ Նախադիտումներից ոչ մեկը ոչինչ չի կիրառում, ուստի գործարկեք համապատասխանը, ապա հաստատեք ստացված լողավազանը կոնսոլում։ Եթե վստահ չեք, թե սերվերն ինչ վիճակում է, կարդացեք վերագրման մեթոդը IPv4 հատկությունների էջում և թվարկեք կարգավորված միջակայքերը.

Get-VpnIPAddressRange

DHCP մեթոդը դատարկ միջակայքերի ցանկով նշանակում է, որ գործում է առաջին նախադիտումը։ Ստատիկ հասցեների լողավազանը գոյություն ունեցող միջակայքով նշանակում է, որ գործում է երկրորդը։

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

LAN-ին պետք է վերադարձի երթուղի

Ենթադրենք՝ LAN-ը 10.60.0.0/24 է, իսկ RRAS սերվերը՝ 10.60.0.10 դրա վրա։ Այդ LAN-ի այն հոսթը, որը պատասխանում է 10.250.50.0/24-ի հաճախորդին, ուղի է պետք դեպի լողավազանը RRAS սերվերի միջով։ Առանց այդ ուղու հարցումը հասնում է, և պատասխանը մահանում է։

Եթե հոսթի լռելյայն դարպասը այլ երթուղիչ է, այդ երթուղիչին պետք է վերադարձի երթուղին VPN նախածանցի համար։ RRAS սերվերի ստատիկ երթուղին այստեղ չի օգնում. վերադարձի ուղին պետք է գոյություն ունենա այն սարքում, որին պատկանում է LAN դարպասը, ուստի ավելացրեք այն երթուղային աղյուսակում կամ դինամիկ երթուղավորման գործընթացում՝ կախված նրանից, թե կայքն ինչ է օգտագործում։

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

Ապացուցեք նոր լողավազանը մեկ սարքում նախքան հինը դուրս բերելը

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

Անունների լուծումն արժանի է իր սեփական թեստին. IP-ով մուտքը կարող է աշխատել, մինչ հաճախորդի DNS-ը դեռ ցույց է տալիս լուծիչի, որին նա չի կարող հասնել։ LAN-ի DNS սերվերը հասանելի է միայն այն դեպքում, երբ հաճախորդն ունի ուղի դեպի այն, և սերվերն ընդունում է հարցումներ նոր միջակայքից։ Երկուսն էլ հաճախ բաց թողնված կետեր են, երբ լողավազանը տեղափոխվում է։

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

Ստուգեք արդյունքը երեք դիտարկումով

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

Հաճախորդի կողմից հաստատեք հասցեն և ուղին դեպի մեկ LAN հոսթ:

ipconfig | findstr /i "IPv4"
route print -4

LAN հոսթի կողմից հաստատեք վերադարձի ուղին և քաղաքականությունը մեկ անցումով։ Եթե ping-ը ձախողվում է, բայց հավելվածն աշխատում է, բացակայող մասը հավանաբար ICMP կանոն է, ոչ թե ուղին։ Եթե երկուսն էլ ձախողվում են, կարդացեք ուղին հոսթում նախքան VPN-ը խմբագրելը։ Գրանցեք երեք արդյունքները փոփոխության տոմսում, որպեսզի հաջորդ մարդը սկսի ապացույցներից։