Udostępnij przez


Nawiązywanie połączenia z systemu Linux lub macOS

pobierz sterownika ODBC

W tym artykule omówiono sposób tworzenia połączenia z bazą danych programu SQL Server.

Właściwości połączenia

Zobacz nazwy DSN, słowa kluczowe i atrybuty parametrów połączenia, aby zapoznać się ze wszystkimi słowami kluczowymi i atrybutami połączenia obsługiwanymi w systemach Linux i macOS.

Ważne

Podczas nawiązywania połączenia z bazą danych korzystającą z funkcji dublowania bazy danych (ma partnera trybu failover), nie należy określać nazwy bazy danych w parametrach połączenia. Zamiast tego wyślij polecenie usedatabase_name w celu nawiązania połączenia z bazą danych przed wykonaniem zapytań.

Wartość przekazana do słowa kluczowego Driver może być jedną z następujących wartości:

  • Nazwa użyta podczas instalowania sterownika.

  • Ścieżka do biblioteki sterowników, która została określona w pliku szablonu .ini używanym do zainstalowania sterownika.

Nazwy DSN są opcjonalne. Można użyć DSN do zdefiniowania słów kluczowych parametrów połączenia pod nazwą DSN, do której można się następnie odwoływać w łączu połączenia. Aby utworzyć nazwę DSN, utwórz (w razie potrzeby) i zmodyfikuj plik ~/.odbc.ini (.odbc.ini w katalogu głównym) dla nazwy DSN użytkownika dostępnej tylko dla bieżącego użytkownika lub /etc/odbc.ini dla nazwy DSN systemu (wymagane uprawnienia administracyjne). Poniższy odbc.ini to przykład pokazujący minimalne wymagane wpisy dla nazwy DSN:

# [DSN name]
[MSSQLTest]  
Driver = ODBC Driver 18 for SQL Server  
# Server = [protocol:]server[,port]  
Server = tcp:localhost,1433
Encrypt = yes
#
# Note:  
# Port isn't a valid keyword in the odbc.ini file  
# for the Microsoft ODBC driver on Linux or macOS
#  

Aby nawiązać połączenie przy użyciu powyższej nazwy DSN w parametrach połączenia, należy określić DSN słowo kluczowe, takie jak: DSN=MSSQLTest;UID=my_username;PWD=<password>
Powyższe parametry połączenia byłyby odpowiednikiem określania parametrów połączenia bez słowa kluczowego DSN , takiego jak: Driver=ODBC Driver 18 for SQL Server;Server=tcp:localhost,1433;Encrypt=yes;UID=my_username;PWD=<password>

Opcjonalnie możesz określić protokół i port, aby nawiązać połączenie z serwerem. Na przykład Server=tcp:servername,12345. Jedynym protokołem obsługiwanym przez sterowniki systemów Linux i macOS jest tcp.

Aby nawiązać połączenie z nazwanym wystąpieniem na porcie statycznym, użyj Server=servername,port_number. Nawiązywanie połączenia z portem dynamicznym nie jest obsługiwane przed wersją 17.4.

Alternatywnie, możesz dodać informacje DSN do pliku wzorca i wykonać następujące polecenie, aby dodać je do pliku ~/.odbc.ini.

odbcinst -i -s -f <template_file>

Aby uzyskać pełną dokumentację dotyczącą plików ini i odbcinst, zobacz dokumentację systemu unixODBC. Aby uzyskać wpisy w odbc.ini pliku specyficzne dla sterownika ODBC dla SQL Server, zobacz słowa kluczowe i atrybuty DSN oraz parametry połączenia obsługiwane w systemach Linux i macOS.

Możesz zweryfikować, czy sterownik działa, testując połączenie za pomocą isql, lub użyć następującego polecenia:

bcp master.INFORMATION_SCHEMA.TABLES out OutFile.dat -S <server> -U <name> -P <password>

Korzystanie z protokołu TLS/SSL

Do szyfrowania połączeń z programem SQL Server można użyć protokołu Transport Layer Security (TLS), wcześniej znanego jako Secure Sockets Layer (SSL). Protokół TLS chroni nazwy użytkowników i hasła programu SQL Server za pośrednictwem sieci. Protokół TLS weryfikuje również tożsamość serwera w celu ochrony przed atakami typu man-in-the-middle (MITM).

Włączenie szyfrowania zwiększa bezpieczeństwo kosztem wydajności.

Aby uzyskać więcej informacji, zobacz Szyfrowanie połączeń z programem SQL Server i Używanie szyfrowania bez walidacji.

Niezależnie od ustawień funkcji Encrypt and TrustServerCertificate poświadczenia logowania serwera (nazwa użytkownika i hasło) są zawsze szyfrowane. W poniższych tabelach przedstawiono efekt ustawień Encrypt and TrustServerCertificate .

Sterownik ODBC 18 i nowszy

Ustawienie szyfrowania Certyfikat serwera zaufania Wymuszanie szyfrowania serwera Wynik
Nie. Nie. Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem nie są szyfrowane.
Nie. Tak Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem nie są szyfrowane.
Tak Nie. Nie. Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Tak Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Nie. Nie. Tak Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.
Nie. Tak Tak Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Nie. Tak Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Tak Tak Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Surowy - - Certyfikat TrustServerCertificate jest ignorowany. Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.

Uwaga / Notatka

Ścisłe jest dostępne tylko dla serwerów, które obsługują połączenia TDS 8.0.

Sterownik ODBC 17 i starszy

