VPN üzərindən Google API: yalnız alt şəbəkəni deyil, VIP-i marşrutlaşdırın
VPC alt şəbəkəsinə marşrut API VIP ünvanlarını seçmir. Düzgün adları həll edin, VIP prefiksini elan edin, VPC-də geri dönüş yolunu saxlayın, sonra HTTPS-i sınayın.
Şirkətdaxili serverə SSH ilə qoşulun, tuneli qaldırın və şəxsi VM cavab verir; sonra Google API-yə ilk müraciət marşrut olmadığı üçün uğursuz olur. VM alt şəbəkəsi və API VIP-ləri fərqli təyinat nöqtələridir, ona görə birinə olan marşrut digərini seçmir. Şəxsi API müraciətinin işləməsi üçün üç şərt ödənməlidir. API adı VIP-ə həll olunmalı, VIP prefiksi tunel üzərindən elan edilməli və VPC cavabı geri göndərməyi bilməlidir. Ping bunların heç birini demir, alt şəbəkədəki maşına işləyən SSH sessiyası da demir.
API VIP-ləri ayrı təyinat nöqtələridir
Google şirkətdaxili API girişi üçün ayrılmış VIP-lər yayımlayır və bunlar DNS-in API adları üçün qaytarmalı olduğu ünvanlardır. Hər ikisi kiçik prefikslərdir və heç biri RFC 1918 məkanı deyil:
| 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 |
Açıq görünən ünvanlar marşrutun tuneli tərk etməli olduğu anlamına gəlmir adi internet üçün. Prefikslər ona görə mövcuddur ki, şirkətdaxili müştəri ixtiyari çıxış nöqtəsi yerinə dəstəklənən yolla Google ön hissələrinə çata bilsin. Onlara tunelə aid təyinat nöqtələri kimi baxın, yoxlanılası hostlar kimi deyil. İnternet çıxışı üçün yazılmış firewall qaydası adətən onları atır və bu, müraciətin başlamadan uğursuz olmasının ümumi səbəblərindən biridir.
DNS hansı son nöqtəyə çatdığınızı müəyyən edir
Şirkətdaxili həlledicini seçilmiş son nöqtə üçün Google-un sənədləşdirdiyi qeydlərə yönəldin ki, tətbiqin ehtiyac duyduğu adlar həmin VIP ilə cavab versin. Yalnız googleapis.com xəritələmək inventar deyil: paket reyestrləri, konteyner reyestrləri və miqrasiya konnektorlarının öz sənədləşdirilmiş adları var. Məhdud VIP də hər xidməti daşımır, ona görə həll olunan ad hələ dəstəklənməyə bilər. Həllediciyə toxunmazdan əvvəl tətbiqin həqiqətən əlaqə saxladığı domenləri yazın.
VPC VM ünvanını xidmət adının əvəzinə təxmin etmək düzəliş deyil və adətən DNS boşluğunu başqa müştəri uğursuz olana qədər gizlədir.
VIP prefiksini elan edin, qalanını saxlayın
BGP əsaslı bağlantıda Cloud Router seçilmiş VIP prefiksini elan etməlidir ki, şirkətdaxili marşrutlaşdırıcı həmin diapazonu nəzərdə tutulan sessiya üzərindən öyrənə bilsin. Yalnız VPC alt şəbəkələrini elan etmək həmin diapazonu əlavə etmir və şirkətdaxili marşrutlaşdırıcı o ünvanlar üçün standart yolunu işlətməyə davam edir. Marşrut cədvəlindəki prefiks elanın sessiyanı keçdiyinin yeganə sübutudur.
Onu əlavə edərkən mövcud elanları qoruyun, çünki marşrutlaşdırıcı səviyyəli və peer səviyyəli seçimlərin əhatəsi fərqlidir və dəsti dəyişmək artıq işləyən şəbəkələri geri çəkə bilər. Sonra effektiv elanı bütün marşrutlaşdırıcıda deyil, hər sessiyada yoxlayın. İtkin prefiks və geri çəkilmiş prefiks şirkətdaxili tərəfdən eyni görünür, ona görə buraxmanı reqressiyadan ayıran sessiya görünüşüdür.
VPC tərəfinin öz marşrutu və geri dönüş yolu lazımdır
VPC daxilində VIP yolu növbəti hop kimi standart internet şlüzünü istifadə etməlidir və adına baxmayaraq bu trafik Google şəbəkəsi daxilində qalır. VPC həmçinin VPN vasitəsilə şirkətdaxili mənbəyə geri marşrut lazımdır və bu, elan edilmiş prefiksdən ayrı obyektdir. Tunel və müştəri eyni regionda olmadıqda sənədləşdirilmiş regional marşrutlaşdırma tələblərini nəzərə alın.
Geri dönüş yolunu ayrıca yoxlayın, çünki işləyən sorğu istiqaməti pozulmuş cavab istiqamətini gizlədə bilər. İki istiqamət, iki marşrut və hər biri öz simptomu ilə uğursuz olur.
Sorğunu sınayın, sonra rədd cavabını oxuyun
ICMP echo bu VIP-lərdən cavab almır, ona görə uğursuz ping heç nə sübut etmir, uğurlu ping isə çox az şey. Faktiki müştəridən adın cavabını və seçilmiş marşrutu yoxlayın, sonra maraqlandığınız xidmətə icazəli HTTPS sorğusu göndərin. Sorğu xidmətə çatıb rədd olunursa, etimad məlumatlarına, IAM-ə və tətbiq olunan xidmət perimetri siyasətinə baxın.
Şəxsi marşrutlaşdırma API avtorizasiyası vermir və identikliyin nəyə icazəli olduğunu dəyişmir. Nəqliyyat uğuru və icazəli cavab ayrı nəticələrdir və sizə hər ikisi lazımdır. IPv6 yolunu da açıq saxlayın, çünki IPv4 prefikslərini konfiqurasiya etmək IPv6-ya üstünlük verən müştəri haqqında heç nə demir.
Google-un şirkətdaxili Private Google Access təlimatı həm DNS qeydlərini, həm də marşrutlaşdırma tələblərini birlikdə əhatə edir, ona görə həlledici və elan parametrlərinizi forum yazısı ilə deyil, onunla müqayisə edin. Sonra eyni sorğunu yenidən işlədin və cavabı və marşrutu eyni biletdə qeyd edin.