Երկու հանրային IP մեկ Azure VPN VM-ի վրա՝ որը ինչ է անում

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

Որոշում 1. որտեղ է ավարտվում թունելը

Azure-ի հանրային IP-ն կապված է NIC-ի մասնավոր IP կազմաձևի հետ. դա հասցե չէ, որը դուք ավելացնում եք հյուրի օպերացիոն համակարգի ներսում։ Կարդացեք քարտեզագրումը՝ փոխարենը ենթադրելու. az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'։ Ինչ մասնավոր հասցե էլ վերադարձնի այդ հարցումը, հենց այն պետք է ունենա հյուրը իրականում։

Մեկ NIC-ը կարող է կրել մի քանի IP կազմաձև, ուստի երկու հանրային հասցեները երկու NIC չեն պահանջում։ Եթե ձևավորումը իսկապես օգտագործում է երկու NIC, ապա յուրաքանչյուրը բերում է իր հյուրային երթուղիներն ու հաջորդ ցատկերը, և դուք ավելացրել եք երթուղավորման որոշում՝ փոխարենը պարզեցնելու։

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

Որոշում 2. ինչ աղբյուր է օգտագործում փոխանցված հաճախորդը

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

Նեղ SNAT կանոնը կարող է ընտրել հյուրի մասնավոր աղբյուր, բայց չի կարող գերազանցել Azure-ի հաջորդ թարգմանությանը։ Ընտրեք SNAT, երբ ձեզ անհրաժեշտ է հաշվետվողականություն յուրաքանչյուր հաճախորդի համար VM-ի ներսում. բաց թողեք այն, երբ ենթացանցի ելքային ձևավորումն արդեն ապահովում է կայուն հանրային աղբյուր, և երկրորդ թարգմանությունը միայն վիճակ կավելացնի։

Որոշում 3. որ Azure ելքային մեթոդն է հաղթում

Microsoft-ը փաստաթղթավորում էելքի առաջնահերթության կարգը. սարքին կամ դարպասին կիրառելի երթուղին առաջնահերթ է, իսկ ենթացանցի NAT Gateway կապը առաջնահերթ է համապատասխան ուղու վրա օրինակի մակարդակի հանրային IP-ի նկատմամբ։ Այդ կարգն է պատճառը, որ 10.20.0.5-ին թարգմանելը չի ապացուցում, թե կայքը կտեսնի 198.51.100.20։ Կարդացեք արդյունավետ երթուղային աղյուսակը, NAT Gateway կապակցումը և NIC-ի հանրային IP-ն միասին, նախքան ելքի ձևավորումը ընդունելը։

ՊահեքAzure NIC-ի փոխանցման կարգավորումըառանձին Linux-ի փոխանցումից։ Ամպային դրոշը թույլատրում է փաթեթներ, որոնց աղբյուրը կամ նպատակակետը NIC-ին վերագրված չէ. այն չի միացնում net.ipv4.ip_forward-ը, և հյուրի կարգավորումը ամպային թույլտվություն չի տալիս։

Թունելի սոքեթն ունի իր աղբյուրի որոշումը

WireGuard-ի Address-ը wg-quick-ի ներքո հասցե է վերագրում WireGuard ինտերֆեյսին. դա արտաքին UDP կապակցման հրահանգ չէ։ Գաղտնագրված սոքեթի աղբյուրը հետևում է երթուղային աղյուսակին, ուստի քաղաքականության երթուղին կամ երկրորդ կանխադրվածը կարող է տեղափոխել այն՝ չդիպչելով ինտերֆեյսի հասցեին։OpenVPN-ի local տարբերակը և UDP multihome-ը վարվում են նույն կերպ. դրանք վերաբերում են լսողին և նրա պատասխաններին, ոչ թե յուրաքանչյուր փոխանցված հաճախորդի ինտերնետ աղբյուրին։

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

Ինչ ընդունել և ինչ հերթականությամբ

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

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