Google API VPN-ით: მარშრუტი VIP-ზე და არა მხოლოდ ქვექსელზე
VPC-ის ქვექსელამდე მარშრუტი API-ის VIP მისამართებს არ ირჩევს. ამოხსენი სწორი სახელები, გამოაცხადე VIP პრეფიქსი, შეინარჩუნე VPC-ის დაბრუნების გზა და შემდეგ შეამოწმე HTTPS.
შედი SSH-ით ლოკალურ სერვერზე, ასწიე გვირაბი და პირადი VM პასუხობს; შემდეგ Google API-ზე პირველი გამოძახება მარშრუტის გარეშე ვარდება. VM-ის ქვექსელი და API-ის VIP მისამართები სხვადასხვა დანიშნულებაა, ამიტომ ერთის მარშრუტი მეორეს არ ირჩევს. სამი პირობა უნდა სრულდებოდეს, სანამ პირადი API გამოძახება იმუშავებს. API-ის სახელი უნდა გადაიჭრას VIP-ად, VIP პრეფიქსი უნდა გამოცხადდეს გვირაბის გავლით, ხოლო VPC-მ უნდა იცოდეს, როგორ გაუშვას პასუხი უკან. ping ამაზე არაფერს გეუბნება, და ქვექსელში მდგარ მანქანაზე მომუშავე SSH სესიაც არაფერს.
API-ის VIP მისამართები ცალკე დანიშნულებებია
Google აქვეყნებს გამოყოფილ VIP მისამართებს ლოკალური ქსელიდან API-ზე წვდომისთვის, და სწორედ ეს მისამართები უნდა დააბრუნოს თქვენმა DNS-მა API სახელებისთვის. ორივე პატარა პრეფიქსია და არც ერთი არ არის RFC 1918 სივრცე:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
საჯაროდ მოჩვენებული მისამართები არ ნიშნავს, რომ მარშრუტმა გვირაბი უნდა დატოვოს ჩვეულებრივი ინტერნეტისთვის. პრეფიქსები იმისთვისაა, რომ ლოკალურმა კლიენტმა Google-ის წინა ნაწილებს მხარდაჭერილი გზით მიაღწიოს და არა თვითნებური გასასვლელი წერტილით. მოეპყარი მათ გვირაბს მიკუთვნებულ დანიშნულებებად და არა შესამოწმებელ ჰოსტებად. ინტერნეტ გასასვლელისთვის დაწერილი firewall წესი ჩვეულებრივ ყრის მათ, და ეს გავრცელებული მიზეზია, თუ რატომ ვარდება გამოძახება დაწყებამდე.
DNS წყვეტს, რომელ საბოლოო წერტილს მიაღწევ
მიუთითე ლოკალური ამომხსნელი იმ ჩანაწერებზე, რომლებსაც Google არჩეული საბოლოო წერტილისთვის ადასტურებს, რათა აპლიკაციისთვის საჭირო სახელები სწორედ იმ VIP-ით უპასუხოს. მხოლოდ googleapis.com მიმაგრება ინვენტარს არ ნიშნავს: პაკეტების რეესტრებს, კონტეინერების რეესტრებს და მიგრაციის კონექტორებს საკუთარი დოკუმენტირებული სახელები აქვთ. შეზღუდული VIP-იც არ ატარებს ყველა სერვისს, ამიტომ ამოხსნილი სახელი მაინც შეიძლება არ იყოს მხარდაჭერილი. ჩამწერე დომენები, რომლებსაც აპლიკაცია რეალურად უკავშირდება, სანამ ამომხსნელს შეეხები.
VPC-ში VM მისამართის გამოცნობა სერვისის სახელის ნაცვლად შესწორება არ არის, და ის ჩვეულებრივ მალავს DNS-ის ხარვეზს, სანამ სხვა კლიენტი ვარდება.
გამოაცხადე VIP პრეფიქსი, დანარჩენი შეინარჩუნე
BGP-ზე დაფუძნებული კავშირისას Cloud Router-მა უნდა გამოაცხადოს არჩეული VIP პრეფიქსი, რათა ლოკალურმა როუტერმა ეს დიაპაზონი განზრახული სესიის გავლით ისწავლოს. მხოლოდ VPC ქვექსელების გამოცხადება ამ დიაპაზონს არ ამატებს, და ლოკალური როუტერი ამ მისამართებისთვის თავის ნაგულისხმევ გზას იყენებს. მარშრუტიზაციის ცხრილში არსებული პრეფიქსი ერთადერთი მტკიცებულებაა, რომ გამოცხადებამ სესია გადაკვეთა.
შეინარჩუნე არსებული გამოცხადებები სანამ ახალს ამატებ, რადგან როუტერის დონისა და პირის დონის ოპციებს განსხვავებული მოცვა აქვთ, და ნაკრების შეცვლამ შეიძლება უკვე მომუშავე ქსელები უკან გაიწვიოს. შემდეგ შეამოწმე ეფექტური გამოცხადება თითოეულ სესიაზე და არა მთელ როუტერზე. დაკარგული პრეფიქსი და უკან გაწვეული პრეფიქსი ლოკალური მხრიდან ერთნაირად გამოიყურება, ამიტომ სწორედ სესიის ხედი ჰყოფს გამოტოვებას რეგრესიისგან.
VPC-ის მხარეს საკუთარი მარშრუტი და დაბრუნების გზა სჭირდება
VPC-ის შიგნით VIP-ის გზამ შემდეგ ჰოპად ნაგულისხმევი ინტერნეტ კარიბჭე უნდა გამოიყენოს, და სახელის მიუხედავად ეს ტრაფიკი Google-ის ქსელში რჩება. VPC-ს ასევე სჭირდება დაბრუნების მარშრუტი ლოკალურ წყარომდე VPN-ის გავლით, რაც გამოცხადებული პრეფიქსისგან ცალკე ობიექტია. გაითვალისწინე დოკუმენტირებული რეგიონული მარშრუტიზაციის მოთხოვნები, როცა გვირაბი და კლიენტი ერთ რეგიონში არ არიან.
შეამოწმე დაბრუნების გზა დამოუკიდებლად, რადგან მომუშავე მოთხოვნის მიმართულებამ შეიძლება დამტვრეული პასუხის მიმართულება დამალოს. ორი მიმართულება, ორი მარშრუტი, და თითოეული თავისი სიმპტომით ვარდება.
გამოსცადე მოთხოვნა, შემდეგ წაიკითხე უარი
ICMP ექო ამ VIP-ებიდან პასუხს არ იღებს, ამიტომ წარუმატებელი ping არაფერს ამტკიცებს, წარმატებული კი ძალიან ცოტას. რეალური კლიენტიდან შეამოწმე სახელის პასუხი და არჩეული მარშრუტი, შემდეგ გაუშვი უფლებამოსილი HTTPS მოთხოვნა იმ სერვისზე, რომელიც გაინტერესებს. თუ მოთხოვნა სერვისამდე მივიდა და უარყვეს, შეხედე სერთიფიკატებს, IAM-ს და ნებისმიერ მოქმედ სერვისის პერიმეტრის პოლიტიკას.
პირადი მარშრუტიზაცია API-ის ავტორიზაციას არ იძლევა და არ ცვლის იმას, რისი უფლებაც იდენტობას აქვს. ტრანსპორტის წარმატება და უფლებამოსილი პასუხი ცალკე შედეგებია, და ორივე გჭირდება. IPv6-ის გზაც ცხადად შეინარჩუნე, რადგან IPv4 პრეფიქსების კონფიგურაცია არაფერს ამბობს IPv6-ის მცდელ კლიენტზე.
Google-ის სახელმძღვანელო Private Google Access-ის შესახებ ლოკალური ქსელიდან ერთად მოიცავს DNS ჩანაწერებს და მარშრუტიზაციის მოთხოვნებს, ამიტომ შეადარე ამომხსნელისა და გამოცხადების პარამეტრები მას და არა ფორუმის პოსტს. შემდეგ ხელახლა გაუშვი იგივე მოთხოვნა და ჩაწერე პასუხი და მარშრუტი იმავე ბილეთში.