Открытие порта для xrdp

А чуть ниже в логе написано «Failed to start xrdp daemon, possibly address already in use.» но ты не стал этого постить сюда, так как это не важно?

Походу xrdp не будте биднится на привилегированный порт. https://askubuntu.com/questions/1337571/xrdp-port-changing-issue

Либо оставить порт >1024 и делать DNAT/REDIRECT в iptables на порт 126, либо CAP_NET_BIND_SERVICE на бинарник (и так при каждом обновлении) https://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-proces...

Походу xrdp не будте биднится на привилегированный порт

Да с какого такого фига сервис будет сам решать куда ему биндиться, а куда нет.

Подскажите, пожалуйста, подробнее. А текст ошибки полностью конечно выложу. Просто показалось что будет нечитаемо..

Active: failed (Result: exit-code) since Wed 2021-08-11 11:14:50 +05; 19min ago Docs: man:xrdp(8) man:xrdp.ini(5) Process: 17385 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS) Process: 17414 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=1/FAILURE)

авг 11 11:14:50 debian systemd[1]: Starting xrdp daemon… авг 11 11:14:50 debian xrdp[17414]: (17414)(140063791548224)[DEBUG] Testing if xrdp can listen on 0.0.0.0 port 126. авг 11 11:14:50 debian xrdp[17414]: (17414)(140063791548224)[ERROR] g_tcp_bind(7, 126) failed bind IPv6 (errno=13) and IPv4 (errno=22). авг 11 11:14:50 debian xrdp[17414]: (17414)(140063791548224)[DEBUG] Closed socket 7 (AF_INET6 :: port 0) авг 11 11:14:50 debian xrdp[17414]: (17414)(140063791548224)[ERROR] Failed to start xrdp daemon, possibly address already in use. авг 11 11:14:50 debian systemd[1]: xrdp.service: Control process exited, code=exited, status=1/FAILURE авг 11 11:14:50 debian systemd[1]: xrdp.service: Failed with result ‘exit-code’. авг 11 11:14:50 debian systemd[1]: Stopped xrdp daemon.

ss -nltp | grep 126

или

netstat -nltp | grep 126

Очень странно. Ведь задача тривиальная. Просто подсоединяться к внешнему ip по измененному порту (был 3389 стал 126).

Сделал.

artur@debian:~$ ss -nltp | grep 126 artur@debian:~$ netstat -nltp | grep 126 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) artur@debian:~$ ^C artur@debian:~$ sudo netstat -nltp | grep 126 [sudo] пароль для artur: artur@debian:~$

так,

во-первых, все эти штуки , включая старт сервиса, и команды, которые я дал, делаем из под рута.

во-вторых,https://www.linux.org.ru/help/markdown.md

Еще после изменения порта в xrdp.ini и перезапуске xrdp командой sudo /etc/init.d/xrdp restart выходит ошибка:

Restarting xrdp (via systemctl): xrdp.serviceJob for xrdp.service canceled. failed!

Про разметку понял. Через sudo две Ваши команды выполнились. Но при рестарте ошибка осталась. И при запросе статуса тоже. Увы.

команды ничего не показали? Значит порт свободен, хм

Пишут, что в может помочь в конфиге use_vsock = false

типа что-то там после обновления стьало плохо

Да, но в конфиге он уже стоит false:

[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=126
; 'port' above should be connected to with vsock instead of tcp
use_vsock=false

Да, команды не вывели ничего.

сорри, это внутренние заморочки xrdp, в гугле много по этому поводу, но у меня нет времени и желания это копать.

Может кто-то другой поможет

Да, это ограничение xrdp на использование портов ниже 1024. Как вариант анонимусом уже предлагалось редиректить.

-A PREROUTING -i eth0 -p tcp -m tcp –dport 126 -j REDIRECT –to-ports 3389.

А если не хочется светить 3389, то слушать соединения на локалхосте и редиректить на него. Вариантов масса.

Как программист напишет, так и будет, но xrdp сам, насколько я понял по коду, не решает на какой порт можно биндится, а на какой нельзя. Однако, «Б-безопасность», xrdp сейчас работает от пользователя ″xrdp″, от пользователя ″root″ работает процесс xrdp-sesman, так прописано в сервисах systemd. https://sources.debian.org/src/xrdp/0.9.1-9 deb9u3/instfiles/xrdp.service/

Не root процесс не может биндится на порт <1024, по какой логике ядро при этом возвращает ошибку EINVAL, а не, допустим, EACCES мне неведомо.

Решение с iptables -j REDIRECT, ИМХО, лучшее. authbind как-то костыльно, CAP_NET_BIND_SERVICE сломается при обновлении...

Как программист напишет, так и будет

Это понятно. Я имел ввиду, что он процесс не может указывать системе, что ему надо запретить какие-то порты. А система не может указывать руту. На том стояли и стоять будем:)

Не root процесс не может биндится на порт <1024

Я, конечно,не выяснял,от какого юзера оно работает. ок