Udostępnij za pomocą

Sieć z dostępem prywatnym (integracja sieci wirtualnej) dla usługi Azure Database for PostgreSQL

W tym artykule opisano koncepcje koneksji i sieci na potrzeby elastycznych instancji serwera usługi Azure Database for PostgreSQL.

Podczas tworzenia elastycznego serwera Azure Database for PostgreSQL należy wybrać jedną z następujących opcji sieciowych:

  • Dostęp prywatny (integracja z siecią wirtualną)
  • Dostęp publiczny (dozwolone adresy IP) i prywatny punkt końcowy

W tym dokumencie opisano opcję sieci dostępu prywatnego (integracja sieci wirtualnej).

Dostęp prywatny (integracja z siecią wirtualną)

Możesz wdrożyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL w sieci wirtualnej platformy Azure przy użyciu iniekcji sieci wirtualnej. Sieci wirtualne platformy Azure zapewniają prywatną i bezpieczną komunikację sieci. Zasoby w sieci wirtualnej mogą komunikować się za pośrednictwem prywatnych adresów IP, które zostały przypisane w tej sieci.

Wybierz tę opcję sieci, jeśli chcesz uzyskać następujące możliwości:

  • Połącz się do zasobów platformy Azure w ramach tej samej sieci wirtualnej z elastycznym serwerem usługi Azure Database for PostgreSQL za pomocą prywatnych adresów IP.
  • Użyj sieci VPN lub usługi Azure ExpressRoute, aby nawiązać połączenie z zasobami spoza platformy Azure do elastycznego wystąpienia serwera Azure Database for PostgreSQL.
  • Upewnij się, że instancja elastycznego serwera Azure Database for PostgreSQL nie posiada publicznego punktu końcowego dostępnego przez Internet.

Diagram przedstawiający, jak działa peering między sieciami wirtualnymi, z których jedna zawiera elastyczny serwer Azure Database for PostgreSQL.

Na powyższym diagramie:

  • Instancje elastycznego serwera usługi Azure Database for PostgreSQL są włączane do podsieci 10.0.1.0/24 w sieci wirtualnej VNet-1.
  • Aplikacje wdrożone w różnych podsieciach w tej samej sieci wirtualnej mogą uzyskiwać bezpośredni dostęp do elastycznych wystąpień serwera usługi Azure Database for PostgreSQL.
  • Aplikacje wdrożone w innej sieci wirtualnej (VNet-2) nie mają bezpośredniego dostępu do instancji elastycznego serwera usługi Azure Database for PostgreSQL. Należy wykonać peering sieci wirtualnych dla prywatnej strefy DNS przed uzyskaniem dostępu do wystąpienia serwera elastycznego.

Pojęcia dotyczące sieci wirtualnej

Sieć wirtualna platformy Azure zawiera prywatną przestrzeń adresową IP skonfigurowaną do użycia. Twoja sieć wirtualna musi znajdować się w tym samym regionie Azure, co instancja elastycznego serwera bazy danych Azure dla PostgreSQL. Aby dowiedzieć się więcej o sieciach wirtualnych, zobacz Omówienie usługi Azure Virtual Network.

