MySQL localhost qua VPN: vẫn là tiến trình cục bộ

Ứng dụng trên máy chủ văn phòng kết nối tới MySQL tại localhost, bạn sao chép tên máy chủ đó vào một ứng dụng khách trên máy tính, và kết nối hoặc thất bại hoặc mở một cơ sở dữ liệu khác. VPN không thay đổi ý nghĩa của từ này: localhost vẫn chỉ máy đang chạy ứng dụng khách. VPN đã di chuyển gói tin, không phải giao diện. Hãy quyết định laptop phải tới điểm cuối nào trước khi chạm vào một tuyến đường.

Bước 1: quyết định laptop phải tới điểm cuối nào

Cả hai thiết kế đều hợp lệ và trả lời những câu hỏi khác nhau. Truy cập trực tiếp nghĩa là cơ sở dữ liệu lắng nghe trên một địa chỉ riêng mà đường hầm tới được, và laptop kết nối tới địa chỉ đó. Truy cập chuyển tiếp nghĩa là cơ sở dữ liệu ở lại trên loopback và một phiên SSH mang cổng tới máy của bạn. Hãy chọn một cách có chủ đích, vì trộn hai cách tạo ra một kết nối hoạt động vì lý do sai.

Với truy cập trực tiếp, hãy lấy tên hoặc địa chỉ riêng của chính máy chủ cơ sở dữ liệu và cổng của nó từ người quản lý nó. Địa chỉ của cổng VPN không phải địa chỉ của cơ sở dữ liệu trừ khi là cùng một máy. Sau đó xác nhận rằng trình lắng nghe thực sự được gắn vào giao diện đó, vì một tuyến đường tới một giao diện không tạo ra trình lắng nghe trên đó.

Bước 2: chỉ chuyển tiếp cổng nếu trình lắng nghe vẫn ở cục bộ

Nếu cơ sở dữ liệu phải ở lại chỉ trên loopback, hãy chuyển tiếp nó qua SSH và gắn cả đầu cục bộ vào loopback. Địa chỉ gắn bên trái thuộc về laptop của bạn; đích bên phải được hiểu từ phía máy chủ SSH, như tài liệu tham chiếu OpenSSH mô tả. Đảo ngược hai vai trò đó là lý do thường gặp khiến một chuyển tiếp có vẻ hoạt động nhưng không kết nối tới đâu.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Nếu SSH đáp xuống một máy nhảy thay vì máy chủ cơ sở dữ liệu, loopback bên phải chỉ máy nhảy, và đích phải đổi thành một địa chỉ mà máy đó tới được. ExitOnForwardFailure bắt được lỗi khi thiết lập chuyển tiếp, nhưng không chứng minh rằng các kết nối sau đó tới đích thành công. Hãy bật kiểm tra khóa máy chủ và đừng cung cấp cổng chuyển tiếp cho toàn bộ LAN của bạn bằng cách gắn nó vào mọi giao diện.

Hãy dừng nếu cơ sở dữ liệu phải ở lại chỉ trên loopback và bạn không thể dùng SSH. Khi đó truy cập trực tiếp là thiết kế sai, không phải cấu hình để ép buộc.

Bước 3: buộc ứng dụng khách dùng TCP

Trên Unix, một ứng dụng khách MySQL được cho localhost sẽ chọn một socket Unix theo mặc định, nên chỉ đổi cổng có thể khiến nó tìm một socket không liên quan gì tới chuyển tiếp của bạn. Hãy dùng giao thức TCP rõ ràng và địa chỉ loopback để ứng dụng khách mở kết nối tới cổng chuyển tiếp của bạn.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

Tùy chọn mật khẩu không có giá trị sẽ hỏi thay vì đặt bí mật trên dòng lệnh, và đó là thói quen đáng giữ. Các công cụ khác có công tắc riêng cho cùng sự phân biệt, và một số trình điều khiển cũng xử lý localhost đặc biệt. Hãy kiểm tra ứng dụng khách của bạn làm gì thay vì giả định rằng cờ đã được chuyển sang. Tài khoản cơ sở dữ liệu cũng cần một quyền khớp với nguồn mà máy chủ thấy, và đó là máy chủ chuyển tiếp chứ không phải laptop của bạn.

Hãy dừng nếu không thể buộc công cụ dùng TCP. Khi đó dùng ứng dụng khách khác, hoặc dùng truy cập trực tiếp tới trình lắng nghe riêng.

Bước 4: chứng minh bạn thực sự đã tới điểm cuối nào

Hỏi máy chủ xem nó nghĩ kết nối là gì. Các biến tên máy chủ, cổng và socket cho bạn biết bạn đã tới qua TCP chưa và trình lắng nghe nào đã trả lời, và danh sách kết nối hiển thị địa chỉ nguồn mà máy chủ đã ghi. Bằng chứng đó hữu ích hơn một lần đổi tuyến đường nữa.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Ghi lại điểm cuối bạn đã thử: một socket Unix cục bộ, cổng chuyển tiếp của bạn hoặc trình lắng nghe riêng. Ba thất bại đó có cách khắc phục khác nhau, và đổi tuyến đường VPN khi ứng dụng khách vẫn nói chuyện với localhost sai là công sức lãng phí. Hãy giữ riêng trong ghi chú cả xác thực SSH và xác thực cơ sở dữ liệu, vì từ một ứng dụng khách trên máy tính, thất bại ở cái này trông giống thất bại ở cái kia. Sau đó hãy gỡ chuyển tiếp khi bạn xong việc.

Danh sách kết thúc khi bạn có thể nêu điểm cuối, giao thức của ứng dụng khách, địa chỉ nguồn mà máy chủ đã thấy và quyền đã cho phép điều đó. Bốn sự thật, và vấn đề kết nối tiếp theo mất vài phút thay vì cả buổi chiều.