Tôi đã làm việc này trong một thời gian, không gặp nhiều may mắn.
Tôi đang sử dụng chuyển tiếp cổng để hiển thị cổng ssh trên máy ảo nội bộ ra thế giới bên ngoài (cổng 8000 trên Máy chủ). Máy chủ là Ubuntu 18.04LTS, ram 132 GB, lõi AMD Epic 16/4. Máy ảo là Debian 11.
Tôi đang sử dụng ufw để bảo vệ chung cho máy chủ.Các kết nối chỉ có thể được thực hiện từ mạng của trường và người dùng bên ngoài phải vpn vào mạng của trường trước khi kết nối. Có hai mạng con, một là mạng con lớp B bao phủ toàn bộ khuôn viên, mạng còn lại là 10.0.0.0/8 được sử dụng bởi vpn và wifi của khuôn viên trường và được định tuyến bên trong trường đại học. Việc sử dụng môi trường theo kế hoạch là để giảng dạy khóa học OS năm thứ 3.
tôi đã sử dụng https://www.cyberciti.biz/faq/how-to-configure-ufw-to-forward-port-80443-to-internal-server-hosted-on-lan/ làm cơ sở, cũng như nhiều trang khác, không phải trang nào tôi cũng nhớ địa chỉ URL.
Mạng riêng nội bộ là 192.168.101.x. /etc/ufw/b Before.rules tôi đang sử dụng là:
*tự nhiên
:CHẤP NHẬN TRƯỚC [0:0]
# chuyển tiếp hostIP từ cổng campusBSubnet 8000 sang 192.168.1.101:22
# chuyển tiếp hostIP từ cổng campusVPNSubnet 8000 thành 192.168.1.101:22
-A PREROUTING -i br0 -d HostIP -s campusBSubnet -p tcp --dport 8000 -j DNAT --to-destination 192.168.101.2:22
-A PREROUTING -i br0 -d HostIP -s campusVPNSubnet -p tcp --dport 8000 -j DNAT --to-destination 192.168.101.2:22
# thiết lập định tuyến
-A POSTROUTING -s 192.168.101.0/24 ! -d 192.168.101.0/24 -j MẶT MẠO
LÀM
... phần còn lại của before.rules
Một sửa đổi từ trang web được tham chiếu là bổ sung giới hạn địa chỉ nguồn vì quy tắc *nat dường như bỏ qua từ chối mặc định ufw và cho phép địa chỉ bên ngoài truy cập vào cổng được chuyển tiếp.
Điều này hoạt động và cho phép tôi ssh vào VM từ bên ngoài với ssh -p 8000 HostName. Mọi thứ dường như hoạt động tốt, ngoại trừ việc x2go không thực sự hoạt động. Màn hình ban đầu hiển thị (và một hộp thoại yêu cầu mật khẩu gốc để tạo Thiết bị hiển thị màu), và sau đó, không có phản hồi. Ứng dụng khách x2go phàn nàn về việc không có phản hồi sau x giây, trong đó x là ~30 giây.
Tôi đã chuyển vm sang giao diện cầu nối và đặt cho nó một địa chỉ IP bên ngoài, đồng thời kết nối trực tiếp với vm qua cầu nối. Mọi thứ đều hoạt động tốt.Có một chút độ trễ trên giao diện x2go, nhưng không thực sự đáng chú ý, nhưng trên mạng riêng nada. Tôi đã thực hiện một số so sánh tốc độ bằng cách sử dụng scp để sao chép một tệp lớn đến và từ VM cả trên cầu nối và thông qua chuyển tiếp cổng, và trong khi chuyển tiếp cổng chậm hơn một chút, tốc độ của nó chênh lệch ít hơn 10% đối với số lượng lớn chuyển khoản.
Tôi hơi thắc mắc tại sao lại có sự khác biệt về hiệu suất như vậy giữa tùy chọn chuyển tiếp cổng và phiên bản bắc cầu. Đây là thử nghiệm trước khi thiết lập trên máy chủ có 192 GB ram và 180 lõi cho corse. Chúng tôi sẽ chạy khoảng 90 vms tại một thời điểm trong số 180 (hai phiên phòng thí nghiệm) và chúng tôi thực sự không thể cung cấp 180 địa chỉ ipv4 chỉ cho một khóa học, vì vậy cấu hình cầu không thực sự là một tùy chọn.
Dường như có rất nhiều tùy chọn cho x2go và tôi thực sự chưa xem xét bất kỳ tùy chọn nào trong số đó, vì vậy nếu đó là một giải pháp khả thi, tôi sẽ không khai thác con trỏ tới tùy chọn nào trong số nhiều tùy chọn khả dụng.
Dựa trên một trong những trang trước đó (lỗi máy chủ hoặc tràn ngăn xếp) chỉ ra rằng NAT libvirt tích hợp gây ra sự cố với chuyển tiếp cổng, vì vậy tôi đã sử dụng mạng riêng được định tuyến và quy tắc định tuyến bài đăng thứ ba trong hình trên. Các vấn đề về hiệu suất giống nhau.
Hiện tại, chiến lược sao lưu của tôi là mã phòng thu trực quan bằng cách sử dụng tùy chọn ssh để chỉnh sửa trên máy bên ngoài, biên dịch và chạy trên vm. Điều này dường như hoạt động tốt qua chuyển tiếp cổng ssh.
Cảm ơn.
