Удаленный доступ к серверу SVN


1

Итак, я потратил несколько дней усилий на это. У меня есть SVN Apache Edge, работающий на моей машине поверх Apache. Я хочу получить к нему доступ (выписка / регистрация) с удаленного компьютера. Моя машина находится за обычным маршрутизатором и имеет динамический IP. Вот чего я достиг:

  1. Зарегистрировал мою машину с помощью службы DDNS и получил URL.
  2. Включена переадресация портов (порт 8085 перенаправлен на порт 80 моей машины) на маршрутизаторе.
  3. Я почти уверен, что SVN / Apache прослушивают порт 80, потому что я могу набрать http://localhostв браузере (на моей машине) и получить список каталогов репо.
  4. Но когда я печатаю http://My_DDNS_URL:8085на удаленной машине, это почти всегда ждет ответа от моей машины и заканчивается тайм-аутом (я думаю).
  5. Я могу пропинговать как мой динамический IP-адрес, так и мой URL-адрес (назначенный службой DDNS) с удаленного компьютера.

Что я здесь не так делаю?


Порт 8085 перенаправляется через маршрутизатор на целевой сервер?
— Ƭᴇcʜιᴇ007

Есть ли причина, по которой вы используете SVN? Mercurial, Git и т. Д. Являются хорошими частями программного обеспечения и легче делятся изменениями, независимо от того, используете ли они бесплатный хостинг или сами запускаете сервер.
— syserr0r

Я работаю с SVN уже довольно давно. Переключение на другую систему управления версиями может повлечь за собой некоторую кривую обучения, которой я хочу избежать на данном этапе графика моего работающего проекта.
— dotNET

Ответы:


1

Проблема может быть в одном из нескольких мест. Три наиболее вероятные:

  • Apache слушает только на локальном хосте (вместо, скажем, 192.168.1.xили 0.0.0.0)
  • Переадресация портов не работает / не настроена должным образом (например, порт 8085переадресован, 192.168.1.12но ваш компьютер изменился с 192.168.1.14момента последней перезагрузки)
  • Ваш модем / маршрутизатор не выполняет NAT-loopback (обычно, если вы хотите получить доступ к своему сервису изнутри вашей сети, к которой вы подключаетесь, http://192.168.1.xи если вы находитесь за ее пределами http://1.2.3.4- NAT-loopback перенаправляет запросы изнутри сети на свой внешний адрес обратно в его внутренний адрес [например, в 1.2.3.4into 192.168.1.x] (поэтому внешний адрес все еще работает внутри).

Благодарю. Я также обнаружил, что я могу сделать http://My_DDNS_URL(без номера порта) с удаленного компьютера, и это приведет меня к домашней странице маршрутизатора (той же странице, к которой я могу получить доступ, набрав 192.168.1.1 на моем локальном компьютере). Помогает ли это в устранении любой из вышеперечисленных возможностей?
— dotNET

Звучит так, как будто на вашем маршрутизаторе отсутствует функция обратной петли NAT (или она не включена). Из того, что я понимаю, это не очень распространено. Самый простой способ проверить это - подключить кого-то за пределами вашей сети - если он может (а вы не можете), то это проблема NAT-loopback. NAT-loopback - более удобная функция; на самом деле вы должны подключаться к локальному хосту (или к любому IP / хосту вашего компьютера), когда вы находитесь в сети.
— syserr0r

В качестве базового теста, если у вас нет доступа к серверу или компьютеру во внешней сети, вы можете перейти к чему-то вроде ShieldsUP! введите номер внешнего порта (например, 8085) и нажмите User Specified Custom Port Probe. Он не скажет вам, что слушает (то есть Apache), но сообщит, могут ли подключиться внешние люди
— syserr0r

ShieldsUP! говорит мне, что состояние моего порта 8085 ОТКРЫТО с неизвестным протоколом / приложением. Как это поможет?
— dotNET

Читая файл conf сервера Apache, я также подтвердил, что он прослушивает порт 80 на всех интерфейсах (сравнивая его с предоставленной выше ссылкой на doc). Так что # 1 здесь не проблема.
— dotNET
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.