Gostou? Compartilhe, deixe seu like e conta aqui embaixo o que mais você gostaria de ver no canal! Índice Do Vídeo: 00:00 Hairpin NAT overview 08:13 Demonstração em laboratório Download de Configurações: drive.google.com/drive/folders/1W6kEBYgt-bopNq6sxSe-OhsZAg156Ep-?usp=sharing Link para curso de Redes de Computadores - TCP/IP: go.hotmart.com/G73136555G Também tenho comunidades: Discord: discord.gg/U6WR5Tshav Telegram: t.me/matheuslealcomunidademorcego Me siga nas redes sociais: 📲Instagram: instagram.com/matheuslealmvl/ 📲LinkedIn: www.linkedin.com/in/matheusvleal/ Para consultorias, dúvidas e sugestões: networks.mvl@gmail.com
Já vi esse cenário antes em um sistema instalado em tablets de vendas que podia estar na loja ou na rua com acesso externo… No meu caso como a RB estava resolvendo DNS fixei no DNS o ip do servidor… So tomar o cuidado de subir o serviço do servidor na mesma porta que foi usada no Nat. Desta forma evita usar nat
Como iria funcionar em um cenário com dois links? O link principal sem ip público e o segundo link que fica como backup é o que tem ip público? Teria que fazer um ajuste para que não saia pelo link principal e saia no secundário não é?
E quando for pra testar redirecionamento externo? Por exemplo acessar externamente pela porta 80 e 443 o apache de um servidor local, como fica essa regra?
Muito bom, bem ilustrativo e didático. Agora me lembrou um case que pode ocorrer, como todo mundo dentro da rede 10.0.0.0/24, vai acessar a aplicação no 10.0.0.2 como se fosse o 10.0.0.1, caso por exemplo alguém dentro da rede local fosse bloqueado por erro de senha (bloqueando a origem IP 10.0.0.1), todo mundo de dentro da rede terá a aplicação bloqueada (o mesmo vale pra log do IP de origem etc, todo mundo chega como 10.0.0.1). Pensando nisso, não seria melhor aplicar um pool Nat ( eu sei que isso trem no fortigate, inclusive no fgt ele já faz o que foi explicado nesse vídeo automaticamente). Explico: se fazer um pool Nat de 1 pra 1 com rede 10.10.10.0/24 vamos supor mascarar a origem do 10.0.0.3 com o IP 10.10.10.3, mascarar a origem do 10.0.0.4, com o IP 10.10.10.4 e assim por diante, não seria uma melhor forma de contornar os possíveis problemas e deixar essa solução do dnat pra rede local um pouco mais sofisticada? Eu já fiz um pouco no fgt, mas confesso que ainda estou engatinhando pra achar a melhor forma possível pra resolver esse problema. Se me permitir, fica uma sugestão pra algum vídeo do fortigate (em especial mostrando por linha de comando a conexão ocorrendo). Parabéns pelo seu trabalho, forte abraço
Fala meu mano! Não sei se entendi muito bem sua pergunta, mas vamos lá: Cenário 01: Aplicação com endereço IP privado em um cenário que uma workstation (10.0.0.4 ou qualquer 10.0.0.x/24) deseja acessar a aplicação pelo IP privado 10.0.0.2 o fluxo não irá para o fortigate, o fluxo é direcionado via L2 para aplicação. Sem passar pelo Fortigate. O Fluxo irá para o fortigate apenas em casos de acessos à redes externas. Entretanto, confesso que não vejo porque aplicar NAT em cenários de fluxo de rede dentro do mesmo segmento 10.0.0.x para 10.0.0.x. Nestes casos não seria necessário aplicar NAT. Cenário 02: Aplicação com endereço IP publico Considerando que uma workstation dentro da rede 10.0.0.0/24 solicitasse uma aplicação que sua resolução de DNS indica um IP de WAN. Neste caso, temos problemas de ARP. Por exemplo, caso uma workstation (10.0.0.4) solicite um IP de WAN 100.100.0.0, no momento em que o pacote chegar para o fortigate e ele realizar o IP Pool nat para a origem 10.0.0.4. Esse pacote entraria em conflito pois existem dois endereços IP iguais na rede, com endereços MAC diferentes. Não sei se respondi sua pergunta, mas qualquer coisa coloca aqui!! abraços meu querido! tamo junto!
Olá Matheus parabéns pelos vídeos sempre muito ricos em detalhes, eu testei aqui na versão 7.11 não funciona, vi que você esta usando a versão 6.47 não testei nela, porem na sua regra dstnat segundo os teste que eu fiz sua regra tem um erro, por exemplo se eu não especificar a interface a regra vai pegar todas as conexões independente de onde vier isso elimina sua regra de hapinat gostaria que vc validasse isso pois essa solução não funciono pra mim, ( se não especificar a interface na regra dstnat qual endereço ou hoste que vc digitar usando aquela porta vai ser redirecionado para aquele roste isso gera um problema pois se eu tiver que acessa um cliente fora da minha rede que usa a mesma porta não conseguirei) obs: estou apenas tentando contribuir e tambem ser ajudado pois preciso que essa solução funcione hehehe
falaa man mas se eu desejo que o servidor seja acessível tanto pela internet, quanto pela minha rede local, entendo que não poderia ser especificado a interface. Pelo menos não pro laboratório. Claro que seria possível melhorar a regra, mas teria ver caso a caso. Talvez não tenha entendido a sua pergunta, mas no cenário que você colocou, como ficaria essa configuração? abraços
Olá Matheus. O switch interno aqui está ligado na interface eth2, acredito que o masquerade deva ser apontado pra ela (out interface), mas ocorre esse erro: Interface matcher not possible when is slave. Sabe qual o problema?
Gostou? Compartilhe, deixe seu like e conta aqui embaixo o que mais você gostaria de ver no canal!
Índice Do Vídeo:
00:00 Hairpin NAT overview
08:13 Demonstração em laboratório
Download de Configurações:
drive.google.com/drive/folders/1W6kEBYgt-bopNq6sxSe-OhsZAg156Ep-?usp=sharing
Link para curso de Redes de Computadores - TCP/IP:
go.hotmart.com/G73136555G
Também tenho comunidades:
Discord: discord.gg/U6WR5Tshav
Telegram: t.me/matheuslealcomunidademorcego
Me siga nas redes sociais:
📲Instagram: instagram.com/matheuslealmvl/
📲LinkedIn: www.linkedin.com/in/matheusvleal/
Para consultorias, dúvidas e sugestões:
networks.mvl@gmail.com
Ótima aula , obrigado.
Ótima aula. Obrigado por compartilhar o seu conhecimento.
Estava procurando essa solução ajudou demais, obrigado!
Poste mais conteúdos, ganhou um inscrito!
Já vi esse cenário antes em um sistema instalado em tablets de vendas que podia estar na loja ou na rua com acesso externo… No meu caso como a RB estava resolvendo DNS fixei no DNS o ip do servidor… So tomar o cuidado de subir o serviço do servidor na mesma porta que foi usada no Nat. Desta forma evita usar nat
Como iria funcionar em um cenário com dois links? O link principal sem ip público e o segundo link que fica como backup é o que tem ip público? Teria que fazer um ajuste para que não saia pelo link principal e saia no secundário não é?
No meu caso eu não especifiquei a interface de saída, mas precisei especificar a dst. port para que o masquerade funcionasse.
video muito bom. 👍
E quando for pra testar redirecionamento externo? Por exemplo acessar externamente pela porta 80 e 443 o apache de um servidor local, como fica essa regra?
configura um DNAT padrão
Muito bom, bem ilustrativo e didático. Agora me lembrou um case que pode ocorrer, como todo mundo dentro da rede 10.0.0.0/24, vai acessar a aplicação no 10.0.0.2 como se fosse o 10.0.0.1, caso por exemplo alguém dentro da rede local fosse bloqueado por erro de senha (bloqueando a origem IP 10.0.0.1), todo mundo de dentro da rede terá a aplicação bloqueada (o mesmo vale pra log do IP de origem etc, todo mundo chega como 10.0.0.1). Pensando nisso, não seria melhor aplicar um pool Nat ( eu sei que isso trem no fortigate, inclusive no fgt ele já faz o que foi explicado nesse vídeo automaticamente). Explico: se fazer um pool Nat de 1 pra 1 com rede 10.10.10.0/24 vamos supor mascarar a origem do 10.0.0.3 com o IP 10.10.10.3, mascarar a origem do 10.0.0.4, com o IP 10.10.10.4 e assim por diante, não seria uma melhor forma de contornar os possíveis problemas e deixar essa solução do dnat pra rede local um pouco mais sofisticada? Eu já fiz um pouco no fgt, mas confesso que ainda estou engatinhando pra achar a melhor forma possível pra resolver esse problema. Se me permitir, fica uma sugestão pra algum vídeo do fortigate (em especial mostrando por linha de comando a conexão ocorrendo). Parabéns pelo seu trabalho, forte abraço
Fala meu mano! Não sei se entendi muito bem sua pergunta, mas vamos lá:
Cenário 01: Aplicação com endereço IP privado
em um cenário que uma workstation (10.0.0.4 ou qualquer 10.0.0.x/24) deseja acessar a aplicação pelo IP privado 10.0.0.2 o fluxo não irá para o fortigate, o fluxo é direcionado via L2 para aplicação. Sem passar pelo Fortigate. O Fluxo irá para o fortigate apenas em casos de acessos à redes externas.
Entretanto, confesso que não vejo porque aplicar NAT em cenários de fluxo de rede dentro do mesmo segmento 10.0.0.x para 10.0.0.x. Nestes casos não seria necessário aplicar NAT.
Cenário 02: Aplicação com endereço IP publico
Considerando que uma workstation dentro da rede 10.0.0.0/24 solicitasse uma aplicação que sua resolução de DNS indica um IP de WAN. Neste caso, temos problemas de ARP.
Por exemplo, caso uma workstation (10.0.0.4) solicite um IP de WAN 100.100.0.0, no momento em que o pacote chegar para o fortigate e ele realizar o IP Pool nat para a origem 10.0.0.4. Esse pacote entraria em conflito pois existem dois endereços IP iguais na rede, com endereços MAC diferentes.
Não sei se respondi sua pergunta, mas qualquer coisa coloca aqui!!
abraços meu querido! tamo junto!
Não é a melhor solução, mas funciona, quando o dono da empresa quer acessar as cameras “DVR” pela WAN e pela LAN. É o jeito.
famosas gabiarras
Olá Matheus parabéns pelos vídeos sempre muito ricos em detalhes, eu testei aqui na versão 7.11 não funciona, vi que você esta usando a versão 6.47 não testei nela, porem na sua regra dstnat segundo os teste que eu fiz sua regra tem um erro, por exemplo se eu não especificar a interface a regra vai pegar todas as conexões independente de onde vier isso elimina sua regra de hapinat gostaria que vc validasse isso pois essa solução não funciono pra mim, ( se não especificar a interface na regra dstnat qual endereço ou hoste que vc digitar usando aquela porta vai ser redirecionado para aquele roste isso gera um problema pois se eu tiver que acessa um cliente fora da minha rede que usa a mesma porta não conseguirei) obs: estou apenas tentando contribuir e tambem ser ajudado pois preciso que essa solução funcione hehehe
falaa man
mas se eu desejo que o servidor seja acessível tanto pela internet, quanto pela minha rede local, entendo que não poderia ser especificado a interface. Pelo menos não pro laboratório. Claro que seria possível melhorar a regra, mas teria ver caso a caso.
Talvez não tenha entendido a sua pergunta, mas no cenário que você colocou, como ficaria essa configuração?
abraços
Olá Matheus.
O switch interno aqui está ligado na interface eth2, acredito que o masquerade deva ser apontado pra ela (out interface), mas ocorre esse erro:
Interface matcher not possible when is slave. Sabe qual o problema?
está associado a alguma bridge ou bouding? pode ser algo nesse sentido.
abraços