VPC-yə VPN işləyir, lakin idarə olunan xidmət vaxt aşımına uğrayır
Tunel sizin kənarınızda bitir, provayderin ön qapısında deyil. Marşrutu dəyişməzdən əvvəl hədəfi VM-də yerləşən, VPC-yə qoşulmuş və ya yalnız açıq kimi təsnif edin.
İdarə olunan verilənlər bazasına VPN vasitəsilə çatmaq adətən runbook-da heç kimin yazmadığı bir səbəbdən uğursuz olur: tunel şəbəkə kənarınızda bitir, xidmət isə heç vaxt onun sizin tərəfinizdə olmayıb. Marşrut cədvəli düzgün görünür, tunel işlək olduğunu bildirir və bağlantı yenə də vaxt aşımına uğrayır. Aşağıdakı dörd yoxlamanı ardıcıllıqla aparın və keçmə şərti yanlış olan ilk yoxlamada dayanın, çünki ondan sonrakı hər yoxlama əvvəlkilərin keçdiyini fərz edir.
Birinci yoxlama: son nöqtə əslində harada yerləşir?
VPN şlüzü ünvanlaşdırmasına sizin nəzarət etdiyiniz iki şəbəkəni birləşdirir. İdarə olunan xidmət isə provayderin öz ön qapısı arxasında idarə olunur və həmin qapı məhsuldan asılı olaraq üç formadan birini alır. Hansı forma ilə işlədiyinizi bilmirsinizsə, heç bir marşrut işi kömək etməyəcək, çünki nasazlıq heç də marşrut nasazlığı olmaya bilər.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Ən çox vaxt itkisi bu təsnifatı atlayıb birbaşa marşrut cədvəlinə keçməkdən yaranır. Açıq son nöqtəsi olan provayder-hostinq xidməti diaqram nə deyirsə desin tunelinizin arxasında deyil, VPC-yə qoşulmuş xidmət isə heç vaxt açıq DNS cavabında görünməyəcək.
İkinci yoxlama: ElastiCache kimi VPC-yə qoşulmuş xidmət
Bu tipli keşlər öz VPC-nizin içində ünvanlanır və ümumiyyətlə internetə baxan dinləyicisi yoxdur. Həmin VPC-də bitən müştəri VPN onlara çata bilər, ancaq üç şərt eyni vaxtda ödənildikdə. Keş son nöqtəsi tunelinizin görə bildiyi alt şəbəkələrlə əlaqələndirilməli, təhlükəsizlik qrupu müştərilərinizin gəldiyi ünvana icazə verməli və müştəri tərəfində keş alt şəbəkələrini əhatə edən marşrut olmalıdır.
Ümumi səhv yaxınlıqdakı hansısa bağlantının sayıldığını fərz etməkdir. VPN-i başqa VPC-yə qoşmaq və ya yalnız peering-ə güvənmək keşin təhlükəsizlik qrupunu və ya onun alt şəbəkə marşrut cədvəlini müştərilərinizə qədər genişləndirmir. Mövcud tunel başqa yerdə bitdikdə, həmin VPC-nin içində yerləşdirilən jump host və ya VPN server adi ehtiyat variantdır. Bu ehtiyat variant dizayn deyil, müvəqqəti həlldir və runbook-da belə də qeyd olunmalıdır.
Üçüncü yoxlama: açıq adı olan PaaS son nöqtəsi
Azure Database for PostgreSQL açıq server adı təqdim edir. O, hosts faylında bərkidib şlüz vasitəsilə yönləndirə biləcəyiniz xüsusi ünvan vermir. Virtual şəbəkə xidmət son nöqtələri hansı alt şəbəkələrin resursa çata biləcəyini məhdudlaşdırır; VPN ilə gələn yerli müştəriyə icazə vermir.
Xüsusi giriş əldə etmək xüsusi son nöqtə və ya private-link dizaynı tətbiq etmək, sonra açıq adın internetin əvəzinə həmin son nöqtə ilə cavab verməsi üçün xüsusi DNS zonası əlavə etmək deməkdir. VPN-in xidmət son nöqtəsi qaydası ilə birləşməsi yalnız diaqramda oxşar görünən fərqli bir arxitekturadır. App Service eyni məntiqi əks istiqamətdən izləyir: VNet inteqrasiyası tətbiqə VNet-ə çıxan çağırışlar etməyə imkan verir və tunelinizdən daxil olan xüsusi yol yaratmır. Buna görə daxil olan xüsusi giriş üçün xüsusi son nöqtə, App Service Environment və ya tətbiqin qabağında şlüz tələb olunur və hansını istifadə edə biləcəyiniz plana bağlıdır.
Dördüncü yoxlama: öz ön qapısı olan məhsullar
Firebase Hosting-i Cloud VPN-ə qoşmaq mümkün deyil, çünki hostinq qatı layihə VPC-nin içindəki bir şey deyil, qlobal ön tərəfdir. Sənədləşdirilmiş alternativ nəzarət olunan giriş nöqtəsini özünüz qurmaqdır: proksi instansı və ya bucket ilə dəstəklənən yük balanslaşdırıcısı. Hər iki halda sayt təmiz hostinq məhsulu olmaqdan çıxır və artıq sizin idarə etdiyiniz infrastruktura çevrilir. Bu mübadiləni kimsə tunelin onu əhatə edəcəyini vəd etməzdən əvvəl adlandırmağa dəyər.
Private API Gateway VPC xidməti tərəfinə daha yaxındır: interface VPC son nöqtəsi cavabları xüsusi ünvanlar olan host adı dərc edir və binalarınızdan trafik tunel və ya ayrılmış interkonekt vasitəsilə gəlir. Son nöqtə API ilə əlaqələndirilməli, sertifikat və host adı isə zəng edənlərin istifadə etdiyi xüsusi domenlə uyğun olmalıdır.
Google Cloud VPN tunelləri adlara deyil, peer IP ünvanlarına bağlanır. DNS yönləndirməsi ayrıca konfiqurasiya olunur, buna görə tunel tam sağlam ola bilər, halbuki uzaq xüsusi zonada axtarışlar hələ də uğursuz olur.
Sonra sərhədi tapın
Eyni bağlantını VPC-nin içindəki VM-dən işə salın. Orada uğurlu olub VPN müştərisindən uğursuz olduqda, boşluq müştəri yolu ilə xidmət son nöqtəsi arasındadır: marşrut, təhlükəsizlik qrupu, son nöqtə siyasəti və ya ad. Hər iki cəhd uğursuz olduqda, o şəbəkədə heç nə xidmətə çata bilmir və VPN heç vaxt maneə olmayıb.
getent hosts db.internal.example
nc -vz db.internal.example 5432Ad axtarışını və port yoxlamasını ayrı-ayrılıqda aparın, çünki onlar fərqli səbəblərdən uğursuz olur və cüt sizə yolun hansı yarısının pozulduğunu deyir. Açıq ünvana çevrilən ad sizə xüsusi DNS zonasının işdə olmadığını bildirir.