SQL přes VPN: přímý klient, nebo interní pracovní stanice?

Týmy chtějí SSMS na svých noteboocích a rychlým řešením je publikovat SQL port do VPN poolu. Pomalejší odpověď se ptá, kde má běžet klientský proces, protože přímý přístup a interní pracovní stanice vytvářejí různé zdrojové adresy, důvěru koncového bodu a cesty dat. Ani jedno není automaticky bezpečné a samotné členství ve VPN nerozhoduje nic. Porovnejte návrhy dřív, než existuje povolovací pravidlo.

Dvě cesty, dvě zdrojové adresy

Při přímém přístupu nese notebook klientskou konfiguraci a sám otevírá připojení k databázi. Při vzdálené pracovní stanici notebook otevírá relaci pracovní plochy a pracovní stanice navazuje SQL spojení ze své vlastní adresy. Databáze proto v prvním návrhu vidí VPN pool nebo přeloženou bránu a ve druhém adresu pracovní stanice. Tento rozdíl rozhoduje, které pravidlo firewallu a které SQL oprávnění skutečně platí.

Notebook stále řídí vzdálenou relaci, takže pracovní stanice nenahrazuje ověřování uživatele ani zásady relace.

Ověřte, co databáze skutečně vidí

Zdrojová adresa se má měřit, ne odvozovat z diagramu. Přečtěte ji na straně serveru živého připojení.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

Test konektivity dokazuje, že listener přijímá TCP z této sítě, zatímco dotaz dokazuje, ke kterému přihlášení a databázi relace došla. Chcete-li vidět adresu, kterou server zaznamenal, dotážete se sys.dm_exec_connections pro aktuální relaci, což vrací adresu klienta po každém překladu. Pokud je touto hodnotou brána a ne notebook, pravidlo hostitele pro jednotlivého uživatele nemůže na stroji s databází fungovat. Zapište pozorovanou hodnotu vedle zvoleného návrhu, protože opětovná připojení a změny poolu ji posouvají.

Otevřete listener a nic navíc

Otevřete jen službu, kterou nasazení potřebuje. Známý 1433 je port výchozí instance, nikoli univerzální konstanta.

Get-NetTCPConnection -State Listen -LocalPort 1433

Pojmenované instance často poslouchají na dynamickém portu, SQL Server Browser odpovídá na zjišťování přes UDP 1434 a tato závislost je samostatné vystavení, které je třeba odůvodnit. Připnutí pevného portu pro instanci odstraní potřebu Browseru a zpřehlední pravidla firewallu. Ponechte kontroly šifrování a certifikátů, které klient už provádí, místo abyste je vypínali, aby test prošel. Potom přidělte databázové role pro zátěž, místo abyste celou VPN skupinu přidali do serverové role.

Dokažte povolenou cestu i tu zamítnutou

Otevřete novou relaci jako běžný schválený uživatel a potvrďte identitu serveru, databázi a požadovanou operaci. Potom potvrďte vyloučení: zdroj nebo účet mimo zásady musí stejným testem selhat. U návrhu s pracovní stanicí ověřte, že notebook nemůže obejít hranici přímým dosažením databáze. U přímého přístupu ověřte, že trasa a zdrojové pravidlo po opětovném připojení stále platí.

Zaznamenejte, kde klient běžel, jaký zdroj databáze pozorovala a které pravidlo to povolilo. To je důkaz, který si vyžádá příští revize.