Poniżej przedstawiono kilka pojęć, które należy znać podczas korzystania z sieci wirtualnych, w których zasoby są zintegrowane z siecią wirtualną z elastycznymi wystąpieniami serwera usługi Azure Database for PostgreSQL:

  • Podsieć delegowana: sieć wirtualna zawiera podsieci (podsieci). Podsieci umożliwiają segmentowanie sieci wirtualnej na mniejsze przestrzenie adresowe. Zasoby platformy Azure są wdrażane w określonych podsieciach w sieci wirtualnej.

    Wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL zintegrowane w sieci wirtualnej musi znajdować się w delegowanej podsieci. Oznacza to, że tylko elastyczne wystąpienia serwera Azure Database for PostgreSQL mogą używać tej podsieci. W podsieci delegowanej nie mogą znajdować się żadne inne typy zasobów platformy Azure. Delegujesz podsieć, przypisując jej właściwość delegowania jako Microsoft.DBforPostgreSQL/flexibleServers.

    Najmniejszy zakres CIDR, który można określić dla podsieci to /28, który zapewnia 16 adresów IP. Nie można przypisać pierwszego i ostatniego adresu w żadnej sieci lub podsieci do żadnego pojedynczego hosta. Platforma Azure rezerwuje pięć adresów IP, które mają być używane wewnętrznie przez sieć platformy Azure, w tym dwa adresy IP, których nie można przypisać do hosta, jak wspomniano. Pozostawia to 11 dostępnych adresów IP dla zakresu CIDR /28. Pojedyncze wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL z funkcjami wysokiej dostępności używa czterech adresów.

    W przypadku replikacji i połączeń firmy Microsoft Entra upewnij się, że tabele tras nie wpływają na ruch. Typowym wzorcem jest kierowanie całego ruchu wychodzącego za pośrednictwem usługi Azure Firewall lub niestandardowego lokalnego urządzenia filtrowania sieci.

    Jeśli podsieć ma tabelę tras skojarzona z regułą w celu kierowania całego ruchu do urządzenia wirtualnego:

    • Dodaj regułę z tagiem AzureActiveDirectory usługi docelowej i następnym przeskokiem Internet.
    • Dodaj regułę z docelowym zakresem adresów IP, który jest taki sam jak zakres podsieci wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL, oraz określ następny przeskok Virtual Network.

    Ważne

    AzureFirewallSubnetNazwy , AzureFirewallManagementSubnet, AzureBastionSubneti GatewaySubnet są zarezerwowane na platformie Azure. Nie używaj żadnej z tych nazw jako nazwy podsieci. Ponadto sieci wirtualne nie powinny mieć nakładających się przestrzeni adresowych do tworzenia replik między regionami.

  • Sieciowa grupa zabezpieczeń: reguły zabezpieczeń w sieciowych grupach zabezpieczeń umożliwiają filtrowanie typu ruchu sieciowego, który może przepływać w podsieciach sieci wirtualnych i interfejsach sieciowych i wychodzących z sieci. Aby uzyskać więcej informacji, zobacz Omówienie sieciowej grupy zabezpieczeń.

    Grupy zabezpieczeń aplikacji ułatwiają kontrolowanie zabezpieczeń warstwy 4 przy użyciu sieciowych grup zabezpieczeń dla sieci prostych. Umożliwia on szybkie wykonywanie następujących zadań:

    • Przyłącz maszyny wirtualne do usługi ASG lub usuń maszyny wirtualne z grupy asg.
    • Dynamiczne stosowanie reguł do tych maszyn wirtualnych lub usuwanie reguł z tych maszyn wirtualnych.

    Aby uzyskać więcej informacji, zobacz Omówienie usługi ASG.

    Obecnie nie obsługujemy sieciowych grup zabezpieczeń (NSG), w których grupa przypisań zabezpieczeń (ASG) jest częścią reguły w połączeniu z elastycznymi wystąpieniami serwera usługi Azure Database for PostgreSQL. Obecnie zalecamy używanie filtrowania źródłowego lub docelowego opartego na adresach IP w sieciowej grupie zabezpieczeń.

    Wysoka dostępność i inne funkcje serwera usługi Azure Database for PostgreSQL wymagają możliwości wysyłania/odbierania ruchu do docelowego portu 5432 w podsieci sieci wirtualnej platformy Azure, w której jest wdrażane elastyczne wystąpienie serwera usługi Azure Database for PostgreSQL i do usługi Azure Storage na potrzeby archiwizacji dzienników. Jeśli utworzysz sieciowe grupy zabezpieczeń (NSG) w celu odmowy przepływu ruchu do lub z wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w podsieci, w której jest ono wdrożone, upewnij się, że zezwalasz na ruch do portu 5432 w podsieci oraz do usługi Storage, przy użyciu tagu usługi Storage jako celu. W celu zapewnienia wysokiej dostępności najlepszym rozwiązaniem jest dodanie punktu końcowego usługi Microsoft.Storage, ponieważ zapewnia prawidłowy routing ruchu do konta usługi Azure Storage, które jest używane do przekazywania plików dziennika zapisu (WAL).

    Tę regułę wyjątku można dodatkowo filtrować , dodając region świadczenia usługi Azure do etykiety, takiej jak us-east.storage. Ponadto, jeśli zdecydujesz się używać Microsoft Entra do uwierzytelniania logowań do elastycznego wystąpienia serwera Azure Database for PostgreSQL, zezwól na ruch wychodzący do Microsoft Entra ID przy użyciu tagu usługi Microsoft Entra.

    Podczas konfigurowania replik do odczytu w różnych regionach platformy Azure wystąpienie elastycznego serwera bazy danych Azure dla PostgreSQL musi mieć możliwość wysyłania i odbierania ruchu do portu docelowego 5432 zarówno z serwera podstawowego, jak i repliki, oraz do usługi Azure Storage w regionach podstawowych i replik zarówno z serwera podstawowego, jak i repliki. Wymagany docelowy port TCP dla magazynu to 443.

  • integracja strefy Prywatna strefa DNS: integracja strefy usługi Azure Prywatna strefa DNS umożliwia rozpoznawanie prywatnego systemu DNS w bieżącej sieci wirtualnej lub dowolnej równorzędnej sieci wirtualnej w regionie, w której jest połączona strefa Prywatna strefa DNS.

