VM của bạn có dùng VPN của máy chủ không? Hãy kiểm tra từ bên trong guest

Bạn kiểm tra IP công khai của máy chủ, nó hiển thị VPN, và bạn kết luận rằng VM đã được bảo vệ. Kết luận đó không được phép thử này chứng minh. Guest có bảng định tuyến riêng, bộ phân giải riêng và các giao diện riêng, và địa chỉ thoát của máy chủ không nói gì về chúng.

Phép thử phải chạy bên trong guest, và phải nêu rõ nó đã đo cái gì.

Hãy bắt đầu từ bên trong guest, không phải từ trình duyệt của máy chủ

Trước tiên hãy ghi lại chế độ mạng của hypervisor: NAT, bridged, host-only hoặc macvtap. Ở chế độ NAT, máy chủ định tuyến lưu lượng của guest, nên tunnel của máy chủ có thể áp dụng hoặc không tùy vào cách client cài đặt tuyến. Ở chế độ bridged, guest là một peer ngang hàng trên LAN vật lý và tunnel của máy chủ không liên quan. Hai chế độ này cho câu trả lời trái ngược nhau từ cùng một cấu hình máy chủ.

Hãy ghi chế độ xuống trước khi bạn thay đổi bất cứ điều gì, vì chính nó quyết định kết quả có thể có nghĩa gì.

Hãy thực hiện một yêu cầu mà bạn biết đích đến

Dùng một yêu cầu vô hại tới một dịch vụ báo cáo địa chỉ nguồn mà nó đã thấy. Sau đó kiểm tra quyết định định tuyến của chính guest cho đích đó: ip route get 203.0.113.5 in ra giao diện và cổng mà guest sẽ dùng.

Nếu giao diện là NIC bình thường của guest thì lưu lượng đó không đi qua tunnel bên trong guest.

Một adapter thứ hai, một thiết lập proxy hoặc một client VPN phía guest có thể thay đổi câu trả lời cho một ứng dụng mà không thay đổi cho ứng dụng khác. Hãy kiểm tra ứng dụng mà bạn thực sự quan tâm, không phải một yêu cầu chung từ shell.

Hãy kiểm tra bộ phân giải riêng

Địa chỉ thoát thay đổi không cho bạn biết bộ phân giải nào đã xử lý tên máy chủ đó. Hãy truy vấn tên một cách tường minh bằng công cụ phù hợp với nền tảng, và ghi lại máy chủ nào đã trả lời. Split DNS nghĩa là câu hỏi về bộ phân giải và câu hỏi về định tuyến có câu trả lời khác nhau.

Hai điều đó có thể lệch nhau theo cả hai hướng, và chính sự lệch nhau đó thường là lỗi thật.

Trên một máy chủ systemd, resolvectl query nêu tên giao diện và máy chủ DNS đứng sau câu trả lời. Các cấu hình cũ hơn hiển thị máy chủ trong đầu ra của dig. Dù thế nào, điểm mấu chốt là xem máy chủ nào đã trả lời, không chỉ là có câu trả lời hay không.

Hãy kiểm tra chính sách khi thất bại, không chỉ khi thành công

Nếu yêu cầu là không có lưu lượng nào đi ra ngoài tunnel, một yêu cầu thành công không chứng minh được gì. Hãy dùng phép thử thất bại có kiểm soát mà client hỗ trợ: dừng tunnel theo cách được hỗ trợ và xem yêu cầu mới của guest có bị chặn hay không. Đừng cho rằng kill switch của client trên máy chủ bao trùm mọi cách bố trí chuyển tiếp ảo. Phạm vi được ghi trong tài liệu của nó là điều duy nhất bạn có thể dựa vào.

Một guest quay về NIC vật lý khi tunnel sập đang làm đúng điều mà chế độ NAT cho phép.

Ghi lại chế độ và phạm vi

Hãy ghi chế độ của hypervisor, giao diện và tuyến của guest, bộ phân giải, và ứng dụng bạn đã kiểm tra. Thêm cả ngày tháng, vì việc khôi phục snapshot hoặc cập nhật hypervisor có thể thay đổi cả bốn thứ.

Nếu IPv4 đi theo tunnel, hãy nói như vậy. Đừng mở rộng khẳng định sang IPv6, một không gian tên khác hoặc một VM khác trên một mạng khác.