Página 3 de 4 PrimeiroPrimeiro 1234 ÚltimoÚltimo
+ Responder ao Tópico



  1. Citação Postado originalmente por gamineiro Ver Post
    Não amigo. Não estou supondo isso. Estou dizendo em mangle que os pacotes vindos do servidor (10.2.15.121) nas portas 8454-8456 devem ser encaminhados para o router A (192.168.84.2) Suas regras do router A estão equivocadas, usando src-port, onde o correto é dst-port. Se puderes fazer o teste como sugeri, poderás ter sucesso. Abraço
    Ah sim, é que achei que tinha um dst-address ali no mangle e que na rota era o IP do servidor, hehe.

    Sobre as regras, acho que eu devo ter errado algo ao transcrevê-las para cá, pois na verdade estão implementadas igual ao que você sugeriu.

    Testei tudo que você sugeriu e nada funcionou. Mas como eu disse no título desse tópico, se no router A eu adicionar ou substituir a regra srcnat atual (inclusive essa que você sugeriu) por uma com action=masquerade, eu consigo o que estou querendo perfeitamente, exceto pelo que o IP de origem do acesso vai ser mascarado, o que não quero.

    Então tenho absoluta certeza que o problema envolve somente nas regras srcnat no router A, mas o quê? Já defini a interface de saída, removi a especificação de protocolo e porta, como você sugeriu no penúltimo post.

    Como a única diferença do src-nat para o masquerade é a abstração da seleção do IP público e interface de saída, parece que o problema está no IP ou interface que estou selecionando na srcnat, mas não sei o porquê disso. Existe alguma forma de eu ver por qual IP/interface está saindo o tráfego da masquerade?

    Atualização: fiz uns testes com o masquerade mudando o src-address e constei que o único que funcionou foi o IP público do router C. Como nesse router - que é pelo qual o router B tem acesso à internet - há um NAT, o tráfego do EoIP está sendo mascarado nele. Mas não entendi o porquê disso ocorrer. O tráfego de um túnel não deveria estar "imune" ao que é feito ao tráfego normal? Ainda mais por estar em uma bridge. E mais, não adianta eu apenas colocar na src-nat o IP do NAT do router C como src-address, não funciona aqui, embora no masquerade ocorra tudo bem. Acredito que seja um problema de identidade da conexão. O dst-nat diz que ela será feita com 192.168.84.1, mas a resposta está vindo de 198.51.100.40 (IP público do router C); a resposta esperada não é daí. Eu tentei fazer o tráfego pelo túnel não passar pelo NAT, mas não consegui. Acho que vou ter que alterar o NAT do PC Linux que está entre os routers B e C de masquerade para dst-nat/src-nat também.
    Última edição por TsouzaR; 12-05-2014 às 01:24.

  2. Agora me confundiu de novo. hahahah

    Bom, caso queira fazer com que a comunicação da rede internet não seja afetada pela regra de NAT, crie uma address-list com as redes internas, e na regra de NAT em dst-address-list(na segunda aba) coloque !NOME_DA_LISTA.

    Espero que ajude.



  3. Citação Postado originalmente por gamineiro Ver Post
    Agora me confundiu de novo. hahahah

    Bom, caso queira fazer com que a comunicação da rede internet não seja afetada pela regra de NAT, crie uma address-list com as redes internas, e na regra de NAT em dst-address-list(na segunda aba) coloque !NOME_DA_LISTA.

    Espero que ajude.
    Hahaha, tentei explicar o mais claramente possível, mas se quiser explico novamente de outra forma.

    Eu teria que fazer essa exceção aí também para o src-address(-list), não? Ao invés de address-list, somente um src-address=!192.168.84.0/30 dst-address=!192.168.84.0/30 deve funcionar, certo?

    Só que há um outro problema que eu não imaginei que existiria. Como eu disse em algum outro post, entre os routers B e C há um PC Linux, que é quem conecta/funciona como gateway entre os dois e faz algumas outras coisas lá. O tráfego entre esses dois routers é feito por um masquerade. Eu não sabia que o NAT se aplicava também a túneis, por isso achei que não seria problema. Sendo assim, vou ter que mudar esse masquerade para src-nat + dst-nat, ao menos nos protocolos GRE e ICMP, certo?

    Diante desse problema, uma correção da imagem anterior:

    Clique na imagem para uma versão maior