Ustawienie szyfrowania Certyfikat serwera zaufania Wymuszanie szyfrowania serwera Wynik
Nie. Nie. Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem nie są szyfrowane.
Nie. Tak Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem nie są szyfrowane.
Tak Nie. Nie. Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Tak Nie. Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Nie. Nie. Tak Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Nie. Tak Tak Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Nie. Tak Certyfikat serwera jest zaznaczony.
Dane wysyłane między klientem a serwerem są szyfrowane.
Tak Tak Tak Certyfikat serwera nie jest sprawdzany.
Dane wysyłane między klientem a serwerem są szyfrowane.

W przypadku korzystania z szyfrowania połączeń, nazwa (lub adres IP) w głównej nazwie podmiotu (CN) lub w alternatywnej nazwie podmiotu (SAN) w certyfikacie TLS/SSL programu SQL Server powinna dokładnie odpowiadać nazwie serwera (lub adresowi IP) określonej w parametrach połączenia. Słowo HostnameInCertificate kluczowe (wersja 18.0 lub nowsza) może służyć do określenia alternatywnej nazwy używanej do dopasowania do nazw w certyfikacie TLS/SSL. Po określeniu słowa kluczowego certyfikat TLS/SSL programu SQL Server musi być zgodny z jedną z nazw serwera lub HostnameInCertificate.

Domyślnie szyfrowane połączenia zawsze weryfikują certyfikat serwera. Jeśli jednak łączysz się z serwerem z certyfikatem z podpisem własnym i nie używasz ścisłego trybu szyfrowania, możesz dodać TrustServerCertificate opcję pomijania sprawdzania certyfikatu względem listy zaufanych urzędów certyfikacji:

Driver={ODBC Driver 18 for SQL Server};Server=ServerNameHere;Encrypt=YES;TrustServerCertificate=YES  

W trybie ścisłego szyfrowania certyfikat jest zawsze weryfikowany. Jako alternatywa dla standardowej weryfikacji certyfikatów, słowo kluczowe ServerCertificate (od wersji 18.1+) może być użyte do określenia ścieżki do pliku certyfikatu, który ma być dopasowany do certyfikatu serwera SQL Server. Ta opcja jest dostępna tylko w przypadku używania ścisłego szyfrowania. Akceptowane formaty certyfikatów to PEM, DER i CER. Jeśli zostanie określony, certyfikat programu SQL Server jest sprawdzany, sprawdzając, czy podana ServerCertificate wartość jest dokładna.

Protokół TLS w systemach Linux i macOS używa biblioteki OpenSSL. W poniższej tabeli przedstawiono minimalne obsługiwane wersje biblioteki OpenSSL i domyślne lokalizacje magazynu zaufania certyfikatów dla każdej platformy:

Platforma Minimalna wersja protokołu OpenSSL Domyślna lokalizacja magazynu zaufania certyfikatów
Debian 10, 11, 12 1.1.1 /etc/ssl/certs
Debian 9 1.1.0 /etc/ssl/certs
Debian 8.71 1.0.1 /etc/ssl/certs
OS X 10.11, macOS 1.0.2 /usr/local/etc/openssl/certs
Red Hat Enterprise Linux 9 3.0.1 /etc/pki/tls/cert.pem
Red Hat Enterprise Linux 8 1.1.1 /etc/pki/tls/cert.pem
Red Hat Enterprise Linux 7 1.0.1 /etc/pki/tls/cert.pem
Red Hat Enterprise Linux 6 1.0.0-10 /etc/pki/tls/cert.pem
SUSE Linux Enterprise 15 1.1.0 /etc/ssl/certs
SUSE Linux Enterprise 11, 12 1.0.1 /etc/ssl/certs
Ubuntu 22.04, 23.04 3.0.2 /etc/ssl/certs
Ubuntu 20.04 1.1.1 /etc/ssl/certs
Ubuntu 18.04 1.1.0 /etc/ssl/certs
Ubuntu 16.04 1.0.2 /etc/ssl/certs
Ubuntu 14.04 1.0.1 /etc/ssl/certs
Alpine 3.17, 3.18 3.0.1 /etc/ssl/certs

Możesz również określić szyfrowanie w parametrach połączenia przy użyciu Encrypt opcji podczas korzystania z programu SQLDriverConnect w celu nawiązania połączenia.

Dostosowywanie ustawień Keep-Alive TCP

Począwszy od sterownika ODBC 17.4, jak często sterownik wysyła pakiety keep-alive i przesyła je ponownie, gdy nie otrzymano odpowiedzi, jest konfigurowalny. Aby skonfigurować, dodaj następujące ustawienia do sekcji sterownika w odbcinst.ini pliku lub sekcji DSN w pliku odbc.ini. Podczas nawiązywania połączenia z DSN, sterownik użyje ustawień w sekcji DSN, jeśli jest obecna; w przeciwnym razie, lub w przypadku nawiązywania połączenia tylko z ciągiem połączenia, użyje ustawień w sekcji sterownika w odbcinst.ini. Jeśli ustawienie nie jest obecne w żadnej lokalizacji, sterownik używa wartości domyślnej. Począwszy od sterownika ODBC 17.8, w łańcuchu połączenia można określić słowa kluczowe KeepAlive i KeepAliveInterval.

  • KeepAlive=<integer> określa, jak często TCP próbuje sprawdzić, czy bezczynne połączenie jest nadal aktywne, wysyłając pakiet keep-alive. Wartość domyślna to 30 sekund.

  • KeepAliveInterval=<integer> określa interwał oddzielający retransmisje utrzymywania aktywności do momentu odebrania odpowiedzi. Wartość domyślna to 1 sekunda.

Zobacz też