Подключение через RDP по 135 порту
 

Здравствуйте!
Можно ли подключиться с помощью протокола RDP по 135-му порту?
Сижу за файрволом, все остальные порты закрыты, кроме стандартного. Но стандартный не подходит из-за моей специфики.
Я подключаюсь не к физическому хосту, а к виртуальной машине на базе VirtualBox. Соответственно, стандартный порт настроен на тачку, на которой висит Vbox (X.XX.XX.XXX:3389),
а виртуалки висят на кастомных портах, которые настраиваются (X.XX.XX.XXX:4444).
Ну так вот, настроил я на 135-й порт и теперь не подключается даже с самого хоста, на котором крутится виртуалка.
На 4444 или 5555 с телефона (и с самого хоста) подключается без проблем, но косяк в том, что они закрыты файрволом на той другой машине.
135-й порт как-то зарезервирован и недоступен для других целей?

Suncatcher, http://ru.wikipedia.org/wiki/%D0%A1%...TCP_%D0%B8_UDP

Спасибо, это я и сам уже посмотрел. Мне интересно, пробовал ли кто-нибудь прикручивать этот порт к RDP и получалось ли это у него?

думаю что прикрутить не получится по вполне понятным и простым причинам - этот порт в системе занят другой службой.
80\443 тоже недоступны для вас?

Да, к сожалению.
А если отключить этот RPC Locator? Получится?

если получится это сделать безболезненно, то вполне

а причём тут локатор то? :)
можно попробовать убрать с интерфейса "клиент для сетей Microsoft" и "службу доступа к файлам и принтерам", тогда, возможно, службы не будут прослушивать RPC на том интерфейсе.
но маловеротяно.

вообще странно что только 135 открыт.
чем вы проверяли?

telnet 127.0.0.1 XXXX

Еще открыт стандартный (3389), но его по вышеуказанным причинам использовать не могу.
Хотяяя...честно говоря, переназначать стандартный порт на VirtualBox не пробовал. Может и получится. Попробую - отпишусь.
Блин, стояла бы на удаленном хосте Win8 Pro, то и проблемы бы такой не стояло :) Заходи себе на физический хост и запускай себе какую душе угодно виртуалку.
Но нет, зараза! One-language-edition входящие RDP-подключения не поддерживает. Приходиться извращаться.

все 65к портов?

:laugh: Хороший вопрос!
Нет, конечно. Помогите автоматизировать процесс :whitevoid:
Писать скрипт с выгрузкой результата в файл как-то неохота ради одного раза.

:durak:
nmap/xspider/etc.
что-то вместе с указанием 127.0.0.1 у меня вообще перестала складываться картинка.
нарисуйте схему, что и где стоит.

Уфф! Аж употел, пока рисовал :boast:

После схемы повторю еще один свой вопрос: если порт закрыт на входящие подключения (которые я проверяю телнетом), то он будет закрыт и на исходящие?
Или на уровне файрвола можно это разграничить?

ну наконец.
тогда не ясно, зачем и что вы проверяете командой telnet 127.0.0.1 xxx
скорее всего на вашем "злом файрволе" разрешён SSL, иначе вы бы не смогли использовать HTTPS.
какие ещё порты у вас открыты - это вопрос.
что можно сделать:
поставить на "удалённый хост 5.x28.bla.bla" что-нибудь типа VNC или Radmin, указать им работу по порту 443 и подключиться со своего "подключающийся хост" по IP адресу и порут 443

можно разграничить, но 127.0.0.1 - не проверка.

А как, по вашему, проверить какие на мне порты открыты/закрыты с себя же? По-моему, вполне себе проверка.
По вашему, другого способа нет проверить порт на доступность его для исходящих соединений, кроме как организовывать пробное подключение с каждого порта?
65536 пробных подключений? Со сменой адресов и портов и на local-е и на remote-е, которые находятся на разных концах города. Геморрой...
По-моему, мы изобретаем велосипед... Проблема наверняка давно уже решена.
Тогда продублирую здесь вопрос, который я уже задавал на другом форуме:
И еще по поводу этого:
Как вы определили, что я использую HTTPS?

какие порты открыты на вход на внешнем файрволе?
ну явно не 127.0.0.1 ;)
причём тут исходящее?
telnet 127.0.0.1 xxx - это входящее.
вы - да, бесспорно.
VPN/SSL-VPN/teamviewer/etc.
логов - нет.
я предполгаю, что вам на "злом файерволе" разрешён SSL.
ибо состояние своего файервола (в ОС) вы можете посмотреть самостоятельно, если, конечно, можете.

Я это подсознательно понимаю, отсюда был и мой вопрос:

Не наводите тень на плетень. Я вам говорю об альтернативных способах проверки доступности портов с самого себя, а не об альтернативах RDP. Это мы сейчас не рассматриваем.

И все-таки раньше вы не предполагали, а выражались более категорично,
вот меня и заинтересовало, какие признаки на то указывают :)

ну для лучшего понимания - "злой файрвол" это файервол у вас на ПК или это файервол в сети, в которой вы находитесь?
вы говорите разные, не связанные между собой вещи - у вас каша в голове, отсюда и попытки проверять непонятно что через telnet 127.0.0.1/

В сети, конечно. Там стоит ISA Server, я полагаю или что-то аналогичное.
Со своим-то я могу справиться.

Ну так объясните мою ошибку, чтобы я понял всю глубину моих заблуждений. :yes: Дайте направление, куда копать, что почитать
Пока единственное осмысленное, что я вычитал - это то, что доступность хоста на каком-то порту проверяется телнетом. Это как расширенный, более функциональный, пинг. Как проверить себя таким способом - я нигде не нашел :(

отлично.
чтд.
я вам её объясняю уже несколько постов подряд.
вам нужно начать с чтения документации по стеку TCP чтобы понимать лучше.
верно.
но telnet 127.0.0.1 никаким образом не проверит начилие каких-либо правил на ISA (независимо S-NAT или D-NAT).
никакой связи с пингом он не имеет, даже на уровне протоколов.

итак, вы находитесь в сети, защищённой неким брендмауером по периметру.
входящие соединения на ваш хост можно отсечь сразу, вряд ли админы для вас это делали, а судя по тому что вы любите поумничать (при этом нисколько не разбираясь в вопросе), то и делать не будут.

значит вам нужно выяснить разрешён ли вам HTTPS трафик наружу.
я предполагаю что разрешён, проверить это просто - если странички через https открываются, то разрешён, если не открываются - то не разрешён.

пока останавливается на том, что он разрешён.
вам нужно сделать настройки, о которых я писала выше, на удалённой windows 8 и проверить работу.
отдельно обратите внимание на наличие FWC агента на вашем ПК.
если он есть - нужно будет предпринять дополнительные действия, чтобы вас пропасли не так быстро.

хорошие отношения с сетевым администратором и грамотное объяснение, почему вам нужно открыть нужные порты для удалённых серверов.
в противном случае при наличие хорошего сетевого администратора выйти за пределы настроенного фаервола - задача сложная.
сетевому администратору не составляет труда проанализировать ваш трафик (до VPN) - и просто закрыть IP адрес назначения:5.x28.ххх.х9 и не важно какой там порт 135 или 443.