Używanie strefy Prywatna strefa DNS

Usługa Azure Prywatna strefa DNS zapewnia niezawodną i bezpieczną usługę DNS dla sieci wirtualnej. Usługa Azure Prywatna strefa DNS zarządza i rozpoznaje nazwy domen w sieci wirtualnej bez konieczności konfigurowania niestandardowego rozwiązania DNS.

W przypadku korzystania z dostępu do sieci prywatnej z siecią wirtualną platformy Azure podanie informacji o strefie Prywatna strefa DNS jest obowiązkowe w celu przeprowadzenia rozpoznawania nazw DNS. W celu utworzenia nowego elastycznego wystąpienia serwera Azure Database for PostgreSQL z dostępem przez prywatną sieć, należy używać prywatnych stref DNS podczas konfigurowania elastycznych wystąpień serwera z prywatnym dostępem.

Ważne

W przypadku korzystania z prywatnej strefy DNS w innej subskrypcji, ta subskrypcja musi mieć zarejestrowanego dostawcę zasobów Microsoft.DBforPostgreSQL. W przeciwnym razie wdrożenie instancji elastycznego serwera usługi Azure Database for PostgreSQL nie zostanie ukończone.

Aby utworzyć nowe elastyczne wystąpienie serwera usługi Azure Database for PostgreSQL z użyciem prywatnego dostępu do sieci za pośrednictwem interfejsu API, szablonu Azure Resource Manager (ARM), Bicep lub Terraform, należy utworzyć prywatne strefy DNS. Następnie użyj ich podczas konfigurowania elastycznych wystąpień serwera usługi Azure Database for PostgreSQL z dostępem prywatnym. Aby uzyskać więcej informacji, zobacz Specyfikacje interfejsu API REST dla platformy Azure.

Jeśli używasz witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure do tworzenia wystąpień serwera elastycznego usługi Azure Database for PostgreSQL, możesz podać nazwę prywatnej strefy DNS, która została wcześniej utworzona w tej samej lub innej subskrypcji, albo domyślna prywatna strefa DNS zostanie automatycznie utworzona w ramach subskrypcji.

Jeśli używasz interfejsu API platformy Azure, szablonu usługi ARM, aplikacji Bicep lub narzędzia Terraform, utwórz strefy Prywatna strefa DNS kończące się na ..postgres.database.azure.com Używaj tych stref podczas konfigurowania instancji elastycznych serwerów Azure Database for PostgreSQL z prywatnym dostępem. Na przykład użyj formularza [name1].[name2].postgres.database.azure.com lub [name].postgres.database.azure.com. Jeśli zdecydujesz się użyć formularza [name].postgres.database.azure.com, nazwa nie może być nazwą używaną dla jednego z wystąpień serwera elastycznego usługi Azure Database for PostgreSQL lub podczas aprowizacji zostanie wyświetlony komunikat o błędzie. Aby uzyskać więcej informacji, zobacz omówienie stref Prywatna strefa DNS.

