Conecte-se à URL do repositório diferente, dependendo de estar na rede doméstica ou não

Question

Eu tenho uma cópia de trabalho de subversão no meu laptop e o repositório correspondente no meu NAS. Quando estou longe de casa, atualizo e faço o commit pela Internet através de uma conexão criptografada com um nome de domínio que resolve meu IP externo. Quando estou em casa e ligado através da minha rede doméstica, gostaria de atualizar e comprometer-me através de uma ligação não encriptada ao meu IP interno (rede doméstica).

Eu preferiria não usar criptografia ou meu endereço IP externo quando estiver em casa, porque ambos diminuem a velocidade de conexão (10 MB / s sem criptografia e com IP interno, 1 MB / s com criptografia e IP interno e 0,5 MB / s com ou sem criptografia e com IP externo).

Existe alguma maneira de deixar minha cópia de trabalho se referir a um URL diferente, dependendo de eu estar ou não conectado à minha rede doméstica? Ou existe outra maneira de resolver o problema da velocidade?

    

Answer 1

Algumas opções:

• Se isso acontecer por meio de ssh ( svn+ssh://... ), você poderá editar seu .ssh/config para especificar aliases para hosts. Você poderia então escrever um script que edita esse arquivo de configuração na mudança de rede para que o alias aponte para o nome de host correto.
• Se não for (através de http ou algo assim), você pode executar um servidor DNS local que resolva um nome de domínio especial que você pode usar para o IP do nome de domínio correto, dependendo da rede em que o computador está em
• (Provavelmente menos insano que o anterior) Execute uma retransmissão TCP em seu computador local em alguma porta e aponte para um dos dois servidores, dependendo da rede em que você está. Por exemplo, você poderia torná-lo vinculado a localhost:8080 e ter que ser encaminhado para myserver:80 quando estiver na rede 1, publicserver:80 quando estiver na rede 2. Então você pode precisar fazer um checkout desse endereço ( svn checkout http://localhost:8080/... ) .

Apenas algumas ideias aleatórias, todas elas parecem soluções alternativas. Talvez haja um jeito mais fácil.

Ou você pode querer mudar para um sistema de controle de versão distribuído como o git, que permitirá que você envie para o controle remoto desejado ( git push -u someremote branchname , onde someremote se refere a um dos servidores).

    

Answer 2

Eu resolvi um problema semelhante ontem, então git repos no meu laptop pode ser sincronizado com um controle remoto na minha máquina desktop, sem ter que usar um controle remoto diferente, dependendo se estou na rede local ou fora de casa.

Eu corri dnsmasq na minha área de trabalho, com esta configuração:

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

/etc/extra_hosts contém uma única entrada com o IP da minha área de trabalho na LAN e o nome do domínio que resolve para o meu IP externo, por exemplo,

192.168.0.72 jwakely.example.com

Em seguida, no meu laptop edite a configuração do NetworkManager para minha conexão Wi-Fi LAN para "Apenas endereços DHCP" e defina 192.168.0.72 como o servidor DNS primário e meu roteador como secundário (para fazer isso sem a GUI NetworkManager apenas defina DNS1 e DNS2 e PEERDNS = não, ou coloque os nameservers em /etc/resolv.conf manualmente)

Funcionou perfeitamente quando me lembrei de permitir consultas DNS (porta 53) através do firewall do meu desktop.

Quando estou em minha LAN doméstica, o laptop usa a área de trabalho para consultas DNS, portanto, obtém o IP interno para jwakely.example.com e todas as outras consultas DNS são encaminhadas para o servidor DNS usual da área de trabalho (que é meu ADSL) roteador.) Somente o laptop usa a instância dnsmasq , todos os outros hosts na LAN ainda usam o roteador para DNS como normal. Se meu laptop estiver na LAN, mas minha área de trabalho não estiver funcionando, o laptop usará seu servidor DNS secundário e não poderá obter o IP interno por jwakely.example.com , mas tudo bem, porque a máquina não está sendo executada de qualquer maneira.

    

Answer 3

Espero que você saiba sobre o comando relocate do Subversion. Você pode usá-lo manualmente. Se você usar nomes de host para acesso interno e externo, que resolvem apenas um em um local respectivamente, o erro svn em qualquer operação relacionada a repo lembra para realocar

Outra idéia (suja) é usar a conexão VPN em redes externas para proteger o acesso ao servidor e usar o protocolo inseguro comum para acesso ao repositório - na rede doméstica você apenas não faz o link VPN. As vantagens dessa maneira são: URL único, segurança sob demanda, simplicidade à prova de erros