Phòng thí nghiệm VPN trên VirtualBox: VM cổng hay mạng chỉ dành cho máy chủ

Bạn cần quyết định phòng thí nghiệm VPN của mình xứng đáng với bao nhiêu máy móc. Một VM cổng được định tuyến giữa hai phân đoạn VirtualBox sẽ tái tạo việc dịch địa chỉ, đường quay về và vị trí tường lửa mà một máy khách thật ngồi sau. Một phân đoạn chỉ dành cho máy chủ cho bạn một cánh cửa được kiểm soát và không gì khác. Bản có cổng cần ba khách và một bảng định tuyến do bạn duy trì; bản chỉ máy chủ cần một khách và một chính sách. Ba câu hỏi phân biệt hai bản, và câu thứ ba quyết định liệu bài kiểm tra của bạn có thể qua được hay không.

Trả lời ba câu hỏi trước khi nhân bản bất cứ thứ gì

Hãy bắt đầu từ điều máy chủ VPN phải quan sát. Nếu máy chủ phải thấy một địa chỉ nguồn không phải của khách kiểm thử, thì phải có thứ gì đó dịch giữa hai bên, và thứ đó phải là một router do bạn kiểm soát. Mạng chỉ dành cho máy chủ cấp cho máy chủ một card mạng trên phân đoạn của khách, không phải một bộ dịch. Khi khách cần chạm tới thứ gì đó bên ngoài, bạn gắn một card NAT, và chính engine NAT của VirtualBox sẽ ghi lại địa chỉ nguồn mà không hỏi bạn.

Tiếp theo, hỏi xem khách có được chạm tới bất cứ thứ gì khác ngoài đường hầm không. Câu trả lời đó chọn mạng nội bộ hay chỉ máy chủ, và đây chính là câu mà phần lớn bài viết về phòng thí nghiệm bỏ qua. Cuối cùng, hỏi điều gì phải xảy ra khi đường hầm sập, vì nó quyết định chính sách chứ không phải cấu trúc liên kết, và một phòng thí nghiệm chỉ chứng minh con đường may mắn thì gần như chưa kiểm tra gì.

Nối ba vai trò bằng mạng nội bộ

Dùng ba khách và hai phân đoạn có tên, với cổng là máy duy nhất có card mạng trên cả hai:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Không có bước tạo riêng cho mạng nội bộ. Chuỗi trong --intnet1 chính là phân đoạn: hai máy chỉ chia sẻ nó khi tên khớp chính xác, và không có gì trên máy chủ được nối vào đó. Chính đặc tính cuối cùng này khiến phòng thí nghiệm lặp lại sạch sẽ, vì các tuyến của máy chủ, máy khách VPN của nó và tường lửa của nó không thể vô tình chạm tới các khách. Phân đoạn nội bộ cũng không có máy chủ DHCP trừ khi bạn thêm một cái, nên địa chỉ tĩnh là con đường ngắn nhất.

Chỉ cấp cho máy khách địa chỉ WAN của nó, với cổng mặc định trỏ tới địa chỉ WAN của cổng. Máy chủ nhận một địa chỉ LAN và dùng địa chỉ LAN của cổng làm cổng mặc định của mình. Một khách giữ hai địa chỉ trên cùng một phân đoạn, hoặc có một tuyến lạc sang phân đoạn kia, sẽ có đường vòng qua router, và các bài kiểm tra bên dưới sẽ nói dối bạn.

Tôi giữ một tệp văn bản bên cạnh tên các VM ghi bốn địa chỉ và hai tên phân đoạn, và dán nó vào mọi shell. Nhiều tuần sau, khi một thay đổi cấu hình làm hỏng thứ gì đó, tệp ấy chính là khác biệt giữa gỡ lỗi cấu hình và gỡ lỗi trí nhớ của chính tôi.

Chọn nội bộ hoặc chỉ máy chủ cho phân đoạn không được rò rỉ

Chế độ chỉ máy chủ tạo một card mạng ảo ngay trên máy chủ, thường là vboxnet0, và cấp cho máy chủ một địa chỉ trên phân đoạn của khách. Điều đó tiện cho quản trị và chết người với bài kiểm tra cách ly, vì máy chủ giờ có thể chạm tới khách trực tiếp và mọi dịch vụ phía máy chủ đều trở thành một con đường khả dĩ. Chế độ nội bộ không có card mạng máy chủ nào cả. Hai chế độ dễ bị nhầm trong bảng cài đặt mạng, nên hãy kiểm tra khác biệt đã được ghi tài liệu thay vì nhãn (xem trang chi tiết mạng của VirtualBox).

Với một khách buộc phải dùng đường hầm, mạng nội bộ là mặc định an toàn hơn, với cổng là lối ra duy nhất. Nếu bạn giữ chỉ máy chủ, hãy coi card mạng của máy chủ là đường quản trị và nói to điều đó: máy chủ được chạm tới khách, và khách không được phép dùng máy chủ làm lối ra.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Cách ly bạn chứng minh được chính là cách ly bạn đã cấu hình. Một khách có một card nội bộ, tuyến mặc định ở cổng và không có card NAT thì không có đường nào vòng qua cổng. Một khách có card chỉ máy chủ và card NAT có hai con đường, và chỉ một trong đó là con đường bạn định kiểm tra.

Định tuyến và dịch tại cổng, rồi để nó thất bại theo hướng đóng

VirtualBox không chuyển tiếp giữa các phân đoạn; khách làm việc đó. Khi VM máy chủ VPN nằm sau cổng, hãy bật chuyển tiếp và dịch lưu lượng của máy khách khi nó đi ra phía máy chủ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Với quy tắc đó, máy chủ thấy địa chỉ LAN của cổng thay vì của máy khách, và đó chính là dáng vẻ của một máy khách thật sau NAT của nhà mạng đối với một đầu mạng. Hãy lưu giá trị sysctl trong /etc/sysctl.d/ và quy tắc trong dịch vụ tường lửa mà bản phân phối dùng, nếu không một lần khởi động lại sẽ lặng lẽ đưa phòng thí nghiệm về trạng thái đã định tuyến nhưng chưa dịch.

Chuyển tiếp không phải là cấp quyền. Dưới chính sách FORWARD mặc định với giá trị ACCEPT, một khách có tuyến mặc định trỏ tới cổng sẽ đi ra qua card mạng mà bảng định tuyến chọn, dù có đường hầm hay không. Nếu cổng còn có một card NAT để cài gói, card đó là một lối ra không mã hóa vẫn hoạt động đúng vào lúc đường hầm sập, và bài kiểm tra chỉ-VPN của bạn chưa bao giờ là bài kiểm tra chỉ-VPN.

Khi máy chủ ở xa và chính cổng kết thúc đường hầm, cùng quyết định đó trỏ tới card mạng của đường hầm, không phải card mạng chạm tới internet:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Giữ riêng phần vận chuyển bên ngoài của chính đường hầm và một đường quản trị ngoài băng so với lưu lượng được chuyển tiếp. Nếu cách duy nhất để sửa cổng là đi qua chính đường hầm bạn đang gỡ lỗi, phòng thí nghiệm trở thành một bài tập tự khóa mình ngoài cửa. Một console nối tiếp, một card quản trị chỉ máy chủ hoặc một ảnh chụp trạng thái tốt đã biết đều rẻ hơn việc tự tay cứu một router hỏng.

Kiểm chứng đường đi từ phía khách, không phải từ phía máy chủ

Hãy làm việc từ trong ra ngoài. Xác nhận máy khách chạm tới địa chỉ WAN của cổng, rồi tới máy chủ qua cổng, rồi kết nối tới cổng VPN đi ra và quay về. Bắt gói trên cả hai card mạng của cổng cho thấy câu trả lời có tới hay bị bỏ ở đường quay về, điều mà bắt gói chỉ trên máy khách không phân biệt được:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Rồi chứng minh lối ra. Hỏi từ phía khách một dịch vụ phản chiếu địa chỉ xem nó thấy nguồn nào và so với địa chỉ ra của chính cổng; nếu câu trả lời khớp với địa chỉ của máy chủ thì tồn tại một đường vòng qua đường hầm. Kiểm tra xem khách thực sự dùng bộ phân giải nào, và kiểm tra IPv6 riêng, vì một phân đoạn bật IPv6 trong khi đường hầm chỉ mang IPv4 là rò rỉ theo thiết kế chứ không phải ngẫu nhiên.

Cuối cùng, hãy phá nó một cách có chủ ý. Dừng đường hầm, hoặc chặn cổng ngoài của nó, rồi mở một kết nối mới từ phía khách. Nó phải thất bại, và lý do phải là thứ bạn gọi được tên: không có tuyến, có một quy tắc từ chối, hoặc bộ phân giải đã chết. Khởi động lại đường hầm và xác nhận khách hồi phục mà không phải dựng lại mạng. Nếu một VPN dạng lưới như Hamachi hay ZeroTier chia sẻ phòng thí nghiệm, hãy nhớ rằng card mạng được bắc cầu đi theo tên card mạng chứ không theo lưới, nên cầu phải được trỏ lại sau khi máy khách cài card mạng ảo của riêng nó.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Chia sẻ đường hầm của khách với máy chủ chỉ phản chiếu lại vấn đề. Trỏ tuyến mặc định của máy chủ vào khách thì hiệu quả, và một proxy bên trong khách cũng vậy; NAT qua máy chủ không mang đường hầm của khách cho lưu lượng do máy chủ khởi phát. Hãy lưu tên phân đoạn và quy tắc tường lửa ở một chỗ, chụp ảnh trạng thái đang chạy được, và ghi lại địa chỉ nguồn mà máy chủ quan sát. Khi đó thay đổi cấu hình tiếp theo chỉ tốn một lần chạy script thay vì một phòng thí nghiệm dựng lại.