W przypadku korzystania z portalu Azure, interfejsów API, interfejsu wiersza polecenia Azure lub szablonu ARM, możesz także zmienić prywatną strefę DNS z tej, którą podałeś przy tworzeniu elastycznego wystąpienia serwera Azure Database for PostgreSQL, na inną prywatną strefę DNS, która istnieje dla tej samej lub innej subskrypcji.

Ważne

Możliwość zmiany prywatnej strefy DNS z tej, która została podana podczas tworzenia wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL na inną prywatną strefę DNS, jest obecnie wyłączona dla serwerów z włączoną funkcją wysokiej dostępności.

Po utworzeniu strefy Prywatna strefa DNS na platformie Azure należy połączyć z nią sieć wirtualną. Zasoby hostowane w połączonej sieci wirtualnej mogą następnie uzyskiwać dostęp do strefy Prywatna strefa DNS.

Ważne

Nie weryfikujemy już obecności połączenia z siecią wirtualną podczas tworzenia serwera dla wystąpień elastycznego serwera usługi Azure Database for PostgreSQL z siecią prywatną. Podczas tworzenia serwera za pośrednictwem portalu udostępniamy klientowi możliwość utworzenia linku do tworzenia serwera za pomocą pola wyboru Połącz strefę Prywatna strefa DNS z siecią wirtualną w witrynie Azure Portal.

Strefy prywatne DNS są odporne na awarie regionalne, ponieważ dane strefy są globalnie dostępne. Rekordy zasobów w strefie prywatnej są automatycznie replikowane w różnych regionach. Azure Prywatna strefa DNS to podstawowa, strefowo nadmiarowa usługa strefy dostępności. Aby uzyskać więcej informacji, zobacz Usługi platformy Azure z obsługą stref dostępności.

Integracja z niestandardowym serwerem DNS

Jeśli używasz niestandardowego serwera DNS, musisz użyć przekierowywacza DNS, aby rozwiązać FQDN wystąpienia serwera elastycznego Azure Database for PostgreSQL. Adres IP usługi przesyłania dalej powinien mieć wartość 168.63.129.16.

Niestandardowy serwer DNS powinien znajdować się w sieci wirtualnej lub osiągalny za pośrednictwem ustawienia serwera DNS sieci wirtualnej. Aby dowiedzieć się więcej, zobacz Rozpoznawanie nazw używające własnego serwera DNS.

Prywatna strefa DNS strefy i komunikacji równorzędnej sieci wirtualnych

Prywatna strefa DNS ustawienia strefy i komunikacja równorzędna sieci wirtualnych są niezależne od siebie. Jeśli chcesz nawiązać połączenie z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL z poziomu klienta aprowizowanego w innej sieci wirtualnej z tego samego regionu lub innego regionu, musisz połączyć prywatną strefę DNS z siecią wirtualną. Aby uzyskać więcej informacji, zobacz Łączenie sieci wirtualnej.

Uwaga

Można łączyć tylko Prywatna strefa DNS nazw stref kończących się ciągiem postgres.database.azure.com . Nazwa strefy DNS nie może być taka sama jak instancje serwerów elastycznych usługi Azure Database for PostgreSQL. W przeciwnym razie rozpoznawanie nazw kończy się niepowodzeniem.

Aby zamapować nazwę serwera na rekord DNS, możesz uruchomić nslookup polecenie w usłudze Azure Cloud Shell przy użyciu programu Azure PowerShell lub powłoki Bash. Zastąp nazwę serwera parametru <server_name> w poniższym przykładzie:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Korzystanie z projektu sieci prywatnej piasty i szprych

Piasta i szprycha to popularny model sieci umożliwiający efektywne zarządzanie typowymi wymaganiami dotyczącymi komunikacji lub zabezpieczeń.

Piasta to sieć wirtualna, która działa jako centralna lokalizacja do zarządzania łącznością zewnętrzną. Hostuje również usługi używane przez wiele obciążeń. Piasta koordynuje całą komunikację do i ze szprych. Reguły i procesy IT, takie jak zabezpieczenia, umożliwiają inspekcję i kierowanie ruchu oraz centralne zarządzanie ruchem. Szprychy to sieci wirtualne, które obsługują obciążenia i łączą się z centralną piastą za pomocą komunikacji równorzędnej sieci wirtualnej. Usługi udostępnione są hostowane we własnych podsieciach do udostępniania szprych. Podsieć obwodowa działa następnie jako urządzenie zabezpieczające.

