Prywatny adres IP Cloud SQL przez VPN: trasa, której nikt nie eksportuje

Wiele zespołów uważa, że prywatny adres IP Cloud SQL działa tylko od wewnątrz VPC, a to przekonanie się utrzymuje, bo awaria wygląda jak problem bazy danych. Google dokumentuje dostęp z sieci połączonych przez Cloud VPN lub Cloud Interconnect. Te sieci nie potrzebują specjalnej funkcji bazy danych, lecz dwóch wymian tras, które łatwo pozostawić w połowie skonfigurowane. Tunel wstaje, instancje obliczeniowe odpowiadają, a połączenie z bazą kończy się przekroczeniem czasu — dokładnie ta kombinacja, która wysyła ludzi do niewłaściwej konsoli.

Mit: prywatny adres IP oznacza prywatność wobec VPC

Dostęp do usług prywatnych to peering VPC między twoją siecią a siecią producenta należącą do Google. Przydzielony zakres dla usługi znajduje się po stronie producenta, a adres instancji jest w jego wnętrzu. To właśnie ten peering sprawia, że baza danych w twoim projekcie może siedzieć na adresie, do którego twoja VPC routuje, choć żadna twoja jawna podsieć go nie zawiera.

Ponieważ to peering, ma też zachowanie peeringu, w tym tę część, w której trasy niestandardowe nie przechodzą automatycznie.

Mit: działający tunel niesie ze sobą trasę do bazy

Dwa zakresy muszą przetrwać podróż. Pierwszy to prefiks klienta: twoja sieć lokalna musi być znana Cloud Routerowi z konkretnymi prefiksami, bo trasa domyślna nie dostarczy importu, którego sieć producenta potrzebuje do drogi powrotnej. Drugi to przydzielony zakres usługi, którego strona zewnętrzna musi się nauczyć, aby jej pakiety do bazy miały gdzie trafić. To różne trasy utrzymywane na różnych granicach, a naprawienie jednej zostawia drugą zepsutą.

Po stronie Google oznacza to włączenie Export custom routes na odpowiednich połączeniach peeringu i dodanie przydzielonego zakresu usługi do ogłaszanych tras Cloud Routera dla tunelu.

Zachowaj ogłoszenia, które już są. Dodanie zakresu usługi nie powinno usuwać tras VPC, które ta sama sesja BGP niesie dla innego ruchu, a zestaw ogłoszeń zastąpiony w całości to druga awaria ukryta za pierwszą. Sprawdź też trasy efektywne na urządzeniu zewnętrznym, bo dotarcie do bramy VPN lub innej podsieci dowodzi tylko transportu.

Mit: Cloud SQL Auth Proxy rozwiązuje problem sieci

The Auth Proxy zapewnia obsługiwane uwierzytelnianie i szyfrowany transport między twoją aplikacją a instancją. Nie tworzy trasy. Proxy uruchomione na hoście bez drogi do sieci prywatnej zawiedzie dokładnie tak jak połączenie bezpośrednie, a jego logi będą mniej pomocne w kwestii przyczyny. Przeniesienie proxy na host, który ma łączność, zmienia to, który odcinek drogi musi działać, i to jest prawdziwa decyzja projektowa, a nie obejście.

Czego nie robi: nie pozwala odłączonemu laptopowi dotrzeć do instancji dostępnej tylko prywatnie.

Mit: Private Service Connect podlega tym samym regułom

Private Service Connect używa punktu końcowego we własnej podsieci i układu DNS, który kontrolujesz, więc trasa do niego to zwykła trasa do adresu, który posiadasz. Ustawienia eksportu peeringu nie dotyczą tego projektu, a kopiowanie zmian peeringu do wdrożenia PSC dodaje ryzyko bez dodawania osiągalności.

Oba dają prywatny adres; podobieństwo na tym się kończy.

Przetestuj drogę w właściwej kolejności

Od klienta zewnętrznego przetestuj najpierw punkt końcowy TCP bazy. Zakończone uzgadnianie TCP oznacza, że routing, zapora i nasłuchiwacz są na miejscu, a następny test to dozwolona operacja uwierzytelniona. Odrzucenie uwierzytelnienia jest w tym momencie właściwie dobrą wiadomością, bo dowodzi, że nasłuchiwacz bazy odpowiedział. Przekroczenie czasu ICMP nie mówi prawie nic o dostępie do bazy, bo wiele dróg go odrzuca, a TCP przekazuje bez problemu.

Jeśli twoje zakresy klienta są poza RFC 1918, przejrzyj dodatkowe wymagania dotyczące eksportu tras i autoryzacji sieci, zanim uznasz, że projekt nie jest obsługiwany.

Zapisz cztery obiekty razem z połączeniem: prefiks zewnętrzny, przydzielony zakres usługi, zaangażowane połączenia peeringu i router, który ogłasza. Te cztery wyjaśniają całą prywatną drogę i zastępują legendę, że Cloud SQL albo zawsze wymaga proxy, albo w ogóle nie da się do niego dotrzeć przez VPN.