erro de RDP usando Gateway Linux

andretf78
(usa Debian)

Enviado em 24/01/2014 - 15:38h

Meus Caros,
Tenho o Seguinte Senário:

Tenho 2 Redes em prédios diferentes. a Matriz fica com ip 192.168.90.0/24 e a filial fica com ip 192.168.80.0/24.

Possuo uma VPN Cisco operando com link da embratel usando os seguintes ips 192.168.90.5 e 192.168.80.5
Possuo uma OpenVPN Reduntante operando nos Gateway de borda (192.168.90.254 e 192.168.80.254)
o Gateway 192.168.80.254 é um servidor novo, que está substituindo o 192.168.80.1.

a Rede local nos gateway's usam os devices eth2

visto isso, o erro que ocorre é o seguinte:

Se eu tentar conectar da minha rede 192.168.90.0/24 via RDP em uma maquina da minha rede 192.168.80.0/24 que já esteja apontada para o Gateway novo ele simplesmente não conecta quando eu estou pela VPN Cisco, porem quando eu estou pela VPN OpenVPN conecta normalmente.

Alguem já pegou esse caso?

Desde já agradeço

removido
(usa Nenhuma)

Enviado em 25/01/2014 - 01:24h

Bom Dia ,


Pelas informações passadas falta somente criar rotas estaticas para as redes que você deseja acessar nos roteadores cisco. Lembando que você terá que configurar uma rota de retorno para a rede da vpn do cisco nos servidores para que o acesso seje possível no senário descrito.


Att,

Tiago Eduardo Zacarias
LPIC-1

andretf78
(usa Debian)

Enviado em 27/01/2014 - 10:41h

Bom dia Tiago.

As rotas estáticas estão Criadas direcionando a tudo que for chamado para a rede 80.0 para o cisco no ip 90.5..
Do outro lado tenho todo chamado para rede 90.0 para o ip do cisco 80.5

VPN cisco na rede 90: 192.168.90.5
VPN Cisco na rede 80: 192.168.80.5

no servidor 192.168.80.254:

Tabela de Roteamento IP do Kernel
Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface
default Broadcom.Home 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.4.0 192.168.80.6 255.255.255.0 UG 0 0 0 eth2
192.168.4.0 192.168.80.6 255.255.252.0 UG 0 0 0 eth2
192.168.80.0 * 255.255.255.0 U 0 0 0 eth2
192.168.90.0 192.168.80.5 255.255.255.0 UG 0 0 0 eth2


No servidor 192.168.90.254

Tabela de Roteamento IP do Kernel
Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface
192.168.80.0 192.168.90.5 255.255.255.0 UG 0 0 0 eth2
172.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.90.0 * 255.255.255.0 U 0 0 0 eth2
192.168.4.0 contabil01.vale 255.255.252.0 UG 0 0 0 eth2
default ACA800FE.ipt.ao 0.0.0.0 UG 0 0 0 eth0

removido
(usa Nenhuma)

Enviado em 27/01/2014 - 12:18h

Bom dia Colega,

Realize o Tracert partindo de uma maquina da rede 80 passando pela VPN cisco sentido o ip do servidor RDP na rede 90 e poste aqui,


ATT,

Tiago Eduardo
LPIC-1

andretf78
(usa Debian)

Enviado em 28/01/2014 - 15:14h

Tiago,

tracert apartir de uma estação da rede 90.0/24 para o ip 192.168.80.4

C:\Users\andre.ferreira>tracert 192.168.80.4

Rastreando a rota para 192.168.80.4 com no máximo 30 saltos

1 9 ms 11 ms 10 ms VPNLITORAL [192.168.90.184]
2 13 ms 10 ms 10 ms 192.168.90.254
3 14 ms 15 ms 14 ms 192.168.80.4

Rastreamento concluído.

C:\Users\andre.ferreira>



do servidor 192.168.90.254 para o ip 192.168.80.4

root@fwserver:~# traceroute 192.168.80.4
traceroute to 192.168.80.4 (192.168.80.4), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@fwserver:~#



do servidor 19.168.80.254 para o ip 90.10 e 90.20

root@fwserver:~# traceroute 192.168.90.10
traceroute to 192.168.90.10 (192.168.90.10), 30 hops max, 60 byte packets
1 192.168.90.10 (192.168.90.10) 9.936 ms 10.160 ms 10.186 ms
root@fwserver:~# traceroute 192.168.90.20
traceroute to 192.168.90.20 (192.168.90.20), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@fwserver:~# root@fwserver:~#