Szprychy są również sieciami wirtualnymi na platformie Azure, które są używane do izolowania poszczególnych obciążeń. Przepływ ruchu między siedzibą lokalną a platformą Azure jest połączony za pośrednictwem usługi Azure ExpressRoute lub sieci VPN typu lokacja-lokacja połączonej z siecią wirtualną koncentratora. Sieci wirtualne ze szprych do piasty są równorzędne i umożliwiają komunikację z zasobami lokalnymi. Piastę i poszczególne szprychy można implementować w osobnych subskrypcjach lub grupach zasobów.

Istnieją trzy główne wzorce łączenia ze sobą sieci wirtualnych szprych:

  • Szprychy są bezpośrednio połączone ze sobą: komunikacja równorzędna sieci wirtualnych lub tunele VPN są tworzone między sieciami wirtualnymi szprych w celu zapewnienia bezpośredniej łączności bez przechodzenia przez sieć wirtualną piasty.
  • Szprychy komunikują się za pośrednictwem urządzenia sieciowego: każda sieć wirtualna szprychy ma komunikację równorzędną z wirtualną siecią WAN lub z siecią wirtualną piasty. Urządzenie kieruje ruch z szprychy do szprychy. Urządzenie może być zarządzane przez firmę Microsoft (podobnie jak w przypadku wirtualnej sieci WAN) lub przez Ciebie.
  • Brama sieci wirtualnej jest dołączona do sieci piasty i korzysta z tras zdefiniowanych przez użytkownika: umożliwia komunikację między szprychami.

Diagram przedstawiający podstawową architekturę piasty i szprych z łącznością hybrydową za pośrednictwem koncentratora ekspresowego.

Użyj usługi Azure Virtual Network Manager , aby utworzyć nowe (i dołączyć istniejące) topologie sieci wirtualnej piasty i szprych na potrzeby centralnego zarządzania łącznością i mechanizmami kontroli zabezpieczeń.

Komunikacja z klientami sieciowymi prywatnie w różnych regionach

Często klienci muszą łączyć się z różnymi regionami świadczenia usługi Azure klientów. Mówiąc dokładniej, to pytanie zwykle sprowadza się do sposobu łączenia dwóch sieci wirtualnych (z których jedna ma wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL, a druga ma klienta aplikacji), które znajdują się w różnych regionach.

Istnieje wiele sposobów osiągnięcia takiej łączności, w tym:

  • Globalna komunikacja równorzędna sieci wirtualnych. Ta metodologia jest najbardziej powszechna, ponieważ jest to najprostszy sposób łączenia sieci w różnych regionach. Globalna komunikacja równorzędna sieci wirtualnych tworzy połączenie za pośrednictwem sieci szkieletowej platformy Azure bezpośrednio między dwiema równorzędną sieciami wirtualnymi. Ta metoda zapewnia najlepszą przepływność sieci i najmniejsze opóźnienia łączności. Gdy sieci wirtualne są równorzędne, platforma Azure obsługuje również routing automatycznie. Te sieci wirtualne mogą komunikować się ze wszystkimi zasobami w równorzędnej sieci wirtualnej, które są ustanawiane w bramie sieci VPN.
  • Połączenie sieciowe-sieć. Połączenie między sieciami wirtualnymi (połączenie między siecią i siecią) jest zasadniczo siecią VPN między dwiema lokalizacjami platformy Azure. Połączenie sieć-sieć jest ustanawiane w bramie sieci VPN. Ruch wiąże się z dwoma większymi przeskokami ruchu w porównaniu z globalną komunikacją równorzędną sieci wirtualnych. Istnieje również dodatkowe opóźnienie i niższa przepustowość w porównaniu z tą metodą.
  • Komunikacja za pośrednictwem urządzenia sieciowego w architekturze piasty i szprych. Zamiast łączyć sieci wirtualne szprychy bezpośrednio ze sobą, można użyć urządzeń sieciowych do przesyłania dalej ruchu między szprychami. Urządzenia sieciowe zapewniają więcej usług sieciowych, takich jak głęboka inspekcja pakietów i segmentacja ruchu lub monitorowanie, ale mogą one wprowadzać opóźnienia i wąskie gardła wydajności, jeśli nie są prawidłowo dopasowane.

