Hai ứng dụng khách chạy cùng lúc, mỗi bên tin rằng mình sở hữu tuyến mặc định, và triệu chứng đến dưới dạng một điều kỳ lạ: một ứng dụng của khách hoạt động, ứng dụng kia phân giải sai chỗ. Một VPN bên trong khách và một VPN trên máy chủ có thể cùng tồn tại, nhưng chỉ khi đường đi bên ngoài và chính sách bên trong đồng ý về việc ai chở cái gì. Khởi động cả hai không tự tạo ra một chuỗi. Ghi lại cách gắn kết trước, rồi đổi từng thứ một.

Ghi lại cách gắn kết của khách trước

Khách đến máy chủ VPN của mình qua con đường mà hypervisor đã cấp: NAT phía sau máy chủ, một cầu nối vào phân đoạn vật lý hoặc một mạng chỉ dành cho máy chủ có thêm định tuyến ở trên. Mỗi cách gắn kết thay đổi những gì khách có thể thấy và những gì máy chủ có thể làm với lưu lượng của nó. Dưới NAT, các gói của khách dường như đến từ máy chủ, nên đường hầm của chính máy chủ có thể chở chúng mà khách không biết gì. Dưới một cầu nối, khách có sự hiện diện riêng trên phân đoạn và cổng mặc định riêng.

Ghi lại cách gắn kết trước khi chạm vào bất kỳ cấu hình nào, cùng với việc ứng dụng khách nào phải chở ứng dụng nào. Câu đó giải quyết phần lớn các ca này, vì hai ứng dụng khách thường được xây trên những giả định khác nhau. Một khách được kỳ vọng dùng đường hầm của máy chủ không được có thêm tuyến mặc định cạnh tranh của riêng nó.

Lần theo điểm cuối của khách ra ngoài

VPN của khách cần một đường dùng được đến máy chủ của chính nó trước khi bất cứ thứ gì khác hoạt động. Khi đường hầm của máy chủ đang bật và khách ngồi sau NAT, cú bắt tay của khách đi ra qua đường hầm của máy chủ, đó hoặc là thiết kế hoặc là tai nạn mà không ai ghi lại. Khi đường hầm của máy chủ sập và khách phụ thuộc vào nó, khách mất kết nối mà không có một thay đổi nào phía mình. Lần theo điểm cuối ra ngoài cho bạn biết bạn thực sự có trường hợp nào trong hai trường hợp đó.

Một tuyến rộng trong bất kỳ bối cảnh nào cũng bắt lấy lưu lượng mà ứng dụng khách kia mong đợi. Tuyến 0.0.0.0/0 bên trong khách và một ứng dụng khách máy chủ với đường hầm đầy đủ đều đòi tất cả, và bên nào áp dụng sau cùng sẽ thắng. Sự chồng lấn giữa các mạng ảo của khách, LAN cục bộ và các mạng từ xa tạo ra cùng hiệu ứng với tiền tố riêng, với các lỗi trông giống vấn đề xác thực; hành vi dịch địa chỉ cũng là hành vi được mô tả cho mạng container.

So sánh bản ghi trước và sau

Lấy một đường cơ sở khi đường hầm của máy chủ tắt, hoặc trong bất kỳ trạng thái được kiểm soát nào mà chính sách của bạn cho phép, và ghi lại tuyến và bộ phân giải của khách. Sau đó áp dụng cấu hình kết hợp và so sánh hai bản ghi, giữ nguyên các yêu cầu về quyền riêng tư. Nếu một đường cơ sở trực tiếp không phù hợp, hãy ghi hạn chế đó vào bản ghi thay vì bỏ qua việc so sánh.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Truy vấn tuyến nêu tên giao diện và địa chỉ nguồn sẽ chở một đích cụ thể, và đó là dòng hữu ích nhất trong cuộc điều tra này. Danh sách quy tắc cho biết định tuyến theo chính sách có gửi một số đích qua bảng thứ hai hay không. Đầu ra của bộ phân giải cho biết DNS có đi theo đường hầm của khách hay ở lại trên đường của máy chủ. Chạy đúng ba lệnh đó trước và sau khi thay đổi, và phần chênh lệch sẽ nêu tên thủ phạm.

Giữ quyền sở hữu rõ ràng qua các lần khởi động lại

Hạn chế truy cập cục bộ của một ứng dụng khách máy chủ có thể chặn lưu lượng đến một NAT ảo hoặc một cầu nối, và hạn chế đó thường bị nhầm với vấn đề thông tin đăng nhập của khách. Hãy đọc hành vi được ghi lại của ứng dụng khách thay vì tắt hạn chế để một bài kiểm tra chạy qua. Sau một bản sửa được hỗ trợ, hãy kiểm tra lại ứng dụng của khách và chính sách lỗi mà bạn yêu cầu. Một máy chủ kết nối lại thành công không chứng minh được gì về tuyến hay bộ phân giải của khách.

Quyết định bên nào sở hữu tuyến mặc định và ghi điều đó vào sổ tay vận hành. Một lần khởi động lại của khách hoặc một lần chuyển mạng trên máy chủ âm thầm đảo quyền sở hữu sẽ tạo ra báo cáo lỗi về một VPN chưa bao giờ có lỗi. Cách sắp xếp phải sống sót qua lần khởi động lại mà không ai còn nhớ vì sao nó từng hoạt động.

Bài viết liên quan