Privátní koncový bod, stejný název serveru: připojovací řetězce Azure SQL

Private Link mění, kam připojení dorazí, ne jak se připojení jmenuje. U Azure SQL Database je tento rozdíl celý návrh: logický server si ponechá své jméno a privátní koncový bod poskytuje síťový záznam, na který se jméno překládá. Nahradit jméno IP adresou je jediná změna, která zároveň rozbije TLS, přihlašovací údaje i nástroje. Dva připojovací řetězce mohou vypadat stejně a chovat se úplně jinak.

Zachovejte orders-db.database.windows.net a dejte klientovi pro něj privátní odpověď.

Jméno a adresa mají různé úlohy

Jméno identifikuje službu SQL, a to je to, co certifikát a přihlášení očekávají. Privátní adresa poskytuje síťový záznam uvnitř připojené virtuální sítě. Záměna jednoho za druhé vytvoří připojení, které k něčemu dorazí a vůči ničemu se neautentizuje.

Pokyny Microsoftu pro Azure SQL vyžadují od klientů obvyklý název serveru. Přímá IP adresa, a stejně tak název s předponou privatelink, není zaměnitelný cíl přihlášení. Nástroje, které přijmou IP adresu, ji přijmou a poté selžou u TLS nebo u autentizace, což skutečnou chybu skryje. Tyto chyby vypadají jako problémy s přihlašovacími údaji, dokud se nepodíváte na název hostitele v chybovém hlášení.

Co privátní zóna skutečně mění

Privátní zóna DNS zaznamenává jednu adresu serveru v rámci oboru názvů privatelink a zóna je propojena s virtuální sítí, která ji má používat. Překlad se přesouvá; připojovací řetězec ne. Podoba níže je ilustrace, ne záznam k vložení do veřejné zóny.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Udržujte tento záznam i jeho propojení se zónou jako infrastrukturu, s vlastníkem a datem revize.

Dvě zóny se stejným původem a různými odpověďmi jsou normální koncový stav, ne konflikt. Veřejní klienti si ponechávají veřejnou odpověď a privátní klienti dostávají adresu koncového bodu. Režim selhání, na který je třeba dávat pozor, je částečné šíření privátního pohledu, kdy se jedna podsíť překládá privátně a jiná tiše ne.

Klienti mimo Azure potřebují cestu do této zóny

Klient VPN stojí mimo překladač Azure, takže privátní zóna musí být dosažitelná z hybridní cesty. Přesměrovač Azure DNS nebo Azure DNS Private Resolver může obsluhovat dotazy přicházející přes tuto síť. Pokyny Microsoftu říkají předávat příslušnou veřejnou zónu služby přes toto uspořádání, místo předpokládat, že klienti dotazují název privatelink přímo. Klienti, kteří nedokážou přeložit privátní odpověď, tiše přejdou na veřejnou.

Rozsah předávání držte záměrný, protože nahrazení používané veřejné zóny rozbije názvy, které náhrada neobsahuje.

Zřizujte v pořadí, které drží identitu pevnou

Kroky mají oddělené vlastníky: vytvořte a schvalte koncový bod, zajistěte trasu VPN, integrujte privátní DNS a potom nakonfigurujte klienta s jeho obvyklým názvem serveru. Dělat DNS před trasou vytváří časové limity, které vypadají jako selhání DNS. Dělat klienta nakonec udržuje v pohybu jednu proměnnou naráz. Každý krok má pozorovatelný výsledek, takže žádný se nemusí testovat hádáním.

Připojená ikona VPN sama o sobě privátní cíl nevybere.

Co privátní koncový bod nevypíná

Vytvoření privátního koncového bodu automaticky nevypíná veřejný přístup k logickému serveru. To je samostatné rozhodnutí o nasazení a patří až poté, co je potvrzeno, že zamýšlení privátní klienti fungují. Zachovejte cestu pro obnovení a počítejte s aplikacemi, které stále používají veřejný vstup. Vypnout nejprve veřejný přístup je způsob, jak se fungující služba stane výpadkem s úhlednou auditní stopou.

Zkontrolujte také, jakou zásadu připojení server používá.

Redirect posílá klienta na port na uzlu po úvodním připojení k bráně, což mění, co musí klientská síť povolit. Proxy drží provoz na bráně. Úspěšné TCP handshake na jednom portu není celý přihlašovací postup.

Toto je Azure SQL Database, ne SQL Managed Instance, která má vlastní model připojení a žádný srovnatelný příběh privátního koncového bodu. V obou případech držte tři věci označené odděleně: jméno, síťový záznam a přihlašovací údaj. Změna toho, kudy připojení cestuje, by nikdy neměla změnit, se kterou službou si klient myslí, že mluví.