SQL prin VPN: client direct sau stație de lucru internă?

Echipele vor SSMS pe laptopurile lor, iar soluția rapidă este publicarea portului SQL în pool-ul VPN. Răspunsul mai lent întreabă unde ar trebui să ruleze procesul client, deoarece accesul direct și o stație de lucru internă produc adrese sursă, încredere a punctului final și căi de date diferite. Niciuna nu este automat sigură, iar apartenența la VPN singură nu decide nimic. Comparați proiectele înainte de a exista o regulă de permisiune.

Două căi, două adrese sursă

La accesul direct laptopul poartă configurația clientului și deschide singur conexiunea la baza de date. La o stație de lucru la distanță laptopul deschide o sesiune de desktop, iar stația face conexiunea SQL din propria adresă. Astfel baza de date vede pool-ul VPN sau un gateway tradus în primul proiect, și adresa stației în al doilea. Această diferență decide ce regulă de firewall și ce permisiune SQL se aplică efectiv.

Laptopul controlează în continuare sesiunea la distanță, deci o stație de lucru nu înlocuiește autentificarea utilizatorului sau politica de sesiune.

Verificați ce vede de fapt baza de date

Adresa sursă se măsoară, nu se deduce dintr-o diagramă. Citiți-o pe partea serverului a unei conexiuni active.

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"

Testul de conectivitate dovedește că ascultătorul acceptă TCP din acea rețea, iar interogarea dovedește la ce autentificare și la ce bază de date a ajuns sesiunea. Pentru a vedea adresa înregistrată de server, interogați sys.dm_exec_connections pentru sesiunea curentă, ceea ce returnează adresa clientului după orice traducere. Dacă acea valoare este un gateway și nu laptopul, o regulă de gazdă pe utilizator nu poate funcționa pe mașina bazei de date. Notați valoarea observată lângă proiectul ales, deoarece reconectările și modificările pool-ului o mută.

Deschideți ascultătorul și nimic mai mult

Deschideți doar serviciul de care are nevoie implementarea. Cunoscutul 1433 este portul instanței implicite, nu o constantă universală.

Get-NetTCPConnection -State Listen -LocalPort 1433

Instanțele numite ascultă adesea pe un port dinamic, cu SQL Server Browser răspunzând la descoperire pe UDP 1434, iar această dependență este o expunere separată care trebuie justificată. Fixarea unui port stabil pentru instanță elimină nevoia de Browser și face regulile de firewall stabile. Păstrați verificările de criptare și certificate pe care clientul le face deja, în loc să le dezactivați pentru ca un test să treacă. Apoi acordați roluri de bază de date pentru sarcina de lucru, în loc să adăugați întregul grup VPN la un rol de server.

Dovediți calea permisă și pe cea refuzată

Deschideți o sesiune nouă ca utilizator obișnuit aprobat și confirmați identitatea serverului, baza de date și operația necesară. Apoi confirmați excluderea: o sursă sau un cont din afara politicii trebuie să eșueze la același test. Pentru proiectul cu stație de lucru, verificați că laptopul nu poate ocoli granița ajungând direct la baza de date. Pentru accesul direct, verificați că ruta și regula sursă sunt încă valabile după o reconectare.

Înregistrați unde a rulat clientul, ce sursă a observat baza de date și ce regulă a permis-o. Acestea sunt dovezile pe care le va cere următoarea revizuire.