Ինչու Azure Point-to-Site VPN-ը չի փոխում ձեր հանրային IP-ն
Point-to-site թունելը տեղափոխում է միայն վիրտուալ ցանցի երթուղիները, ուստի ձեր հանրային IP-ն մնում է տեղական, քանի դեռ հարկադիր թունելավորումը և firewall-ի SNAT-ը ելքը չեն տեղափոխում Azure։
Ես միացնում եմ Azure VPN հաճախորդը Windows նոթբուքի վրա, բացում եմ հասցեի արձագանքման էջ և տեսնում եմ նույն հանրային հասցեն, որը տվել էր իմ տնային երթուղիչը։ Մինչ այդ 10.20.0.4-ի jump box-ը պատասխանում է, և մասնավոր վերջնակետի անունը լուծվում է, ուստի թունելը կոտրված չէ։ Point-to-site դարպասը անում է հենց այն, ինչ ասում է իր լռելյայն կարգավորումը՝ տեղափոխում է մասնավոր նախածանցները և մնացած ամեն ինչ թողնում տեղական կապի վրա։ Azure-ին պատկանող ելքային հասցե ստանալը երթուղավորման ձևավորման փոփոխություն է, ոչ թե վերանորոգում։
Ինչ է դարպասը հայտարարում լռելյայն
Դարպասը երթուղիներ է ուղարկում վիրտուալ ցանցի հասցեային տարածության, ինչպես նաև զուգակցված ցանցերի համար, որտեղ թույլատրված է դարպասի տարանցումը, և site-to-site կապով կամ BGP-ով սովորած տեղական նախածանցների համար։ Այդ հավաքածուում 0.0.0.0/0 չկա։ Ձեր օպերացիոն համակարգը պահում է իր լռելյայն երթուղին Wi-Fi-ի կամ Ethernet-ի վրա, ուստի հանրային API-ի ուղղությամբ փաթեթը երբեք չի մտնում թունել։
Այն հասցեն, որը հաճախորդը ստանում է թունելի ներսում, point-to-site լողավազանից մասնավոր վարձակալություն է։ Այն նույնականացնում է հաճախորդին VNet-ի ռեսուրսների համար. դա ինտերնետի տեսանելի հասցե չէ, և երբեք չի հայտնվի որպես SaaS API-ին ուղղված ելքային հարցման աղբյուր։ Այդ վարձակալության շուրջ կառուցված allowlist գրառումը չի կարող աշխատել, որքան էլ սպասեք, որ այն հայտնվի մատակարարի մատյաններում։
Բաժանված թունելը և հարկադիր թունելավորումը կողք կողքի
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Միայն երկրորդ տողն է փոխում այն հասցեն, որը տեսնում է հեռավոր ծառայությունը։ Այդ աղյուսակում մնացած ամեն ինչ ծախս և գործառնական մակերես է, որը դուք ընդունում եք, երբ ելքը պետք է ստուգվի կամ թարգմանվի Azure-ի ներսում։ Եթե ինչ-որ մեկը խնդրում է փոխել հանրային IP-ն, նա ուզում է ամբողջ աջ սյունակը, ոչ թե հաճախորդի փոքր ճշգրտում։
Մինչ որևէ բան վերակառուցելը արժե անվանել մեկ միջանկյալ տարբերակ։ VNet-ի ներսում proxy կամ դարպաս VM-ը ձեզ տալիս է վերահսկվող աղբյուրի հասցե այն հավելվածների համար, որոնք կարելի է ուղղել դեպի այն, առանց հաճախորդի լռելյայն երթուղին տեղափոխելու։ Սա սովորական զննարկումը պահում է տեղական և դեռ բավարարում է գործընկերոջը, որը միայն մեկ API կանչի կարիք ունի Azure-ից։ Այն ձախողվում է, երբ պահանջը իսկապես վերաբերում է ամբողջ երթևեկությանը, քանի որ ամեն ինչ, որ անտեսում է proxy կարգավորումը, դեռ դուրս է գալիս տեղական։
Թույլ տվեք թունելին կրել լռելյայն երթուղին
Վիրտուալ ցանցի դարպասի վրա հաճախորդի ամբողջ ինտերնետ երթևեկը թունել ուղղելու աջակցվող եղանակը point-to-site կարգավորմանը հատուկ երթուղիներ ավելացնելն է։ Երկու կեսերը ծածկում են ամբողջ IPv4 տարածությունը, և յուրաքանչյուրը տեղական լռելյայն երթուղուց ավելի կոնկրետ է, ուստի հաճախորդը նախապատվությունը տալիս է դրանց՝ առանց որևէ բան ջնջելու.
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Այդ տողը պատկերավոր է, ոչ թե պատճենելու համար ամբողջական. նախ ստացեք դարպասի օբյեկտը Get-AzVirtualNetworkGateway-ով և փոխարինեք այն GWOBJ-ի փոխարեն, և գործարկելուց առաջ հաստատեք, որ SKU-ն և տեղակայման մոդելը ընդունում են հատուկ երթուղիներ։ Նույն նախածանցները հայտնվում են պորտալում point-to-site կարգավորման էջում, ինչն ավելի ապահով տեղ է դրանք սահմանելու համար, եթե դեռ չեք սկրիպտավորում դարպասը։
Այդ նախածանցների փոփոխությունը անվավեր է դարձնում հաճախորդի փաթեթը։ Նորից ներբեռնեք VPN հաճախորդի փաթեթը և վերատեղադրեք այն, որովհետև երթուղիները ճամփորդում են պրոֆիլի ներսում։ Հին պրոֆիլով նորից միացող հաճախորդը պահում է հին երթուղիների հավաքածուն, և դուք կարող եք կորցնել մեկ ժամ՝ վրիպազերծելով փոփոխություն, որը երբեք չի հասել նրան։
Ապահով վիրտուալ WAN հաբում համարժեքը հաբի երթուղիների աղյուսակում լռելյայն երթուղին է, որը կապված է point-to-site դարպասի հետ, իսկ երթևեկը վերցնում է հաբի Azure Firewall-ը։ Firewall-ը ինտերնետ ուղղված կապերը թարգմանում է իր սեփական հանրային IP հասցեներին, և հենց այդ թարգմանությունից է գալիս նոր ելքային հասցեն։ Երբ firewall-ն ունի մի քանի հանրային IP, դրանցից ցանկացածը կարող է հայտնվել որպես աղբյուր, ուստի allowlist-ը պետք է պարունակի բոլորը։
Վերևի երկու ձևավորումներն էլ IPv4 են։ Երկու /1 նախածանցները ոչինչ չեն անում IPv6-ի համար, և point-to-site-ի IPv6 աջակցությունը բավական նեղ է, որպեսզի փորձարկեք համակցությունը նախքան հավասարություն խոստանալը։
Ստուգեք երթուղին, ապա ելքը
Փաթեթը վերատեղադրելուց և նորից միանալուց հետո հաստատեք, որ հաճախորդը իսկապես տեղադրել է կեսերը։ Windows-ում Get-NetRoute -DestinationPrefix 0.0.0.0/1 և նույն հարցումը 128.0.0.0/1-ի համար պետք է նշեն թունելի ինտերֆեյսը, իսկ route print-ը ցույց է տալիս երկուսն էլ ձեր սկզբնական լռելյայնի կողքին։ Linux-ում ip route show-ն պետք է թվարկի երկու նախածանցները. եթե չի անում, պրոֆիլը երբեք չի կրել դրանք։
Ապա նորից ստուգեք հանրային հասցեն հաճախորդից և կարդացեք firewall-ի մատյանը նույն կապի համար։ Աղբյուրը պետք է լինի firewall-ի հանրային IP-ն՝ թարգմանված պորտով։ Այն հաճախորդը, որը դեռ տեղական է դուրս գալիս, մինչ երկու երթուղիներն էլ գոյություն ունեն, նշանակում է, որ փաթեթները հասել են Azure և դուրս եկել այլ ճանապարհով. օգտատիրոջ կողմից սահմանված երթուղի դարպասի ենթացանցում, firewall, որն ինքն է հարկադիր թունելով տեղական ցանցին, կամ քաղաքականություն, որը հոսքը գցում է թարգմանությունից առաջ։
Նույն նստաշրջանում նորից փորձարկեք մեկ մասնավոր նպատակակետ։ Jump host-ը, որը փոփոխությունից հետո դադարում է պատասխանել, սովորական նշան է, որ նոր նախածանցները ինչ-որ բան դուրս են մղել՝ կամ ավելի նեղ տեղական երթուղի, որը նախկինում հայտարարվում էր, կամ անունների լուծում, որն այժմ գնում է առանց փոխանցողի լուծիչի ձեր մասնավոր գոտիների համար։
Երբ թողնել բաժանված թունելը հանգիստ
Եթե նպատակը միայն մասնավոր API-ին, մասնավոր վերջնակետին կամ ներքին ադմինիստրատորի էջին հասնելն է, լռելյայն վարքը ավելի էժան և ավելի հանգիստ է։ Հարկադիր թունելավորումը ավելացնում է firewall-ի ժամեր և տվյալների մշակման վճարներ, ավելի երկար ուղի և ևս մեկ տեղ, որտեղ յուրաքանչյուր հաճախորդի հոսք կարող է ձախողվել։ Այն նաև շատ ավելի շատ երթևեկություն է որսում, քան այն միակ նպատակակետը, որի համար անհանգստանում էիք։
Դիմեք դրան, երբ պահանջը ձևակերպված է ելքի առումով. գործընկերը պետք է տեսնի ֆիքսված Azure հասցե, անվտանգությունը ցանկանում է, որ կապերը գրանցվեն և ստուգվեն, կամ տվյալները պետք է դուրս գան մեկ վերահսկվող կետով։ Նույնիսկ այդ դեպքում ձևավորումը յուրաքանչյուր օգտատիրոջ տալիս է ընդհանուր ելք, ուստի օգտատիրոջ հաշվետվողականությունը պետք է գա հավելվածի ինքնությունից, ոչ թե աղբյուրի հասցեից։
Նախքան փոփոխությունը փակելը հաստատեք չորս բան. տեղադրված հաճախորդի փաթեթը նորն է, երկու /1 երթուղիները թունելի ինտերֆեյսի վրա են, մասնավոր նպատակակետը դեռ պատասխանում է, և հեռավոր ծառայության մատյանը ցույց է տալիս firewall-ի հասցեն։