Я работал над этим некоторое время, без особой удачи.
Я использую переадресацию портов, чтобы открыть порт ssh на внутренней виртуальной машине для внешнего мира (порт 8000 на хосте). Хост-машина — Ubuntu 18.04LTS, 132 ГБ оперативной памяти, ядра AMD Epic 16/4. Виртуальная машина - Debian 11.
Я использую ufw для общей защиты хоста.Соединения могут быть установлены только из сети кампуса, а внешние пользователи перед подключением должны подключиться к сети кампуса через vpn. Есть две подсети, одна — это подсеть класса B, которая покрывает весь кампус, другая — 10.0.0.0/8, которая используется VPN и Wi-Fi кампуса и маршрутизируется внутри университета. Планируемое использование среды для обучения 3-го курса ОС.
я использовал https://www.cyberciti.biz/faq/how-to-configure-ufw-to-forward-port-80443-to-internal-server-hosted-on-lan/ как основу, а так же много других страниц, не на всех помню URL.
Внутренняя частная сеть — 192.168.101.x. Я использую /etc/ufw/before.rules:
*натуральный
: ПРЕДВАРИТЕЛЬНОЕ ПРИНЯТИЕ [0:0]
# переадресовать hostIP с порта 8000 campusBSubnet на 192.168.1.101:22
# переадресовать hostIP с порта 8000 campusVPNSubnet на 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
# настроить маршрутизацию
-A POSTOUTING -s 192.168.101.0/24 ! -d 192.168.101.0/24 -j МАСКАРАД
СОВЕРШИТЬ
... остальное перед.правилами
Одной из модификаций упомянутой веб-страницы было добавление ограничения исходного адреса, поскольку правило *nat, казалось, обходило запрет ufw по умолчанию и разрешало внешнему адресу доступ к переадресованному порту.
Это работает и позволяет мне подключаться к виртуальной машине по ssh извне с помощью ssh -p 8000 HostName. Кажется, все работает хорошо, за исключением того, что x2go вообще не работает. Появляется начальный дисплей (и диалоговое окно с запросом пароля root для создания устройства цветного дисплея), а после этого нет ответа. Клиент x2go жалуется на отсутствие ответа через x секунд, где x составляет ~30 секунд.
Я переместил виртуальную машину на мостовой интерфейс, дал ей внешний IP-адрес и подключился напрямую к виртуальной машине через мост. Все работает нормально.На интерфейсе x2go есть небольшой лаг, но не особо заметный, а вот на приватной сети нада. Я провел несколько сравнений скорости, используя scp для копирования большого файла на виртуальную машину и с нее как на мосту, так и через переадресацию портов, и, хотя переадресация портов была немного медленнее, разница в скорости для основной части была менее 10%. перевод.
Я немного в недоумении, почему должна быть такая разница в производительности между вариантом переадресации портов и мостовой версией. Это тест перед настройкой на сервер с 192 Гб ОЗУ и 180 ядрами для корса. Мы будем запускать примерно 90 vms за раз из 180 (два лабораторных сеанса), и мы действительно не можем выдать 180 адресов ipv4 только для одного курса, поэтому конфигурация моста на самом деле не вариант.
Кажется, что у x2go есть множество вариантов, и я действительно не рассматривал ни один из них, поэтому, если это возможное решение, я бы не стал искать указатель на то, какие из многих вариантов доступны.
Основываясь на одной из предыдущих страниц (которая была либо ошибкой сервера, либо переполнением стека), было указано, что встроенный NAT libvirt вызывает проблемы с переадресацией портов, поэтому я использовал маршрутизируемую частную сеть и третье правило маршрутизации сообщений на рисунке выше. Те же проблемы с производительностью.
Прямо сейчас моя стратегия резервного копирования — это визуальный студийный код с использованием опции ssh для редактирования на внешней машине, компиляции и запуска на виртуальной машине. Кажется, это отлично работает с переадресацией портов ssh.
Спасибо.
