VPN đã chuyển: vì sao máy khách OpenVPN của bạn vẫn gọi IP cũ

Nhà cung cấp đã đổi địa chỉ công khai của bạn, bạn đã cập nhật bản ghi DNS động, mà máy khách vẫn không kết nối được. Nhìn từ bên ngoài, có vẻ bản ghi chưa lan truyền. Phần lớn thời gian bản ghi vẫn đúng và máy khách gọi địa chỉ mà nó đã phân giải trước khi chuyển, vì đường hầm đang chạy và hồ sơ đã lưu mỗi thứ có ý niệm riêng về nơi máy chủ trú ngụ. Ba lớp phải khớp nhau, và chúng cập nhật theo lịch khác nhau.

Xem hồ sơ gọi đến đâu, không phải DNS nói gì

Mở kết nối bạn thực sự dùng và đọc dòng remote. Địa chỉ dạng số ở đó không bao giờ đi theo bản cập nhật tên máy chủ, dù bản ghi có đúng đến đâu.

Sau đó kiểm tra xem hồ sơ bạn đã sửa có phải là hồ sơ máy khách đã tải. Hồ sơ nhập vào là chuyện thường: một quản trị viên có thể đã sao một bản từ nhiều tháng trước và giữ phiên bản riêng, nên tệp trong thư mục tải xuống của bạn và mục trong ứng dụng có thể khác nhau. Hãy so điểm cuối trong phần chi tiết kết nối của chính máy khách trước khi bắt tay gỡ lỗi DNS.

Hai tệp, một điểm cuối — đó là phát hiện thường gặp ở đây.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Đọc lần kết nối tiếp theo của máy khách

Khởi động lại kết nối với ghi nhật ký chi tiết và đọc dòng nêu địa chỉ mà nó sẽ liên hệ. Chính giá trị đó mới quan trọng, không phải giá trị trình duyệt của bạn phân giải.

Bộ nhớ đệm của bộ phân giải vẫn có thể giữ câu trả lời cũ, và một số mạng giữ nó lâu hơn TTL của bản ghi yêu cầu. Hãy hỏi bộ phân giải mà máy khách thực sự dùng, không phải một bộ phân giải công cộng bạn đã thử từ nơi khác.

Nếu nhật ký hiển thị địa chỉ mới mà kết nối vẫn thất bại, vấn đề đã dịch chuyển: gói tin đi đâu đó và không ai trả lời. Đây là câu hỏi về trình lắng nghe, tường lửa hay chuyển tiếp cổng, và nó nằm ở phía máy chủ chứ không phải trên đường phân giải của máy khách. Hãy tách hai thất bại đó ra, vì coi một trình lắng nghe không tới được là vấn đề DNS sẽ khiến bạn đi vòng qua cùng một vòng lặp hai lần.

Biết mình đang khởi động lại kiểu nào

Không phải mọi lần khởi động lại đều giữ cùng trạng thái, nên thay đổi địa chỉ có thể hành xử khác nhau tùy cách tiến trình được tái chế. Khởi động lại mềm do tín hiệu kích hoạt giữ nhiều ngữ cảnh của phiên trước hơn, còn dừng và khởi động hoàn toàn bắt đầu lại từ cấu hình. Nếu bạn đang thử xem máy khách có phân giải lại không, bạn cần con đường bắt đầu từ cấu hình.

Các thiết lập duy trì cũng quan trọng, vì chúng được tạo ra để giữ những gì đã xác thực, chứ không phải để đuổi theo địa chỉ mới.

Phép thử sạch nhất là khởi động mới từ hồ sơ dự định, rồi nhìn dòng nhật ký nêu điểm cuối. Bất cứ điều gì bạn học được từ một phiên chỉ được giữ lại một phần đều là phát biểu về chính phiên đó.

Bốn tùy chọn và công việc riêng của chúng

remote với tên máy chủ là thiết lập khiến việc phân giải lại trở nên khả thi; một địa chỉ nguyên văn trên dòng đó loại bỏ điều này. resolv-retry kiểm soát điều gì xảy ra khi tra cứu thất bại, và 2.6 đã đặt nó thành vô hạn theo mặc định. Vì vậy thêm nó vào không thay đổi gì, và nó không bao giờ lên lịch kiểm tra định kỳ cho một câu trả lời khác. Ai nói nó thăm dò địa chỉ mới đã lẫn lộn giữa khôi phục và độ tươi mới.

persist-remote-ip nói về sự liên tục chứ không phải độ tươi mới: nó dùng lại điểm cuối đã xác thực lần cuối, qua các lần khởi động lại mềm mà nó hỗ trợ. Khi bạn đang thử một cuộc chuyển, đó là điều ngược lại với mong muốn của bạn. Hãy tắt nó cho phép thử nếu bản dựng của bạn bật nó, rồi khôi phục khi điểm cuối mới đã được chứng minh. Nếu để bật, một lần kết nối lại thành công có thể chẳng nói gì với bạn về DNS.

float chấp nhận một đối tác đã xác thực có địa chỉ thay đổi giữa phiên, và chỉ trong những cấu hình hỗ trợ điều đó. Nó không làm mới DNS, và sẽ không tự theo thay đổi của nhà cung cấp. Hãy coi nó là tính năng chịu lỗi cho các đối tác chuyển vùng, không phải cơ chế địa chỉ động cho máy chủ.

Xác nhận điểm cuối mới trước khi đổ lỗi cho máy khách

Từ bên ngoài mạng của bạn, hãy kiểm tra địa chỉ mới có trình lắng nghe trên cổng đã cấu hình và việc chuyển tiếp của nhà cung cấp trỏ tới nó. Một bản ghi A đúng cho máy không mở cổng tạo ra đúng triệu chứng mà người ta quy cho bộ nhớ đệm.

Sau đó kết nối lại và xác minh hai điều: máy khách đã xác thực với chứng chỉ máy chủ mong đợi, và phiên đến được tài nguyên bạn định tới. Thay đổi địa chỉ không hạ thấp yêu cầu danh tính, và một kết nối thành công tới điểm cuối sai còn tệ hơn một kết nối thất bại. Hướng dẫn OpenVPN 2.6 liệt kê cả bốn tùy chọn với phạm vi riêng, và đó là danh sách kiểm tra nên để cạnh hồ sơ.

Hãy giữ một đường vào máy chủ ngoài băng trước khi bạn khởi động lại đường hầm mang quyền truy cập quản trị của mình. Chỉ một biện pháp phòng ngừa đó đã ngăn phần lớn sự cố mà tình huống này tạo ra.