Encapsulando um IP Público em uma Máquina Remota


8

Eu tenho um servidor Linux A com um bloco de 5 endereços IP públicos 8.8.8.122/29,. Atualmente, 8.8.8.122está atribuído a eth0e 8.8.8.123está atribuído a eth0:1.

Eu tenho outra máquina Linux B em um local remoto, atrás do NAT. Gostaria de criar um túnel entre os dois para que B possa usar o endereço IP 8.8.8.123como endereço IP principal.

O OpenVPN é provavelmente a resposta, mas não consigo descobrir como configurar as coisas ( topology subnetou topology p2ppode ser apropriado. Ou devo usar a ponte Ethernet?). A segurança e a criptografia não são uma grande preocupação neste momento; portanto, o GRE também seria bom - a máquina B virá de um endereço IP conhecido e poderá ser autenticada com base nisso.

Como posso fazer isso? Alguém pode sugerir uma configuração do OpenVPN, ou alguma outra abordagem, que possa funcionar nessa situação? Idealmente, ele também seria capaz de lidar com vários clientes (por exemplo, compartilhar todos os quatro IPs sobressalentes com outras máquinas), sem permitir que esses clientes usassem IPs aos quais não têm direito.


Quais firewalls existem nos dois locais?
Robert

1
Espero que você tenha inventado esses endereços, em vez de realmente trabalhar no Google. Caso contrário, você não poderá usar o espaço de endereço deles.
Michael Hampton

Robert: A é um servidor Linux com algumas iptablesregras simples . B está por trás de um NAT que é outro servidor Linux em execução shorewall.
Jim Paris

Michael: Sim, mudei os três primeiros octetos para 8 para ofuscá-los, mas ainda assim indico que eles são públicos. Desculpe, Google.
Jim Paris

1
Para referência futura, temos uma RFC para isso .
Michael Hampton

Respostas:


7

Acabei indo com a ponte Ethernet. Muitos exemplos extremamente detalhados para percorrer online, mas acaba sendo bem fácil:

Primeiro, em A , /etc/network/interfacesfoi alterado de:

auto eth0
iface eth0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121

para:

auto br0
iface br0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121
    pre-up openvpn --mktun --dev tap0
    bridge_ports eth0 tap0
    bridge_fd 3

para fazer a ponte eth0(a interface WAN real) com tap0(uma nova interface de túnel) na inicialização.

Em seguida, em A , execute o servidor openvpn com:

openvpn --dev tap0

Em B , conecte-se a ele com:

openvpn --remote 8.8.8.122 --dev tap0 --route-gateway 8.8.8.121 \
        --redirect-gateway def1 --ifconfig 8.8.8.123 255.255.255.248

Essa é a configuração super simples que eu estava procurando e funciona - B agora está acessível ao público em 8.8.8.123, e as conexões de saída se originam do mesmo endereço.

Adicione segurança ( --secret, --tls-serveretc) conforme necessário, é claro.


Agradável! Eu vou tentar isso. Você encontrou uma maneira de configurar isso: "sem permitir que esses clientes usem IPs aos quais não têm direito"?
Bastian

Eu não me incomodei na minha configuração (que era temporária), mas imagino que você poderia fazê-lo com ebtables.
Jim Paris

Muito útil. Uma pergunta: o que eu preciso alterar na configuração A se precisar rotear dois IP de A: A => B e A => C (onde C é outro host)? Preciso configurar outra ponte?
precisa saber é

2
Sim. Adicionar outra pre-up openvpnlinha para criar tap1também, adicionar tap1a bridge_ports, e executar outra instância do openvpn com openvpn --dev tap1.
Jim Paris

Que tal se você quisesse tornar o gateway de A local via B, para que qualquer sistema na LAN pudesse usar B e atribuir o gateway padrão remoto e IPs públicos?
Areeb Soo Yasir

1

Você vai ter dificuldade, eu acho. A maioria dos firewalls terá dificuldade em rotear o tráfego OpenVPN se os dois lados da VPN estiverem na mesma sub-rede.

Se você estiver tentando rotear para acesso público, eu moveria os dois servidores para sub-redes diferentes dos seus endereços públicos e usaria IPs virtuais (1 a 1 Nat) para conectá-los. Para conectar os dois sites, o OpenVPN funcionaria ou um túnel IP-Sec.

IPs virtuais: http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

Site para site: http://doc.pfsense.org/index.php/VPN_Capability_IPsec

Edite com base nos comentários:

Eu instalaria pessoalmente o pfSense na caixa A e daria a porta que você queria para sua WAN. Em seguida, configure um servidor OpenVPN em uma sub-rede local (que esteja pronta para entrar na interface da web do pfSense) e configure a outra máquina com um IP virtual apontado para seu IP OpenVPN local. Isso daria a você espaço para expansão posteriormente (adicione mais máquinas com IPs virtuais, encaminhe portas específicas para diferentes servidores, tenha realmente uma configuração completa de LAN / WAN / DMZ com o OpenVPN para acesso virtual. roteador completo, por isso provavelmente seria mais seguro.


Não entendo como os firewalls intermediários estão envolvidos; eles certamente não vai estar olhando dentro dos pacotes OpenVPN entre A e B . Para a própria configuração do OpenVPN, eu esperava que algo assim push "route 50.7.19.122 255.255.255.255 net_gateway"assegurasse que os dados da VPN ainda fossem enviados pela rede normal.
Jim Paris

Para deixar claro, quero criar um túnel diretamente entre A e B , não em firewalls separados em cada extremidade.
Jim Paris

1
Mas quando o computador A deseja rotear para o computador B, ele não saberá se deve usar a WAN (com seus IPs públicos), a LAN (com seu IP estático) ou o OpenVPN (também com seus IPs públicos) porque são todos. mesma sub-rede. B para A deve funcionar embora.
Robert

1
Também existe, eu trabalhei, mas não com IPs públicos. Eu acho que os ips virtuais serão muito melhores de qualquer maneira. openvpn.net/index.php/open-source/documentation/misc Miscellaneous
Robert

"Para deixar claro, quero criar um túnel diretamente entre A e B, não em firewalls separados em cada extremidade". Você precisará abrir uma porta em algum lugar para um servidor OpenVPN
Robert
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.