SQL över VPN: direkt klient eller intern arbetsstation?

Team vill ha SSMS på sina bärbara datorer, och den snabba lösningen är att publicera SQL-porten till VPN-poolen. Det långsammare svaret frågar var klientprocessen ska köras, eftersom direkt åtkomst och en intern arbetsstation ger olika källadresser, slutpunktsförtroende och datavägar. Ingen av dem är automatiskt säker, och VPN-medlemskap ensamt avgör ingenting. Jämför designerna innan en tillåtelseregel finns.

Två vägar, två källadresser

Vid direkt åtkomst bär den bärbara datorn klientkonfigurationen och öppnar databasanslutningen själv. Vid en fjärransluten arbetsstation öppnar den bärbara datorn en skrivbordssession, och arbetsstationen gör SQL-anslutningen från sin egen adress. Databasen ser därför VPN-poolen eller en översatt gateway i den första designen, och arbetsstationens adress i den andra. Den skillnaden avgör vilken brandväggsregel och vilken SQL-behörighet som faktiskt gäller.

Den bärbara datorn styr fortfarande fjärrsessionen, så en arbetsstation ersätter inte användarautentisering eller sessionspolicy.

Kontrollera vad databasen faktiskt ser

Källadressen är något man mäter i stället för att härleda från ett diagram. Läs den från serversidan av en aktiv anslutning.

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"

Anslutningstestet bevisar att lyssnaren accepterar TCP från det nätverket, medan frågan bevisar vilken inloggning och vilken databas sessionen nådde. För att se adressen som servern registrerade, fråga sys.dm_exec_connections för den aktuella sessionen, vilket returnerar klientadressen efter varje översättning. Om värdet är en gateway och inte den bärbara datorn, kan en värdregel per användare inte fungera på databasmaskinen. Skriv ner det observerade värdet bredvid den valda designen, eftersom återanslutningar och pooländringar flyttar det.

Öppna lyssnaren och inget mer

Öppna bara den tjänst som driftsättningen behöver. Den välkända 1433 är standardinstansens port, inte en universell konstant.

Get-NetTCPConnection -State Listen -LocalPort 1433

Namngivna instanser lyssnar ofta på en dynamisk port, där SQL Server Browser svarar på upptäckt över UDP 1434, och det beroendet är en separat exponering som måste motiveras. Att fästa en fast port till instansen tar bort behovet av Browser och gör brandväggsreglerna stabila. Behåll krypterings- och certifikatkontrollerna som klienten redan utför, i stället för att stänga av dem för att ett test ska gå igenom. Tilldela sedan databasroller för arbetsbelastningen i stället för att lägga hela VPN-gruppen till en serverroll.

Bevisa den tillåtna vägen och den nekade

Öppna en ny session som en vanlig godkänd användare, och bekräfta serverns identitet, databasen och operationen som krävs. Bekräfta sedan uteslutningen: en källa eller ett konto utanför policyn måste misslyckas i samma test. För arbetsstationsdesignen, verifiera att den bärbara datorn inte kan kringgå gränsen genom att nå databasen direkt. För direkt åtkomst, verifiera att rutten och källregeln fortfarande gäller efter en återanslutning.

Registrera var klienten körde, vilken källa databasen observerade och vilken regel som tillät det. Det är beviset som nästa granskning kommer att begära.