Моя цель - иметь возможность подключаться с помощью удаленного рабочего стола на моем настольном компьютере к Windows XP, работающей в виртуальном боксе на моем сервере Linux.
Моя установка:
Моя проблема: если я пытаюсь использовать удаленный рабочий стол на своем домашнем компьютере, я не могу подключиться к гостевой системе Windows. Если я сначала "ssh -X -C" подключусь к серверу debian, а затем запустил "rdesktop 192.168.1.100", я смогу подключиться без проблем. Брандмауэр Windows был настроен так, чтобы разрешать подключения к удаленному рабочему столу, и я даже отключил его (поскольку здесь он избыточен), чтобы проверить, была ли это проблема, но это не имело значения.
Поскольку я могу подключаться изнутри локальной подсети, я подозреваю, что я неправильно настроил свой брандмауэр debian для обработки подключений извне локальной сети. Вот что я сделал ...
Сначала мой статус ufw:
ufw status
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
80 ALLOW Anywhere
3389 ALLOW Anywhere
Я отредактировал /etc/ufw/sysctl.conf и добавил:
net/ipv4/ip_forward=1
Отредактировал / etc / default / ufw и добавил:
DEFAULT_FORWARD_POLICY="ACCEPT"
Отредактировал /etc/ufw/before.rules и добавил:
# setup port forwarding to forward rdp to windows VM
*nat
:PREROUTING - [0:0]
-A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.100
-A PREROUTING -i eth0 -p udp --dport 3389 -j DNAT --to-destination 192.168.1.100
COMMIT
# Don't delete these required lines, otherwise there will be errors
*filter
<snip>
Перезапустил брандмауэр и т. Д., Но соединения нет.
Мои файлы журнала на хосте debian показывают это (мой общедоступный IP-адрес был удален для этой публикации, но он верен в фактическом журнале):
Feb 6 11:11:21 localhost kernel: [171991.856941] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Feb 6 11:11:21 localhost kernel: [171991.856963] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Feb 6 11:11:24 localhost kernel: [171994.856701] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Feb 6 11:11:24 localhost kernel: [171994.856723] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Feb 6 11:11:30 localhost kernel: [172000.856656] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Feb 6 11:11:30 localhost kernel: [172000.856678] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0
Хотя это текущая установка / конфигурация, я также пробовал несколько вариантов этого; Я подумал, что, возможно, интернет-провайдер по какой-то причине заблокирует 3389, и попытался использовать другие порты, но снова не было соединения.
Любые идеи...? Я где-то забыл изменить какой-то файл?
Это решило это для меня:
sudo ufw allow proto tcp from 192.168.1.100 to any port 22
Проблема в том, что ответ был заблокирован. Надеюсь, это кому-то поможет.
Я на самом деле не привередничать с этим, но вам нужно управлять «межсетевым экраном» IPTAbles с помощью чего-то лучшего, чем UFW.
Это хорошо для настольных компьютеров, но предназначено именно для этого, а не для «серверного» использования.
Я настоятельно рекомендую сесть и потратить некоторое время на изучение того, как работает NetFilter / IPTables, и научиться пользоваться этими командами напрямую. Если вы боитесь, что что-то сломаете, создание резервных копий конфигурации IPTables перед изменениями или, возможно, даже базовая настройка управления версиями Git поможет вам поэкспериментировать и обрести уверенность.
Не уверен, что вам все еще нужна помощь. У меня была точно такая же проблема, и проблема была довольно простой. На целевом сервере не было записи о шлюзе по умолчанию, и ответы на него не возвращались. После установки шлюза по умолчанию все прошло нормально. Вы можете проверить свою маршрутизацию, набрав route -n (с -n позволяет избежать трудоемкого поиска DNS для каждой записи).
Я просто сделал: ufw allow to [IP-адрес виртуальной машины]