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 |
პირველი გვირაბს ეკუთვნის. მეორე — თქვენი მარშრუტისა და firewall-ის დიზაინს. მესამე — შემომავალ ინტერნეტ წვდომას და ის აისახება, არა მიმაგრდება. დიზაინი, რომელიც ერთ მათგანზე მუშაობს, დანარჩენ ორზე არაფერს ამბობს.
რატომ არ არის გარე მისამართი მეორე ინტერფეისი
მისამართების სახელმძღვანელო არის ავტორიტეტი იმის შესახებ, თუ როგორ განსხვავდება შიდა და გარე ხელმისაწვდომობა Compute Engine-ზე. Compute Engine-ის გარე IPv4 არის ერთ-ერთზე ასახვა ინსტანციის ერთადერთ შიდა NIC-ზე, ამიტომ სტუმარი ვერასდროს ხედავს მეორე ინტერფეისს ან მეორე მისამართს ამ NIC-ზე. რასაც VM შიგნიდან იტყობინება, კვლავ ერთი ძირითადი შიდა მისამართია.
ამიტომ კერძო კლიენტი, რომელიც გვირაბის გავლით მარშრუტიზაციას აკეთებს 10.24.1.7 მისამართისკენ, და კლიენტი, რომელიც VM-ის გარე მისამართს მიმართავს, სხვადასხვა გზაზე არიან. საჯარო მისამართისთვის firewall-ის წესის გახსნა არაფერს ცვლის 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 მარშრუტი და firewall-ის ის წესი, რომელიც ლოკალურ წყაროს უშვებს. ეს სამი უნდა შეთანხმდეს, სანამ სტუმარზე მსმენელი საერთოდ აქტუალური გახდება.
შემდეგ შეამოწმეთ სტუმარი: ემსახურება თუ არა სერვისი შიდა მისამართზე და უბრუნდება თუ არა მისი დაბრუნების გზა VPC-ის გავლით? მხოლოდ საჯარო მისამართზე მიბმული მსმენელი ვერ გაივლის ამ ტესტს მაშინაც, როცა ღრუბლის მხარეს ყველა ობიექტი სწორია.
საჯარო პრეფიქსი სხვა კითხვაა
ზემოთქმულიდან არაფერი ნიშნავს, რომ VPN-ის შიგნით გადატანილი ყოველი მისამართი RFC1918 უნდა იყოს. დისტანციური ქსელი კანონიერად შეიძლება დანომრდეს საჯარო სივრციდან, თუ პლატფორმა მარშრუტიზაციას მხარს უჭერს და ოპერატორს მისამართის უფლება აქვს. ეს ნორმალური დიზაინის არჩევანია.
ეს არ არის იგივე, რაც ჩვეულებრივი გარე NAT მისამართის მოპყრობა ისე, თითქოს ის სხვა შიდა ქვექსელის მისამართია. ერთი პრეფიქსია, რომელსაც მარშრუტიზაციას უკეთებთ; მეორე — ასახვა, რომელსაც პლატფორმა შემომავალ წვდომაზე იყენებს.
გარე IPv6-ს და სპეციალურად შექმნილ მისამართების განლაგებას საკუთარი სემანტიკა აქვს. თუ თქვენი გეგმა ერთ-ერთ მათგანზეა დამოკიდებული, წაიკითხეთ პლატფორმის დოკუმენტაცია იმ ფუნქციისთვის, ნაცვლად IPv4-ის შემთხვევიდან განზოგადებისა. IPv4-ის ასახვა ჩვეულებრივი შემთხვევაა, არა ერთადერთი, და გამონაკლისებს თითოეულს საკუთარი წესები აქვს.
გადაფარვადი დიაპაზონები სხვა პრობლემაა
კერძო დიაპაზონების გადაფარვა რეალური მიზეზია, რის გამოც ადამიანები საჯარო მისამართს მიმართავენ, და ეს არასწორი ბერკეტია. დანიშნულების VM-ის NAT მისამართზე შეცვლა გადაფარვას არ წყვეტს; ის ცვლის, თუ რომელი მისამართისთვის ამბობს პაკეტი, რომ არის, განუსაზღვრელად, როგორ მუშაობს დაბრუნების გზა.
გადაფარვა გააზრებულად გადაწყვიტეთ: ხელახლა დანომრეთ, გამოიყენეთ მხარდაჭერილი თარგმანის დიზაინი, ან მარშრუტიზაცია გაატარეთ ქსელში, სადაც პრეფიქსები არ ეჯახება. თითოეული ეს არის დიზაინი მფლობელით. NAT მისამართი დიზაინი არ არის.
ორი ველი ცალ-ცალკე დააფიქსირეთ
ჩაწერეთ გვირაბის პარტნიორი და სამუშაო დატვირთვის დანიშნულება როგორც ორი ცალკე runbook ველი, თითოეული მისი მხარდამჭერი მარშრუტითა და firewall-ის წესით. აწეული IPsec გვირაბი მხოლოდ იმას გეუბნებათ, რომ მხარეები შეთანხმდნენ; ის არაფერს ამბობს იმაზე, თუ რომელ მისამართზეა სამუშაო დატვირთვა ხელმისაწვდომი, და არც იმაზე, სრულია თუ არა მისი კერძო მარშრუტი.
გადაამოწმეთ რეალური კლიენტით მეორე მხარეს: გადაწყვიტეთ სახელი, დაადასტურეთ, რომ შიდა მისამართს აბრუნებს, დაუკავშირდით და შეამოწმეთ დაბრუნების ტრაფიკი. Compute Engine-ის IP მისამართების დოკუმენტაცია წარმოადგენს ზემოთ გამოყენებული შიდა-გარე განსხვავების ცნობარს.