como usar IPs Válidos e Privados sem proxy arp?

[NielsonPadilha]

Olá amigos recebi dos blocos de ips do meu fornecedor sendo eles:

/30(Para receber o link) e /29(Para meu uso em servidores, mk auth....)

Minha rede privada:

- 192.168.4.1/22 (Estrutura da rede, ip da bridge)
- 172.16.0.0/21 (Clientes pppoe)
- 172.16.254.1/30 (Thundercache)

Fiz o mascaramento para essas 3 classes privadas para poder navegar, e deixar os ips válidos sem mascaramento.

o /30 está funcionando normalmente. Porém o /29 que estou usando não funciona muito bem para fora da rede, tem horas que abre e tem horas que não abre.

/30
IP: 170.231.192.130
MAS: 255.255.255.252 /30
GAT: 170.231.192.129

/29
IP: 170.231.192.202(Estou usando esse no mk auth)
MAS: 255.255.255.248 /29
GAT: 170.231.192.201 (Coloquei esse IP na bridge)

Gostaria de usar o /29 sem usar proxy arp e eliminar esse problema de ficar hora funcionando hora não. No /29 criei uma rota com Dst. Address 170.231.192.200/29 saindo com gateway pela ether1 (Ether1 é a que recebe o link de um PTP em bridge com /30)

Alguém me da uma luz?

[Maurobranquinho]

Aqui na nossa rede, temos um /28 também tive este problema!!! No teu caso é um pouquinho diferente pois tu tem dois blocos mas acredito que irá funcionar, então vou seguir a mesma lógica que está aqui.
O que acontecia comigo é que ele não repassava o ARP de uma interface para a outra então a solução seria você publicar este ip lá em IP=>ARP:
Vá lá na aba ARP, coloque o IP em questão apontando para a interface que chega o link e marque a opção Published, o MAC ADDRESS vai ficar no formato 00:00:00:00:00:00. Dando um Ok ele deverá estar funcionando normalmente.
Não sei se publicando o bloco todo funciona do mesmo jeito mas faça um teste!!!

[MichelGoulart]

AC...

[inquiery]

Buenas @NielsonPadilha

Se o teu fornecedor te deu 2 blocos de IP, e o menor (o /30) você usa para receber o link, então certamente eles direcionaram todo o trafego para o bloco /29, para o gateway da sua rede, no IP 170.231.192.202.

Ou seja, todo o trafego externo para qualquer IP do bloco /29, vai cair no seu gateway. Então como você ja tem o IP 170.231.192.201 em uma interface do gateway (você comentou que colocou em uma bridge), então qualquer dispositivo conectado nessa bridge com um IP dentro desse bloco /29 vai ser um destino roteavel. Você só tem que cuidar para não mascarar o trafego dessas redes junto com o trafego de internet dos clientes.

Mas, no fim das contas, não existe nada de especial que você tenha que fazer para isso funcionar, basta cuidar para não "bloquear" esse trafego com regras de NAT ou de filtro.

[NielsonPadilha]

Olá Pessoal boa tarde obrigado pela ajuda. eu tenho um bridge que interliga a ether2(Switch) e ether11(servidor com vmware, mk auth...).

Então cologuei o gateway 170.231.192.201 na bridge e fui lá em rotas e criei uma rota com Dst Address 170.231.192.200/29 com gateway para porta ether1.



Será se fiz correto ? Só que a rota do /29 fica somente em azul com S (Static) mais não aparece o A de ativo.

Obrigado

[inquiery]

Você não tem que configurar rota nenhuma neste caso.
O seu fornecedor está roteando o bloco /29 para o seu gateway da rede /30 (no caso 170.231.192.130).

No seu cenário, você não precisa dessa bridge pelo que entendi. Você pode simplesmente colocar o IP 170.231.192.201 na ether11 onde esta o seu servidor com MK-Auth, e no MK-Auth o IP 170.231.192.202.

Só isso já vai funcionar. É para isso que roteadores servem, para rotear pacotes entre as redes que eles conhecem. Ou seja, sendo que seu fornecedor vai enviar todos os pacotes que o destino é o 170.231.192.200/29 para você (pro seu gateway, da rede /30, que é 170.231.192.130), o seu gateway vai receber esses pacotes e vai verificar o destino, e se ela conhece a rede do destino, ele encaminha o pacote para o dispositivo dentro da rede que possui aquele endereço. E então assim, se alguém mandar um pacote para o endereço 170.131.192.202, ele vai no cair no seu fornecedor, que vai rotear para o seu gateway, que no caso conhece aquele rede e existe um dispositivo com aquele endereço e ele vai rotear para lá.

Se alguém da sua rede interna tentar acessar o mesmo endereço, a mesma coisa. O seu gateway vai ver se conhece a rede destino, e conhecendo ela vai ver qual é o dispositivo dono do endereço e destino e encaminha o pacote pra la.