Os pings para todos os IPs funcionam normalmente, tanto a partir dos gateways quanto de uma estação.

andretf78
(usa Debian)

Enviado em 29/01/2014 - 10:40h

gateway 80.254


root@fwserver:~# ip route show
default via 192.168.1.1 dev eth1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.199
192.168.4.0/24 via 192.168.80.6 dev eth2
192.168.4.0/22 via 192.168.80.6 dev eth2
192.168.80.0/24 dev eth2 proto kernel scope link src 192.168.80.254
192.168.90.0/24 via 192.168.80.5 dev eth2
root@fwserver:~#


gateway 90.254

root@fwserver:~# ip route show
192.168.80.0/24 via 192.168.90.5 dev eth2
172.168.0.0/24 dev eth0 proto kernel scope link src 172.168.0.253
192.168.90.0/24 dev eth2 proto kernel scope link src 192.168.90.254
192.168.4.0/22 via 192.168.90.29 dev eth2
default via 172.168.0.254 dev eth0
root@fwserver:~#


Uma informação, esse problema somente ocorre quando estou na vpn (cisco) e o gateway do computador 192.168.80.4 é o 192.168.80.254

Quanto estou na VPN (OpenVPN) minha vpn redundante o RDP funciona normalmente quando o ip 192.168.80.4 está com o gateway 192.168.80.254.

Quando estou na VPN (Cisco) e o gateway do ip 192.168.80.4 está apontado para o servidor antigo 190.168.80.1 funciona normalmente também

removido
(usa Nenhuma)

Enviado em 29/01/2014 - 10:48h

Bom dia ,


Pelo que pude ver voce esta com a vpn cisco ligada em sua rede local, o ideal era voce ligar a vpn cisco em uma placa de rede diferente da rede local nos gateways de borda para evitar que o trafego entre na borda e depois retorne pela mesma placa para alcançar a rede remota ou então utilizar recurso de vlan na mesma placa para evitar este loop de roteamento.


Obs: Voce dependeria dos gateways de borda para as duas conexões de vpn operem normalmente, para resolver este problema voce poderia realizar o balanceamento com um segundo gateway linux em cada ponta para garantir a disponibilidade eliminando o ponto unico de falha.


Tiago Eduardo Zacarias
LPIC-1
Viva o Linux

andretf78
(usa Debian)

Enviado em 29/01/2014 - 11:31h

Esse problema não ocorre quando estou no slackware (o gateway de borda antigo.) somente no novo. já comparei tabelas de roteamento e regras de firewall, configuração de Lan, e simplesmente continuo tendo esse problema. o mesmo não ocorre no sentido contrário, no gateway novo, inclusive já desliguei o gateway antigo.

não achei nenhuma discrepância, entre o gateway antigo e o gateway novo na rede 80. o gateway antigo não possui vlan, e nem saida exclusiva para o cisco. Porem funciona. o que me sugere que tenho algo de errado no gateway novo. esse é o unico serviço que não funciona, até a minha replicação de domínio funciona normalmente.

andretf78
(usa Debian)

Enviado em 29/01/2014 - 11:31h

Esse problema não ocorre quando estou no slackware (o gateway de borda antigo.) somente no novo. já comparei tabelas de roteamento e regras de firewall, configuração de Lan, e simplesmente continuo tendo esse problema. o mesmo não ocorre no sentido contrário, no gateway novo, inclusive já desliguei o gateway antigo.

não achei nenhuma discrepância, entre o gateway antigo e o gateway novo na rede 80. o gateway antigo não possui vlan, e nem saida exclusiva para o cisco. Porem funciona. o que me sugere que tenho algo de errado no gateway novo. esse é o unico serviço que não funciona, até a minha replicação de domínio funciona normalmente.

andretf78
(usa Debian)

Enviado em 29/01/2014 - 11:31h

Esse problema não ocorre quando estou no slackware (o gateway de borda antigo.) somente no novo. já comparei tabelas de roteamento e regras de firewall, configuração de Lan, e simplesmente continuo tendo esse problema. o mesmo não ocorre no sentido contrário, no gateway novo, inclusive já desliguei o gateway antigo.

não achei nenhuma discrepância, entre o gateway antigo e o gateway novo na rede 80. o gateway antigo não possui vlan, e nem saida exclusiva para o cisco. Porem funciona. o que me sugere que tenho algo de errado no gateway novo. esse é o unico serviço que não funciona, até a minha replicação de domínio funciona normalmente.