4

У меня есть рабочая копия Subversion на моем ноутбуке и соответствующий репозиторий на моем NAS. Когда я нахожусь вне дома, я обновляю и фиксирую через Интернет зашифрованное соединение с доменным именем, которое преобразуется в мой внешний IP. Когда я нахожусь дома и подключен через домашнюю сеть, я хотел бы обновить и зафиксировать незашифрованное подключение к своему внутреннему (домашней сети) IP.

Я предпочел бы не использовать шифрование или мой внешний IP-адрес, когда я дома, потому что оба замедляют скорость соединения (10 МБ / с без шифрования и с внутренним IP, 1 МБ / с с шифрованием и внутренним IP, и 0,5 МБ / с или без шифрования и с внешним IP).

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

3 ответа3

1

Некоторые варианты:

  • Если это через ssh (svn+ssh://...), то вы можете отредактировать ваш .ssh/config чтобы указать псевдонимы для хостов. Затем можно написать сценарий, который редактирует этот файл конфигурации при изменении сети, чтобы псевдоним указывал на правильное имя хоста.
  • Если это не так (через http или что-то еще), вы можете запустить локальный DNS-сервер, который разрешает специальное доменное имя, которое вы можете сделать до IP-адреса правильного доменного имени в зависимости от того, в какой сети находится компьютер.
  • (Вероятно, менее ненормальный, чем предыдущий) Запустите ретранслятор TCP на локальном компьютере через какой-либо порт, и он должен указывать на любой сервер в зависимости от сети, в которой вы находитесь. Например, вы можете привязать его к localhost:8080 и передать его myserver:80 в сети 1, publicserver:80 в сети 2. Тогда вам может понадобиться сделать извлечение с этого адреса (svn checkout http://localhost:8080/...).

Просто некоторые случайные идеи, все они чувствуются как обходные пути. Может быть, есть более простой способ.

Или вы можете захотеть переключиться на распределенную систему управления версиями, такую как git, которая позволит вам передавать на удаленный компьютер, который вы хотите (git push -u someremote branchname , где someremote ссылается на один из серверов).

1

Вчера я решил похожую проблему, поэтому git-репозитории на моем ноутбуке можно синхронизировать с пультом на настольном компьютере, без необходимости использовать другой пульт, в зависимости от того, нахожусь ли я в локальной сети или вдали от дома.

Я запустил dnsmasq на своем рабочем столе с этим конфигом:

domain-needed
bogus-priv
no-poll
local=/localdomain/
addn-hosts=/etc/extra_hosts

/etc/extra_hosts содержит единственную запись с IP-адресом моего рабочего стола в локальной сети и именем домена, которое разрешается для моего внешнего IP-адреса, например

192.168.0.72 jwakely.example.com

Затем на моем ноутбуке измените конфигурацию NetworkManager для моего Wi-Fi-подключения к локальной сети на "DHCP Addresses Only" и установите 192.168.0.72 в качестве основного DNS-сервера, а мой маршрутизатор в качестве дополнительного (для этого без графического интерфейса пользователя NetworkManager просто установите DNS1 и DNS2 и PEERDNS = нет, или поместите серверы имен в /etc/resolv.conf вручную)

Он прекрасно работал, как только я вспомнил, что разрешил DNS-запросы (порт 53) через брандмауэр моего рабочего стола.

Когда я нахожусь в моей домашней локальной сети, ноутбук использует рабочий стол для DNS-запросов, поэтому получает внутренний IP-адрес для jwakely.example.com , а все другие DNS-запросы перенаправляются на обычный DNS-сервер моего рабочего стола (который является моим ADSL-маршрутизатором). .) Только ноутбук использует экземпляр dnsmasq , все остальные хосты в локальной сети все еще используют маршрутизатор для DNS как обычно. Если мой ноутбук находится в локальной сети, но мой рабочий стол не работает, он использует свой дополнительный DNS-сервер и не может получить внутренний IP-адрес для jwakely.example.com но это нормально, потому что машина все равно не работает.

0

Надеюсь, вы знаете о команде relocate Subversion. Вы можете использовать его вручную. Если вы будете использовать имена хостов для внутреннего и внешнего доступа, которые разрешают только одно в одном расположении соответственно, ошибка svn при любой операции, связанной с репо, напоминает о перемещении

Еще одна (грязная) идея - использовать VPN-соединение во внешних сетях для защиты доступа к серверу и использовать общий небезопасный протокол для доступа к хранилищу - в домашней сети вы просто не подключаете VPN-соединение. Преимущества этого способа: единый URL, безопасность по требованию, простота, защищенная от ошибок

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .