Vì sao chỉ một máy khách VPN kết nối sau cùng một router

Hai máy tính xách tay nằm trên cùng một mạng gia đình, và VPN của cơ quan chỉ chấp nhận đúng một trong hai. Máy thứ hai hoặc hết thời gian chờ hoặc đợi cho đến khi máy thứ nhất ngắt kết nối, và không ai chạm vào cài đặt máy khách giữa hai lần thử. Thông tin đăng nhập vẫn là thông tin đã hoạt động một phút trước, và đây là manh mối cho thấy xác thực không phải nguyên nhân hỏng. Ba cơ chế tạo ra kiểu này, và nhật ký của chính máy chủ cho biết bạn đang gặp cơ chế nào.

Đọc nhật ký cổng vào trước khi chạm vào máy khách

Bản ghi của máy chủ về hai lần thử trả lời câu hỏi đầu tiên, và trả lời theo một trong ba cách. Nếu lần thử thứ hai không bao giờ xuất hiện trong nhật ký đó, gói tin chưa bao giờ đến được bộ lắng nghe, và vấn đề thuộc về router gia đình hoặc đường đi của nhà cung cấp. Nếu nhật ký ghi nhận một lần thử và từ chối nó, đường hầm đã đến, vậy vấn đề là danh tính, giấy phép hoặc giới hạn phiên chứ không phải thứ gì trên dây. Nếu nhật ký ghi nhận một phiên thành công trong khi máy khách vẫn báo lỗi, hãy xem đường quay về hoặc việc hai máy khách được cấp cùng một địa chỉ đường hầm.

Điểm phát sóng từ điện thoại tách hai nhóm đó một cách rẻ tiền: chạy máy khách thứ hai qua dữ liệu di động trong khi máy thứ nhất vẫn kết nối. Thành công ở đó chỉ về mạng gia đình, và thất bại y hệt ở đó chỉ về cổng vào, khiến router vô can. Không kết quả nào tự nó quyết định, nhưng mỗi kết quả loại bỏ một nửa không gian tìm kiếm trong một lần thử.

Ghi lại kết quả trước khi thay đổi bất cứ điều gì, vì ba kết cục của nhật ký dẫn đến ba cách sửa không liên quan. Một ghi chú nêu rõ bạn đã thấy kết cục nào trong ba có giá trị hơn ảnh chụp màn hình lỗi máy khách.

Router làm gì với GRE và NAT-T

PPTP là thủ phạm kinh điển: kênh điều khiển là TCP 1723 trong khi đường dữ liệu là GRE, tức giao thức IP 47. Nhiều router tiêu dùng đi kèm một trình trợ giúp PPTP chỉ theo dõi một kết nối điều khiển, nên máy khách thứ hai sau cùng NAT mở kênh điều khiển của mình rồi không nhận được đường dữ liệu nào. Chuyển tiếp một cổng TCP mang số 47 không làm gì cho GRE, vì GRE là số giao thức chứ không phải cổng.

L2TP trên IPsec hoạt động khác đi theo thiết kế: IKE dùng UDP 500, việc xuyên NAT chuyển tải trọng được bảo vệ sang UDP 4500, và việc đóng gói tồn tại chính là để nhiều máy khách sau một địa chỉ có thể đến cùng một cổng vào. Thiết kế đó không ngăn cổng vào hay một hộp trung gian áp đặt giới hạn phiên theo địa chỉ, và từ ghế sofa hai thất bại trông giống nhau. Giao thức riêng của SoftEther cũng có cùng loại vấn đề: router không có chuyển tiếp hoạt động sẽ nhận máy khách đầu tiên từ mạng cục bộ và loại bỏ máy thứ hai. Hãy thử công tắc ALG hoặc chuyển tiếp của router ở cả hai vị trí, vì một trình trợ giúp viết cho máy khách cũ có thể làm hỏng các gói mà máy khách hiện tại gửi.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Giới hạn danh tính trông như giới hạn truyền tải

Router không phải nghi phạm duy nhất, và nhật ký phân biệt nó với phương án khác. Khi máy chủ OpenVPN ghim một tên chung vào một địa chỉ đường hầm, cả hai thiết bị nhận địa chỉ đó, và nếu không có duplicate-cn thì phiên mới hơn đẩy phiên cũ ra ngoài. Bật tùy chọn đó để cả hai vẫn kết nối nhưng để chúng chỉ còn một danh tính, một chứng chỉ và một quyết định thu hồi, điều này tệ hơn vẻ ngoài của nó. Thiết bị thứ hai sau đó không bao giờ có thể bị thu hồi riêng, nên một công tắc tiện lợi lặng lẽ gỡ bỏ quyền kiểm soát mà bạn có thể cần về sau.

Đọc nhật ký hệ thống của máy chủ và tệp trạng thái cùng lúc, vì một cái cho thấy quyết định xác thực và cái kia cho thấy ai đang kết nối. Hai mục có cùng tên chung và một địa chỉ ảo xác nhận va chạm danh tính chứ không phải giới hạn của router. Các cổng vào thương mại thêm giới hạn riêng, như gói chỉ cho phép một phiên đồng thời, số giấy phép hoặc quy tắc cho phép một phiên cho mỗi địa chỉ công cộng, và không cài đặt router nào thay đổi bất kỳ điều nào trong số đó.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Ghép cách sửa với mục nhật ký

Một lần từ chối trong nhật ký đòi hỏi thông tin đăng nhập riêng cho từng thiết bị, giới hạn cao hơn từ người vận hành dịch vụ, hoặc một điểm cuối cổng vào thứ hai cho một máy. Nếu không lần thử thứ hai nào đến được máy chủ, cách sửa lâu dài là một router chuyển tiếp giao thức và giữ nhiều hơn một phiên, hoặc một phương thức truyền tải mà router xử lý tốt, như một luồng TCP hoặc UDP duy nhất. Chọn giữa hai điều đó là quyết định về tuổi thọ phần cứng, không phải về cài đặt máy khách.

Đừng sao chép hồ sơ của một thiết bị đang hoạt động sang máy thứ hai rồi coi là xong. Việc đó biến vấn đề kết nối thành vấn đề kiểm soát truy cập, vì một máy tính xách tay bị mất không còn phân biệt được với bản sao vẫn đang dùng. Nó cũng che giấu lỗi ban đầu, lỗi này quay lại ngay khi thiết bị thứ ba xuất hiện.

Kiểm chứng hai phiên đang sống

Kết nối cả hai thiết bị cùng lúc, chạy ứng dụng dự định trên từng máy, sau đó kết nối lại một trong hai và lặp lại. Một biểu tượng thứ hai hiện ra trong chốc lát không chứng minh được gì về lưu lượng, và một phiên rớt sau mười phút là lỗi khác với người phụ trách khác. So sánh điều máy chủ báo cáo cuối cùng với điều người dùng đã thấy, vì hai bản tường thuật này thường không khớp nhau.

Nếu cả hai phiên sống sót và mang lưu lượng, cách sửa đứng vững, và ghi chú bạn viết lúc đầu trở thành bản ghi về điều gì đã sai. Nếu chỉ một phiên sống sót, hãy quay lại bước đầu và kiểm tra xem hiện giờ bạn có kết cục nào trong ba kết cục của nhật ký, vì câu trả lời có thể đã thay đổi. Các trình trợ giúp của router có thể che giấu một vấn đề tái xuất hiện trên mạng khác, trong khi giới hạn theo địa chỉ đi theo người dùng chứ không phải thiết bị. Thử từ một mạng thứ hai là cách rẻ nhất để biết bạn thực sự đã sửa điều nào trong số đó.