Cloud VPN դեպի GCP-ի VM․ օգտագործեք ներքին IP-ն, ոչ թե NAT IP-ն
Դարպասի վերջնակետը, VM-ի ներքին հասցեն և արտաքին մեկը-մեկին NAT հասցեն երեք տարբեր աշխատանք ունեն։ Ստուգեք, թե ձեր երթուղին որն է օգտագործում։
Երբ տեղական ցանցը Cloud VPN-ի միջոցով հասնում է VPC-ին, Compute Engine ծառայության նպատակակետը սովորաբար VM-ի ներքին հասցեն է։ Արտաքին IPv4 հասցեն երկրորդ հասցե չէ, որը կարող եք տեղադրել նույն մասնավոր երթուղու մեջ։ Այս ոլորտում խառնաշփոթի մեծ մասը գալիս է նրանից, որ երեք աշխատանք ունեցող երեք հասցեներ դիտարկվում են որպես փոխարինելի, ուստի սկսեք նշելով, թե տվյալ փաթեթը որն է օգտագործում։
Երեք հասցե, երեք աշխատանք
Անվանեք բոլոր երեքին նախքան դրանցից որևէ մեկի վրիպազերծումը, քանի որ պատասխանը փոխում է այն օբյեկտը, որը ստուգելու եք հաջորդիվ։
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
Առաջինը պատկանում է թունելին։ Երկրորդը պատկանում է ձեր երթուղու և ֆայրվոլի նախագծմանը։ Երրորդը պատկանում է ներգնա ինտերնետ հասանելիությանը և քարտեզագրվում է, ոչ թե կցվում։ Նախագիծը, որն աշխատում է դրանցից մեկի համար, ոչինչ չի ասում մյուս երկուսի մասին։
Ինչու արտաքին հասցեն երկրորդ ինտերֆեյս չէ
Հասցեավորման ուղեցույցը հեղինակավոր աղբյուրն է այն մասին, թե ինչպես են տարբերվում ներքին և արտաքին հասանելիությունը Compute Engine-ում։ Compute Engine-ի արտաքին IPv4-ը մեկը-մեկին քարտեզագրում է օրինակի միակ ներքին NIC-ի վրա, ուստի հյուրը երբեք չի տեսնում երկրորդ ինտերֆեյս կամ երկրորդ հասցե այդ NIC-ում։ Այն, ինչ VM-ը հաղորդում է ներսից, դեռևս մեկ հիմնական ներքին հասցե է։
Այդ պատճառով մասնավոր հաճախորդը, որը թունելով երթուղավորում է դեպի 10.24.1.7, և հաճախորդը, որը նպատակադրում է VM-ի արտաքին հասցեն, տարբեր ուղիների վրա են։ Հանրային հասցեի համար ֆայրվոլի կանոն բացելը ոչինչ չի փոխում VPC-ի այն երթուղում, որը պետք է կրի թունելի տրաֆիկը, և հյուրի երթուղին խմբագրելը չի տեղափոխում հարթակի քարտեզագրումը։ Ընտրեք այն հասցեն, որը ձեր երթուղին անվանում է, ապա ստուգեք միայն այն օբյեկտները, որոնք կառավարում են այն։ Այս կարգապահությունը հեռացնում է գուշակության մեծ մասը այս խնդրի լուծման ուղուց։
Անցեք ուղին gcloud-ով
Սկսեք օրինակից և կարդացեք երկու հասցեները նույն օբյեկտից, որպեսզի իմանաք, թե դրանցից որի մասին է խոսում ձեր փաստաթղթերը․
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"Ապա հաստատեք երթուղավորումը և թույլտվությունը, որոնցից ուղին իրականում կախված է․
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1Կարդացեք թունելի հայտարարված և սովորված միջակայքերը, աշխատանքային բեռի ենթացանցի VPC երթուղին և ֆայրվոլի այն կանոնը, որը թույլ է տալիս տեղական աղբյուրին։ Այս երեքը պետք է համաձայնեն նախքան հյուրի վրա լսողը ընդհանրապես արդիական կդառնա։
Ապա ստուգեք հյուրին․ արդյոք ծառայությունը լսում է ներքին հասցեում, և արդյոք նրա վերադարձի ուղին նորից անցնում է VPC-ով։ Միայն հանրային հասցեին կապված լսողը կձախողվի այս թեստում նույնիսկ այն ժամանակ, երբ ամպի կողմի բոլոր օբյեկտները ճիշտ են։
Հանրային նախածանցը այլ հարց է
Վերոնշյալից ոչինչ չի նշանակում, որ VPN-ի ներսում կրվող յուրաքանչյուր հասցե պետք է լինի RFC1918։ Հեռավոր ցանցը կարող է օրինականորեն համարակալվել հանրային տարածությունից, պայմանով որ հարթակը աջակցում է երթուղավորումը և օպերատորն ունի հասցեի լիազորությունը։ Սա սովորական նախագծային ընտրություն է։
Սա նույնը չէ, ինչ սովորական արտաքին NAT հասցեին վերաբերվելը այնպես, կարծես այն մեկ այլ ներքին ենթացանցային հասցե լինի։ Մեկը նախածանց է, որը դուք երթուղավորում եք․ մյուսը քարտեզագրում է, որը հարթակը կիրառում է ներգնա հասանելիության վրա։
Արտաքին IPv6-ը և հատուկ ձևավորված հասցեային դասավորությունները ունեն իրենց իմաստաբանությունը։ Եթե ձեր ծրագիրը կախված է դրանցից մեկից, կարդացեք հարթակի փաստաթղթերը այդ հատկության համար, փոխանակ IPv4 դեպքից ընդհանրացնելու։ IPv4 քարտեզագրումը սովորական դեպքն է, ոչ միակը, և բացառություններից յուրաքանչյուրն ունի իր կանոնները։
Համընկնող միջակայքերը այլ խնդիր են
Համընկնող մասնավոր միջակայքերը իրական պատճառ են, թե ինչու մարդիկ դիմում են հանրային հասցեին, և դա սխալ լծակն է։ Նպատակակետը VM-ի NAT հասցեին փոխելը չի լուծում համընկնումը․ այն փոխում է, թե փաթեթը որ հասցեի համար է պնդում, առանց սահմանելու, թե ինչպես է աշխատում վերադարձի ուղին։
Լուծեք համընկնումը գիտակցաբար․ համարակալեք նորից, օգտագործեք աջակցվող թարգմանության նախագիծ կամ երթուղավորեք ցանցով, որտեղ նախածանցները չեն բախվում։ Դրանցից յուրաքանչյուրը սեփականատեր ունեցող նախագիծ է։ NAT հասցեն նախագիծ չէ։
Փաստագրեք երկու դաշտերն առանձին
Գրանցեք թունելի գործընկերոջը և աշխատանքային բեռի նպատակակետը որպես երկու առանձին runbook դաշտեր, յուրաքանչյուրը իրեն աջակցող երթուղով և ֆայրվոլի կանոնով։ Բարձրացող IPsec թունելը միայն ասում է, որ կողմերը համաձայն են․ այն ոչինչ չի ասում, թե որ հասցեում է աշխատանքային բեռը հասանելի, և ոչ էլ այն մասին, թե արդյոք նրա մասնավոր երթուղին ամբողջական է։
Ստուգեք մյուս կողմի իրական հաճախորդով․ լուծեք անունը, հաստատեք, որ այն վերադարձնում է ներքին հասցեն, միացեք և ստուգեք վերադարձի տրաֆիկը։ Compute Engine-ի IP հասցեների փաստաթղթերը վերևում օգտագործված ներքին-ընդդեմ-արտաքին տարբերության հղումն են։