Replikacja między regionami i sieciami wirtualnymi platformy Azure przy użyciu sieci prywatnej

Replikacja bazy danych to proces kopiowania danych z serwera centralnego lub podstawowego do wielu serwerów nazywanych replikami. Serwer podstawowy akceptuje operacje odczytu i zapisu, ale repliki obsługują transakcje tylko do odczytu. Serwer podstawowy i repliki tworzą zbiorczo klaster bazy danych. Celem replikacji bazy danych jest zapewnienie nadmiarowości, spójności, wysokiej dostępności i dostępności danych, szczególnie w aplikacjach o dużym natężeniu ruchu i krytycznym znaczeniu.

Usługa Azure Database for PostgreSQL oferuje dwie metody replikacji: fizyczne (czyli przesyłanie strumieniowe) za pośrednictwem wbudowanej funkcji repliki do odczytu i replikacji logicznej. Oba są idealne w różnych przypadkach użycia, a użytkownik może wybrać jeden w zależności od celu końcowego.

Replikacja między regionami platformy Azure, z oddzielnymi sieciami wirtualnymi w każdym regionie, wymaga łączności między regionalnymi granicami sieci wirtualnych, które mogą być udostępniane za pośrednictwem komunikacji równorzędnej sieci wirtualnych lub architektur piasty i szprych za pośrednictwem urządzenia sieciowego.

Domyślnie rozpoznawanie nazw DNS jest ograniczone do sieci wirtualnej. Każdy klient w jednej sieci wirtualnej (VNET1) nie może rozpoznać nazwy FQDN wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w innej sieci wirtualnej (VNET2).

Aby rozwiązać ten problem, upewnij się, że klienci w sieci VNET1 mogą uzyskać dostęp do elastycznego wystąpienia serwera Azure Database for PostgreSQL w prywatnej strefie DNS. Dodaj link sieci wirtualnej do prywatnej strefy DNS wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.

Nieobsługiwane scenariusze sieci wirtualnej

Poniżej przedstawiono pewne ograniczenia dotyczące pracy z sieciami wirtualnymi utworzonymi za pośrednictwem integracji sieci wirtualnej:

Ważne

Usługa Azure Resource Manager obsługuje możliwość blokowania zasobów jako kontroli zabezpieczeń. Blokady zasobów są stosowane do zasobu i są skuteczne we wszystkich użytkownikach i rolach. Istnieją dwa typy blokady zasobów: CanNotDelete i ReadOnly. Te typy blokad można zastosować do strefy Prywatna strefa DNS lub do pojedynczego zestawu rekordów.

Zastosowanie blokady dowolnego rodzaju na prywatnej strefie DNS lub pojedynczym zestawie rekordów może zakłócać zdolność instancji elastycznego serwera Azure Database for PostgreSQL do aktualizacji rekordów DNS. Może to również powodować problemy podczas ważnych operacji w systemie DNS, takich jak tryb failover o wysokiej dostępności z podstawowej do pomocniczej. Z tych powodów upewnij się, że nie używasz prywatnej strefy DNS ani blokad rekordów podczas korzystania z funkcji wysokiej dostępności w wystąpieniu elastycznego serwera w usłudze Azure Database for PostgreSQL.

Nazwa hosta

Niezależnie od wybranej opcji sieciowej zalecamy, aby zawsze używać nazwy FQDN jako nazwy hosta podczas nawiązywania połączenia z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL. Adres IP serwera nie ma gwarancji, że pozostanie statyczny. Użycie nazwy FQDN pomaga uniknąć wprowadzania zmian w parametry połączenia.

Przykładem użycia nazwy FQDN jako nazwy hosta jest hostname = servername.postgres.database.azure.com. Jeśli to możliwe, unikaj używania hostname = 10.0.0.4 (adresu prywatnego) lub hostname = 40.2.45.67 (adresu publicznego).

Powiązana zawartość

  • Last updated on