Nome:	         topologia.png
Visualizações:	76
Tamanho: 	33,6 KB
ID:      	51744

    Mais tarde vou testar essas coisas aí, comenta aí se está certo meu raciocínio.
    Até mais.

  4. Se você estiver usando EoIP não funciona mesmo, a menos que faça o redirecionamento das portas, como você já sabe.

    Existe alguma possibilidade de fazer um túnel entre B e A?

    Poderia habilitar um SSTP Server no router A, e criar um sstp-client no router B, assim não teria problema o nat no meio do caminho, precisa apenas um IP público no router A.

    Abraço



  5. Citação Postado originalmente por gamineiro Ver Post
    Se você estiver usando EoIP não funciona mesmo, a menos que faça o redirecionamento das portas, como você já sabe. Existe alguma possibilidade de fazer um túnel entre B e A?

    Poderia habilitar um SSTP Server no router A, e criar um sstp-client no router B, assim não teria problema o nat no meio do caminho, precisa apenas um IP público no router A.

    Abraço
    Não, não é possível fazer um túnel entre A e B diretamente, por dois motivos:
    1: O router A é visível para o B, mas o inverso não é possível pois o B não possui IP público e não está em uma rede do router A
    2: A solução para isso seria com rotas, mas não posso mexer nelas no router A pois ele está próximo da borda de um OSPF, o que faria a rota ser distribuída por muitos routers, e no caso de haver uma alteração de IP, teria o trabalho de alterar a rota nele de novo, além de gerar toda a atualização do OSPF. Se não fosse isso, eu poderia definir a rota para o router B passando pelo C. No C tenho a rota para o router B passando pelo PC Linux.

    Bom, acho que o SSTP não serve, mas se servisse teria que ser no router C para manter a ideia desse router ser um concentrador de túneis, e também, pela proximidade com ele, a conexão e estabelecimento do túnel seria feito mais rapidamente e com menos chances de uma interrupção no meio do caminho. Só que haveriam alguns problemas: SSTP exige muito do router por usar SSL em todo o tráfego, não preciso disso e os router não têm recursos sobrando assim (PPTP e L2TP estão defasados), e o problema que atinge todos os tipos de VPN: as interface não podem ser usadas em bridges, nem podem haver VLANs sobre elas, além de outras coisas. Caso eu precise fazer algo assim, e imagino cenários onde essas necessidades podem surgir, vou ter problemas. Por isso EoIP é a solução ideal, nem OpenVPN atenderia, pois mesmo não sendo defasado quanto os que citei e nem usar tantos recursos quanto a sua sugestão, ainda há o problema das interfaces passivas (acho que é esse o nome que dão).

    Então, acabei de bolar uma solução mais interessante aqui: ao invés de um EoIP entre o router B e C, faço uma VLAN entre o PC Linux e o router C. Essa VLAN está inclusa na bridge com o túnel EoIP com o router A. Nesse PC Linux eu faço um DNAT+SNAT para o router B. Ótimo, consigo ping entre o router A e o PC Linux. Aí, para testar, iniciei um servidor web **no PC Linux** rodando em uma das portas encaminhadas e tentei acessá-lo usando o IP público do router A. E adivinha o que ocorreu? O maldito problema lá do começo continua. Fica carregando e não tem resposta no navegador. No EoIP até era compreensível a ocorrência do NAT por ser um túnel over IP, mas na VLAN não estou entendendo o porquê disso estar ocorrendo. Novamente, action=masquerade funciona perfeitamente, inclusive o mesmo caso do src-address ocorre: somente com o IP público do router C. Ou seja, está passando pelo NAT ainda. Mas não faz sentido, o NAT lá no router C é aplicado somente à faixa de IPs com que as máquinas se conectam a ele. Embora o PC Linux esteja nessa faixa, o tráfego do encaminhamento passa pela VLAN, que está em outra faixa. Está muito estranha essa situação, não sei o que fazer para escapar dessa regra NAT. Será que preciso alterar, talvez no router C, a configuração de ARP para proxy-arp? Não entendo muito bem essa configuração, não sei se devo alterar na bridge ou nas portas dela, se for essa a solução.

    Atualização: recém lembrei das rotas. Como o router A está mais próximo da borda do OSPF, ao atribuir um IP na faixa do túnel para ele, ele distribuir no OSPF a rota para essa faixa como sendo ele o gateway, e essa rota chega no router C. Assim, quando o router C vai encaminhar o pacote para o router B, ele vê a rota apontando para o A e manda o pacote pra lá. Quando chega no A, o pacote é enviado novamente para o router B por meio do túnel, chegando novamente no C... enfim, acabei criando um loop na rede. Acho que o problema é esse. Agora o porquê do masquerade fazer esse loop parar eu não estou conseguindo entender. Vou ver se posso fazer algo quanto à distribuição dessa rota específica no OSPF, mas acho que não é possível ignorá-la. Se tiver alguma dica para me dar quanto a isso, agradeço.

    Atualização: infelizmente o problema não é esse. Eu alterei a máscara dos IPs no túnel para 29 e adicionei um IP para a bridge no router C; isso faz com que a regra recebida do OSPF fique inválida. No entanto, mesmo assim não consegui fazer funcionar. Eu fiz uns testes no router A tentando fazer o dst-nat/src-nat para um outro router na rede e até para o servidor web de algum site, só para testar. E a surpresa é que não funcionou com nenhum. Aí eu resolvi testar usando o IP do próprio router A no túnel como dst-address e src-nat na dst-nat e src-nat respectivamente, fazendo as devidas adaptações no action. Fiz praticamente o mesmo que um action=redirect, porém especificando o IP do túnel. E sem surpresa, funcionou. Logo está confirmado que é o problema não é com as regras. É alguma outra coisa, provavelmente um NAT, mas não faço ideia de como está ocorrendo isso, sendo que testei a configuração entre dois routers ligados diretamente por um PTP wireless e não funcionou. Alguma ideia?
    Última edição por TsouzaR; 13-05-2014 às 17:35.






Tópicos Similares

  1. Respostas: 1
    Último Post: 10-05-2013, 10:10
  2. Port Forwarding com o Putty + OpenSSH
    Por supercelso no fórum Servidores de Rede
    Respostas: 4
    Último Post: 10-01-2006, 10:50
  3. Port Forward com Iptables
    Por Luciano_g no fórum Servidores de Rede
    Respostas: 1
    Último Post: 25-05-2005, 08:12
  4. Problemas fazendo port forwarding para NetMeeting
    Por Ganymede no fórum Servidores de Rede
    Respostas: 2
    Último Post: 22-01-2003, 12:07
  5. Respostas: 3
    Último Post: 07-01-2003, 22:09

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L