Juliano, Entao e necessario eu fazer essa divulgacao de rotas por causa dos encaminhamentos e o gateway central digamos assim e essa maquina IP 192.168.10.1 somente ele conhece todas as rotas, ate pq eu tenho conexoes via mpls e radio, entao e extremamente necessario que seja divulgadas essa rotas no firewall. Agora o que eu precisava fazer eu ainda nao conseguir preciso por exemplo tirar o ip 200.x.x.x direto da placa de rede do servidor e colocar 192.168.x.x e fazer esse encaminhamento atraves desse cara.
Resultado do IP ROUTE LIST: firewall:~# ip route list 200.212.230.0/26 dev eth2 proto kernel scope link src 200.212.230.3 200.205.182.64/26 dev eth1 proto kernel scope link src 200.205.182.94 192.168.100.0/24 via 192.168.10.1 dev eth0 192.168.21.0/24 via 192.168.10.1 dev eth0 192.168.20.0/24 via 192.168.10.1 dev eth0 192.168.50.0/24 via 192.168.10.1 dev eth0 192.168.19.0/24 via 192.168.10.1 dev eth0 192.168.18.0/24 via 192.168.10.1 dev eth0 192.168.17.0/24 via 192.168.10.1 dev eth0 192.168.16.0/24 via 192.168.10.1 dev eth0 192.168.15.0/24 via 192.168.10.1 dev eth0 192.168.30.0/24 via 192.168.10.1 dev eth0 192.168.14.0/24 via 192.168.10.1 dev eth0 192.168.95.0/24 via 192.168.10.1 dev eth0 192.168.13.0/24 via 192.168.10.1 dev eth0 192.168.12.0/24 via 192.168.10.1 dev eth0 192.168.11.0/24 via 192.168.10.1 dev eth0 192.168.10.0/24 via 192.168.10.1 dev eth0 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.30 192.168.9.0/24 via 192.168.10.1 dev eth0 default via 200.212.230.1 dev eth2 default via 200.205.182.65 dev eth1 Resultado do ip addr list: firewall:~# ip addr list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:c0:9f:22:a9:9c brd ff:ff:ff:ff:ff:ff inet 192.168.10.30/24 brd 192.168.10.255 scope global eth0 inet6 fe80::2c0:9fff:fe22:a99c/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:01:02:39:62:3e brd ff:ff:ff:ff:ff:ff inet 200.205.182.94/26 brd 200.205.182.127 scope global eth1 inet 200.205.182.68/26 scope global secondary eth1 inet6 fe80::201:2ff:fe39:623e/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:1d:0f:be:49:ef brd ff:ff:ff:ff:ff:ff inet 200.212.230.3/26 brd 200.212.230.63 scope global eth2 inet6 fe80::21d:fff:febe:49ef/64 scope link valid_lft forever preferred_lft forever Resultado do route -n : firewall:~# route -n Tabela de Roteamento IP do Kernel Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface 200.212.230.0 0.0.0.0 255.255.255.192 U 0 0 0 eth2 200.205.182.64 0.0.0.0 255.255.255.192 U 0 0 0 eth1 192.168.100.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.21.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.20.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.50.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.19.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.18.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.17.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.16.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.15.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.30.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.14.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.95.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.13.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.12.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.11.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.9.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 0.0.0.0 200.212.230.1 0.0.0.0 UG 0 0 0 eth2 0.0.0.0 200.205.182.65 0.0.0.0 UG 0 0 0 eth1 Essa situacao pra mim e nova eu sempre tinha visto ser feito atraves mesmo de aliases como vc trata que eu chamava de eth virtual, se tiver mais alguma dica. atenciosamente, Fernando Felicissimo 2009/5/20 Juliano F. Ravasi <[email protected]>: > Fernando Cesario wrote: >> Os testes feitos sao pings para o proprio ip de maquinas externas. >> Sim existe um grande e unico motivo hoje a maioria dos meus servidores >> de internet estao publicados diretamente com IP VALIDO entao o que eu >> preciso fazer e fazer o cadastro dos meus ips validos no meu firewall >> e ai ao invez do servidor estar com esse ip valido ele fica no >> firewall e eu faco o encaminhamento pro ip da lan. > > Ok, essa configuração é estranha. Acredito que algum daemon em execução > (NetworkManager?) esteja removendo o IP da interface, ou alguma rota da > tabela de rotas. > > Em geral, você não precisa de aliases de interfaces para apenas ter um > IP adicional numa interface. O Linux permite que uma mesma interface > tenha vários endereços IP, sem precisar criar aliases: > > ip addr add 200.205.182.94/26 dev eth1 > ip addr add 200.205.182.68/26 dev eth1 > > Você só deve criar aliases se você precisa de uma unidade de roteamento > adicional (geralmente como origem de rota), e mesmo assim, ainda é > preferível usar o parâmetro 'src' para o 'ip route'. Na imensa maioria > dos casos, o uso de aliases é desencorajado. > >> cat /etc/network/interfaces >> (...) >> iface eth1 inet static >> address 200.205.182.94 >> netmask 255.255.255.192 >> >> iface eth1:1 inet static >> address 200.205.182.68 >> netmask 255.255.255.192 > > Eu não estou familiarizado com a sintaxe da configuração de interfaces > de rede do Debian. Verifique se não é possível atribuir mais de um > endereço IP para a mesma interface. > > Procure não usar 'route', e passe a usar 'ip route'. O comando 'route' > faz parte de uma interface obsoleta do Linux, mantida apenas para manter > compatibilidade com scripts antigos. O comando 'ip' e todos os seus > subcomandos são a maneira mais moderna de interagir com o subsistema de > redes do Linux. > > Pelo que eu entendi: Os IPs públicos do seu roteador são 200.205.182.94, > 200.205.182.68 e 200.212.230.3. Na sua rede interna ele é 192.168.10.30, > e há diversas outras subredes da sua LAN que você acessa passando por um > outro roteador 192.168.10.1. > > Algumas conexões ao endereço 200.205.182.94 são redirecionados para um > outro servidor, 192.168.14.4, que está em outra sub-rede (para chegar > até esse servidor você tem que passar pelo 192.168.10.1). > > Outras conexões, para o endereço 200.205.182.68 são redirecionadas para > 192.168.30.1, que também está em outra sub-rede. Em momento nenhum você > utiliza este IP como origem de rota, já que o redirecionamento é criado > por uma regra DNAT do iptables. > >> firewall:~# route -n > > Sugestão: > ip route list > > > Problema 1: Você tem duas rotas de saída, com a mesma métrica, em duas > interfaces diferentes (eth1 e eth2), tem certeza de que isso está certo? > >> 0.0.0.0 200.212.230.1 0.0.0.0 UG 0 0 0 eth2 >> 0.0.0.0 200.205.182.65 0.0.0.0 UG 0 0 0 eth1 > > > Problema 2: Você tem duas rotas para atingir 192.168.10.0/24, uma > vizinha e uma via 192.168.10.1. Isso definitivamente não pode estar correto: > >> 192.168.10.0 192.168.10.1 255.255.255.0 UG 0 0 0 eth0 >> 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > > > Você está gerenciando um número muito grande de sub-redes, > desnecessariamente. Isso é ótimo para causar problemas, especialmente > por descuido humano. Você deve ter sua rede estruturada na forma de uma > árvore (talvez com raras exceções), e então fazer os IPs seguirem esta > mesma árvore. Todas essas sub-redes (192.168.9.0/24, de ..11.0/24 até > ..21.0/24, ..30.0/24, ..50.0/24, ..95.0/24 e ..100.0/24) estão indo numa > única direção (via 192.168.10.1). Isso é um bom indício de que as > numerações de todas elas estão erradas. > > Se você rearranjar todas estas redes com numeração a partir de > 192.168.128.0/24, então você poderá ter uma única rota para > direcioná-las todas para o roteador em questão: > > ip route add 192.168.128.0/23 via 192.168.10.1 dev eth0 > > Se existirem mais ramificações, aplique o mesmo princípio recursivamente > nos roteadores seguintes. > >> echo "1" > /proc/sys/net/ipv4/ip_forward >> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > > Sugestão: > sysctl net.ipv4.ip_forward=1 > sysctl net.ipv4.icmp_echo_ignore_broadcasts=1 > >> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.94 >> --dport 80 -j DNAT --to 192.168.14.4:80 >> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.94 >> --dport 110 -j DNAT --to 192.168.14.4:110 >> (...) > > Não poderia ser atribuído um IP verdadeiro a este servidor, e direcionar > todo o tráfego (possivelmente filtrado) diretamente para o servidor? > Remove-se o NAT para esse servidor em questão, deixando apenas o > firewall. Não é muito legal dois hosts (firewall e o servidor em > questão) compartilharem o mesmo endereço IP. > >> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp -d 200.205.182.68 >> --dport 80 -j DNAT --to-destination 192.168.30.1:80 > > Idem. > >> /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > Isso está errado. Sequer faz sentido para a sua rede. O correto deveria ser: > > iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j SNAT > --to-source 200.205.182.94 > > Isso, é claro, supondo que você tenha UMA rota de saída (aqui estou > considerando a eth1). Precisa determinar o que aquela segunda rota de > saída para eth2 está fazendo lá. > >> Acredito que agora contenha todas informações necessario para entender >> o pq desse problema. > > Pode ser uma entre muitas coisas... a primeira, listada exaustivamente > acima, é remover as ambiguidades da sua rede. Depois que não tiver mais > ambiguidades, aí fica mais fácil achar o problema. > > Depois que os problemas acima estiverem resolvidos, se o problema > aparecer novamente, seria bom uma listagem de rotas (ip route list) e de > endereços (ip addr list) antes e depois de enfrentar o problema (para > saber se algum daemon está mexendo nas rotas), e também observar como > seu firewall responde via 'arping' de cada uma das interfaces. > > Att, > Juliano. > > > -- > Juliano F. Ravasi ·· http://juliano.info/ > 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 > > "A candle loses nothing by lighting another candle." -- Erin Majors > > * NOTE: Don't try to reach me through this address, use "contact@" instead. > --------------------------------------------------------------------------- Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utilização da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