[NielsonPadilha]

Você não tem que configurar rota nenhuma neste caso.
O seu fornecedor está roteando o bloco /29 para o seu gateway da rede /30 (no caso 170.231.192.130).

No seu cenário, você não precisa dessa bridge pelo que entendi. Você pode simplesmente colocar o IP 170.231.192.201 na ether11 onde esta o seu servidor com MK-Auth, e no MK-Auth o IP 170.231.192.202.

Só isso já vai funcionar. É para isso que roteadores servem, para rotear pacotes entre as redes que eles conhecem. Ou seja, sendo que seu fornecedor vai enviar todos os pacotes que o destino é o 170.231.192.200/29 para você (pro seu gateway, da rede /30, que é 170.231.192.130), o seu gateway vai receber esses pacotes e vai verificar o destino, e se ela conhece a rede do destino, ele encaminha o pacote para o dispositivo dentro da rede que possui aquele endereço. E então assim, se alguém mandar um pacote para o endereço 170.131.192.202, ele vai no cair no seu fornecedor, que vai rotear para o seu gateway, que no caso conhece aquele rede e existe um dispositivo com aquele endereço e ele vai rotear para lá.

Se alguém da sua rede interna tentar acessar o mesmo endereço, a mesma coisa. O seu gateway vai ver se conhece a rede destino, e conhecendo ela vai ver qual é o dispositivo dono do endereço e destino e encaminha o pacote pra la.

O servidor ta saindo pra net, funciona o ping mais ao tentar acessar de fora não vai.

O Mascaramento está assim para as redes privadas:


E a configuração do mk auth ta certinha, acesso normalmente na rede interna e pelo ssh do mk auth pingo pra fora da rede tranquilamente, porém não consigo acessar fora da rede.


Obrigado

[inquiery]

Vove nao tem regras nos filtros que possam estar dropando pacotes?

[NielsonPadilha]

Os únicos filtros que tenho são do mkauth, teste de velocidade para thunder e bloqueio de acesso dns externo na rede interna.

Foto:

[andrecarlim]

Posta um print do teu address ai!

[NielsonPadilha]

qual parte ?

[andrecarlim]

Vai em IP -> Address e tira um print e post aí.

[NielsonPadilha]

Segue a foto:

[andrecarlim]

Cara, esta estranho o teu bloco /29, você não precisa configurar nenhuma rota no teu router para ter acesso ao IP 170.231.192.201, por exemplo, partindo desse ponto de vista se você colocar algum servidor ligado a bridge1 usando o IP 170.231.192.202, por exemplo, com a mask 255.255.255.248 (/29) e GW 170.231.192.201, deveria funcionar perfeitamente, isso porque teu uplink tem uma rota lá dizendo que sempre que for necessário acessar algum ip da faixa 170.231.192.200 até 170.231.192.207 o "caminho" é pelo IP 170.231.192.130, IP Wan do PEER (Uplink), no entanto eu fiz um traceroute aqui e parece que teu operador de transito não esta com a rota configurada corretamente para você, vou anexar dois prints, o primeiro para o IP 170.231.192.130, fica perfeito e o segundo, para o IP 170.231.192.201 não avança além do host 10.7.7.201 e não completa, acho que não é problema na tua configuração.

[NielsonPadilha]

vendo trace achei estranho mesmo esse ip 10.7.7.201 é ip do meu ptp-cliente, o 10.7.7.200 é o ptp-ap. O fornecedor do link me passou essas confs do ip e pediu que habilita-se o proxy arp para ativar passagem do link para os demais ips. Porém gostaria de habilitar sem proxy arp.

[andrecarlim]

Cara, desabilita proxy-arp, você não precisa disso, esta roteado, e veja se não tem nenhuma rota atrapalhando no teu cenário.

[NielsonPadilha]

Cara, desabilita proxy-arp, você não precisa disso, esta roteado, e veja se não tem nenhuma rota atrapalhando no teu cenário.

Olá Andre, na parte e rota basicamente oque tenho é isso:

Tirando isso é os PPPoE's conectados.

Será se é alguma configuração errada na parte deles ? Oque você acha que devo pedir pra eles verificarem ?

[andrecarlim]

É isso aí! No entanto ainda esta estranho o traceroute, está parando no 170.231.192.3, que deve ser do teu operador de trânsito, dâ uma conferida com eles, talvez encaminha esse pra eles, só antes de tudo, da uma conferida no teu firewall se está tudo liberado para o teu bloco /29, pelo menos o icmp para a gente poder testar, se estiver com receio de liberar o ICMP, vou deixar as regras liberar o ICMP com certo controle, olha o print:





/ip firewall filter
add chain=input comment="Allow ICMP - Rate Limit" limit=3,5acket protocol=icmp
add action=drop chain=input protocol=icmp

Você pode colocar, na regra de permissão, no dst-address teu bloco /29, assim evita DDoS no ICMP!