Hypervisor trong phòng thí nghiệm tại nhà không truy cập được qua VPN: nên xem ở đâu

Đường hầm đi lên, trang web của hypervisor hết thời gian chờ, và máy khách nói rằng nó đã kết nối. Sự kết hợp đó loại trừ rất nhiều thứ: bắt tay VPN hoạt động, máy khách có địa chỉ, và điểm cuối có thể truy cập được. Những gì còn lại là một danh sách ngắn các câu hỏi về định tuyến và chính sách, và chúng có thứ tự tự nhiên. Hãy xử lý chúng từ hypervisor ra ngoài chứ không phải từ máy khách vào trong, vì trạng thái của chính hypervisor là thứ rẻ nhất để xác nhận.

Bắt đầu với phân đoạn quản trị

Xác nhận địa chỉ quản trị của hypervisor và dịch vụ đang lắng nghe trên đó, và xác nhận rằng trang tải được từ một máy chủ khác trong phân đoạn đó trước khi chẩn đoán bất cứ điều gì từ xa. Một thử nghiệm cục bộ thất bại không phải là vấn đề VPN, và đó là kiểm tra năm phút tiết kiệm một giờ.

Sau đó là hai đường. Máy khách VPN cần một tuyến đến mạng quản trị, điều này thường có nghĩa là AllowedIPs của máy khách hoặc các tuyến được đẩy bao gồm mạng con đó. Hypervisor, hoặc cổng mặc định của nó, cần một đường quay về bể địa chỉ máy khách, trừ khi thiết kế cố ý dịch địa chỉ nguồn ở lối vào. Đây là hai sự kiện riêng biệt và thiếu một trong hai sẽ tạo ra cùng một thời gian chờ. Kiểm tra riêng: ip route get 192.168.10.20 trên máy khách, và một bản bắt gói trên máy chủ hypervisor cho thấy gói tin có đến hay không.

Cho phép quản trị viên từ xa thực sự

Phân quyền là câu hỏi riêng so với khả năng truy cập. Hãy dùng chính sách cổng và máy chủ giới hạn ở các nguồn và dịch vụ cần quyền truy cập quản trị. Một tài khoản VPN khách chỉ cần một ứng dụng thí nghiệm không nên vì thế mà đến được mặt phẳng quản trị, và một quy tắc phẳng cho phép toàn bộ mạng con của đường hầm là cách điều đó xảy ra.

Giữ bật xác thực của chính hypervisor và kiểm tra chứng chỉ. Một tuyến riêng không phải lý do để bấm qua một cảnh báo danh tính bất ngờ.

Cảnh báo đáng được coi là phát hiện chứ không phải trở ngại. Nếu chứng chỉ không khớp với tên bạn đã dùng, thì hoặc tên sai hoặc dịch vụ không phải là thứ bạn nghĩ, và cả hai câu trả lời đều quan trọng trên giao diện quản trị hơn bất cứ nơi nào khác. Hãy truy cập trang bằng tên mà chứng chỉ được cấp, và để DNS trỏ tên đó tới địa chỉ đường hầm. Một tên riêng được phân giải không nhất quán giữa LAN và đường hầm là nguyên nhân phổ biến của các phàn nàn về chứng chỉ trông giống như lỗi VPN.

Kiểm tra các kết nối phụ

Một số tính năng dùng các kết nối mà trang web không dùng. Một phiên giao diện điều khiển, một lần tải ISO, một proxy VNC hoặc SPICE và một kênh di chuyển đều có thể dùng cổng khác hoặc địa chỉ máy chủ khác. Khi trang tải được mà một tính năng thất bại, hãy đọc yêu cầu của sản phẩm đó thay vì mở mọi cổng trên máy chủ.

Mở tất cả là cách một giao diện quản trị trở thành không được quản trị. Mỗi cổng thêm là một trình lắng nghe nữa phải được vá, và một hypervisor đã phơi ra đủ nhiều. Xác định kết nối cụ thể mà tính năng cần, xác nhận nó truy cập được qua đường hầm, và để phần còn lại đóng. Nếu tính năng khăng khăng đòi kết nối trực tiếp tới một địa chỉ máy chủ không thể định tuyến qua đường hầm của bạn, đó là một ràng buộc thiết kế phải lách có chủ ý, không phải lý do để chuyển tiếp một dải.

Giữ một đường quay về trước khi chạm vào mạng

Trước khi thay đổi mạng ảo mang chính VPN của bạn, hãy xác nhận rằng bạn có một đường quay về cục bộ hoặc độc lập.

Điều này quan trọng nhất trong phòng thí nghiệm tại nhà, vì điểm cuối VPN thường là một máy ảo trên chính hypervisor mà bạn đang cố truy cập. Thay đổi một switch ảo, một cầu nối hoặc một quy tắc tường lửa từ xa có thể xóa tuyến bạn đang dùng, và phiên có thể tồn tại đủ lâu để bạn thấy điều đó xảy ra.

Hãy thử từ bên ngoài phòng thí nghiệm chứ không phải từ LAN, và xác minh cả các lần từ chối cũng như các lần cho phép. Một mạng phải tiếp tục không truy cập được từ đường hầm thì phải tiếp tục như vậy sau thay đổi của bạn, và đó là một khẳng định riêng so với việc trang quản trị tải được. Ghi lại cả hai kết quả, vì kết quả thứ hai là cái bị bỏ qua và là cái quan trọng khi phòng thí nghiệm lớn lên.

Bản ghi cần giữ rất ngắn: địa chỉ và dịch vụ quản trị, tuyến mà mỗi bên cần, các danh tính được phép đến, và đường khôi phục. Thế là đủ để người tiếp theo tái tạo trạng thái hoạt động mà không phải suy ra lại.

Nếu trang vẫn hết thời gian chờ sau tất cả những điều đó, hãy bắt gói trên hypervisor và tìm gói tin trước khi thay đổi thêm một quy tắc nữa. Một gói tin không bao giờ đến là câu hỏi về định tuyến hoặc tường lửa; một gói tin đến và bị từ chối là câu hỏi về dịch vụ hoặc chính sách; một gói tin đến và được trả lời trong khi máy khách chờ là câu hỏi về đường quay về. Tài liệu của strongSwan về chuyển tiếp giải thích cách một cổng Linux chuyển tiếp lưu lượng đường hầm tới một máy chủ nội bộ. Ba lần bắt gói thắng một phỏng đoán nữa.