Baza danych, która działa przed połączeniem VPN i zawodzi po nim, rzadko jest problemem z danymi logowania. Zapory chmurowe dopasowują adresy źródłowe, a pełny tunel zastępuje ten, który dopasowywały. Różnica między tym, co według ciebie wysyła laptop, a tym, co odbiera serwer, to cały błąd, i można ją zmierzyć w jednym kroku.

Czym staje się adres źródłowy

W pełnym tunelu każdy pakiet opuszcza sieć przez bramę VPN, więc serwer widzi adres wyjściowy bramy, a nie twoje domowe połączenie. Jeśli na ścieżce stoi serwer proxy przekazujący, dociera jego adres. Oba są legalnymi źródłami i żaden nie jest adresem z twojej pierwotnej reguły.

Reguły zapory Azure SQL na poziomie serwera i bazy danych dopasowują adres klienta, który dociera do serwera logicznego, a po pełnym tunelu jest to adres wyjściowy. Grupa zabezpieczeń AWS zezwalająca na jeden adres zachowuje się tak samo. Pakiet jest odrzucany przed uwierzytelnieniem, więc zwracany błąd wygląda jak awaria sieci, a nie problem z uprawnieniami. Właśnie dlatego ludzie zaczynają resetować hasła.

Gdzie zapada decyzja o liście dozwolonych

Przeczytaj regułę pasującą do zawodzącej ścieżki, nie tę, którą pamiętasz, że utworzyłeś. Zanotuj jej zakres, port, protokół oraz to, czy jest oceniana przed jakąkolwiek weryfikacją tożsamości.

Następnie zdecyduj, która warstwa legalnie odpowiada za tę decyzję. Reguła adresowa odpowiada na pytanie, skąd pochodzi ruch. Prywatny punkt końcowy odpowiada, czy usługa jest w ogóle osiągalna prywatną ścieżką. Wyjątek tunelu dzielonego odpowiada, które cele omijają tunel. Nie są wymienne i każda zawodzi inaczej, gdy tunel się zmienia.

Trzy naprawy, trzy warstwy

Każda z poniższych opcji naprawia przepływ z innego powodu, a wybór złej daje połączenie, które działa do następnej zmiany bramy.

RepairLayer it changesWhat it does not fix
Add the egress address to the ruleSource address matchingNothing about routing, and it breaks when the egress moves
Use a private endpointWhether the service is reached privatelyA client that still resolves the public name
Add a split-tunnel exceptionWhich flows bypass the tunnelAn expired credential or a wrong password

Dodanie adresu wyjściowego to najmniejsza zmiana i najbardziej krucha, ponieważ nowa brama lub inny region unieważniają go po cichu. Udokumentuj adres obok definicji tunelu, aby oba poruszały się razem. Tymczasowy szeroki zakres to diagnoza, a nie naprawa; pozostawienie go na miejscu to sposób, w jaki wewnętrzne usługi kończą jako wystawione.

Dlaczego zarządzana platforma nie może dołączyć do tunelu

Platformy aplikacyjne takie jak Heroku, AppHarbor czy CloudBees uruchamiają twój kod w środowisku bez urządzenia tun lub tap i bez uprawnień do jego utworzenia. Ich model wejściowy to HTTP, a nie dowolne gniazdo nasłuchujące. Buildpack dostarczający plik binarny VPN nadal nie ma gdzie umieścić interfejsu. Działające wzorce to statyczny adres wyjściowy, który baza danych może dopuścić, produkt prywatnego połączenia oferowany przez platformę albo proxy w strefie DMZ osiągalne przez HTTPS.

To proxy to ścieżka dostępu z własnym uwierzytelnianiem i rejestrowaniem. Nie czyni platformy członkiem twojego VPN, a opisywanie tego w ten sposób tworzy reguły, których nikt nie może zaudytować.

Zweryfikuj od klienta, który zawiódł

Połącz się ponownie i powtórz dokładną ścieżkę klienta. Sprawdź adres źródłowy, który rejestruje usługa, trasę, którą klient wybiera dla nazwy bazy danych, oraz wynik rzeczywistego zapytania, w tej kolejności. Test z bramy dowodzi, że brama działa, co nigdy nie było wątpliwe. Jeśli połączenie teraz się uwierzytelnia, a zapytanie nadal zawodzi, pozostałym problemem są uprawnienia w bazie danych.

Przeglądaj te reguły za każdym razem, gdy tunel się zmienia. Wymieniona brama lub nowy zakres wyjściowy psują ścieżkę bez żadnej zmiany w konfiguracji aplikacji.

Powiązane artykuły