Rede 500 clientes, melhor servidor central e tudo bridge?

Citação:

Postado originalmente por Josue Guedes

Bom dia amigo, considerando sue número de clientes suas experiências são importantes. Gostaria que explicasse sua configuração.

Você usa Cache full, e usa roteamento entre as torres, seu servidor de cache é o mesmo de saída aos clientes? Ou seja nele também é feito o controle de banda é outros?

Então você tem uma faixa de IP para cada torre, e na interface de saida do cache você tem uma faixa correspondente para cada faixa usada nas torres?

Suas RB´s fazem algum roteamento ou isso só é feito nos seu servidores?

Com esse roteamento todo, como você entrega Ip Válido?

Grato por sua atenção.

amigo o seguinte, tive um erro de digitação no local de 7 mil, são 700 clientes, foi mal

a duvidas dos amigo em relação a IP e Proxy, cada interface da torre tem um range de ip /24 só é feito nat no central (porem na porta 80 não faço, vou explicar), eu gosto de colocar ospf para ficar as redes dinamicas e sem dor de cabeça em questão de rota, o segredo esta quando chega no central, tenho no central 2 placas de rede para a saida, uma eu chamo de proxy e outra de link, assim faço como se fosse um balancer por serviço entre as duas saidas.

para a proxy envio tudo que é porta 80, na outra fica com o restantes observe as reguas

Citação:

/ip firewall mangle
add action=mark-routing chain=prerouting comment="Direcionamento para o proxy" disabled=no dst-port=80 new-routing-mark=SquidThunder passthrough=yes protocol=tcp

/ip route
add check-gateway=ping comment="Squid Thunder" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=172.16.0.1 routing-mark=SquidThunder scope=30 target-scope=10

add comment=Link disabled=no distance=10 dst-address=0.0.0.0/0 gateway=189.108.214.33 scope=30 target-scope=10

aqui já temos uma separação da conexão dos clientes, a interface do link cai direto no roteador e vai para o dedicado, a do proxy passa pelo Debian+Squid+Thunder+bind9_cache, assim faço um QoS para a interface do proxy, lembrando que precisa de uma maquina boa para isso aqui utilizo Intel Core2 Quad Q9550 2.83GHz com 8 gb ddr2 e 4 hd de 1.5t cada
o questão de log do sarg, se deixar como esta ele vai aparecer apenas log vindo do ip do seu mk central e essa não é a ideia, para resolver isso no nat do central tem que retirar para a interface do proxy e fazer o nat apenas no cache, assim o mk vai direcionar o cliente com o ip dele para o proxy, a regra que uso é a seguinte

Citação:

add action=masquerade chain=srcnat comment="mascarar todos os clientes" disabled=no out-interface=!ether3 src-address=10.0.0.0/8

sobre o cache, o cache full utilzei esses tutoriais THUNDERCACHE.ORG

aki estão as reguas do meu rc.local do cache

Citação:

#ativar interface clientes
ifconfig eth1 172.16.0.1 netmask 255.255.255.252 up

#ativar NAT
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#ativar proxy transparente
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

# rotas
route add -net 10.0.0.0/8 gw 172.16.0.2
route add -net 172.0.0.0/8 gw 172.16.0.2
route add -net 192.168.0.0/16 gw 172.16.0.2
route add -net 189.108.215.0/24 gw 172.16.0.2

# mount backup de logs
# mount nfs backup
# mount -t nfs 189.108.214.34:/mnt/BKSquidLog/ /mnt/backup/

exit 0

amigos tem que fazer rota para os seus clientes, pois o squid tem que saber que os ips que estão vindo estão atras do central

lembando que não adianta copiar e colar tem uqe entender o que esta acontecendo senão vai dar pau.

Citação:

Postado originalmente por Josue Guedes

Acho que a grande questão é, se está tudo roteado como é o cache, e o repasse de ip válido.

o repasse de ip valido eu faço no hotspot que esta no central, um exemplo,

Citação:

/ip hotspot ip-binding
add address=10.6.2.2 comment="nome do cliente" disabled=no server=hs-wlan1-Vermelho to-address=189.10x.xxx.x8

e na torre marco para o dhcp entregar o ip 10.6.2.2 sempre para este cliente com mac 00:1x:0x:8x:xC:Cx

Citação:

Postado originalmente por neon

você faz controle de banda e filtros de "pragas" na torre?

voce usa RBs ou PC-AP ?

como fica o processamento de uma torre com 120 clientes pendurados (30 por cartao) ?

amigo eu não deixo um cliente se comunicar com outro dentro da minha rede, assim evito varias coisa, o controle de pragas eu fiz uma vez, mais tem sempre uma portas ou outra que é fod@ bloquear, pois sempre tem o joginho la da put@ que pario que para de funcionar, agora não bloqueio mais, cada um é responsavel por proteger o seu pc, salvo as empresas que pagão um extra para ter portas bloqueadas, o famoso plano adicional "firewall" e bloqueio de msn, p2p e sites de sacanagem e orkut, que as empresas pagam para que eu o faça, é bem simple as regras estão abaixo

Citação:

/ ip firewall filter
dst-address=189.108.214.34 comment="LIBERAR - dns" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-address=189.x.x.x comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-address=189.x.x.x comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=80 protocol=tcp comment="portas" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=25 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=110 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=8291 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=53 protocol=udp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=53 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=443 protocol=udp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=443 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=20-22 protocol=tcp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" dst-port=20-22 protocol=udp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" src-port=53 protocol=udp comment="" disabled=no
add chain=forward action=accept in-interface="wlan3" src-port=53 protocol=tcp comment="" disabled=no

deixo no meu central, se alguma empresa tiver no plano firewall é só add a regua para drop

Citação:

add chain=forward action=drop in-interface="wlan3" src-address=ip do cliente comment="" disabled=no

geralmente é só isso, e o bloqueio dos sites faço no squid, é um jeito que achei de ganhar um extra, deixar o cliente que quer segurança satisfeito, e o que gosta dos joginho livre para brincar

espero ter ajudado

Citação:

Postado originalmente por diox

Olha pelo desabafo sua ex bridge erá das bravas :) massa massa, conte me , quantos cliente usted tens??? hehehe, usa cada torre roteada? showw, abraços!

estamos partindo pros 30 e poucos mbs

cada repetidora uma rota /30 ou /29

temos 2 redes /24

estamos agora analisando pra comprar uma ASN

Sei que isso já foi discutido aqui varias vezes, mas a regra normalmente é:
rotemento-> profissional, organizado e muito poder de expansão(tecnicamente mais complexo, porém reduz o custo a longo prazo)
bridge=> desorganizado, baixa flexibilidade, não muito profissional(poder ser profissional mas depende de alto custo de equipamentos layer2)

como ja disse o Sérgio...

Alguém sabe pq se chama Mikrotik Router??
ou então porque a RouterBoard leva esse nome???

Citação:

Postado originalmente por tnarnold

Sei que isso já foi discutido aqui varias vezes, mas a regra normalmente é:
rotemento-> profissional, organizado e muito poder de expansão(tecnicamente mais complexo, porém reduz o custo a longo prazo)
bridge=> desorganizado, baixa flexibilidade, não muito profissional(poder ser profissional mas depende de alto custo de equipamentos layer2)

como ja disse o Sérgio...

Alguém sabe pq se chama Mikrotik Router??
ou então porque a RouterBoard leva esse nome???

Olha amigo, não concordo não, já fiz testes com roteamento e tive uma rede mais "presa", foi impressão que tive. Estou aberto a opniões quanto a esse assunto, inclusive quero mudar algumas coisas aqui, mais não considero como "não profissional" por estar em bridge. Temos cerca de 400 clientes, e nunca tivemos problemas com a bridge. Temos algumas verdades com as desvantagens a respeito de segurança na bridge, mais a experiencia que tive é que a bridge deixa a rede mais leve.

Então é o seguinte, o que vocês dizem disso aqui então:

Servidor/HTB/NAT/Squid -----------------Torre1--------------Torre2-----------Torre3

No caso acima teríamos uma bridge nas RB que fazem o link de radio do servidor até as torres, e clientes, hoje eu uso mais ou menos assim. Com cache full transparente.

Usando roteamento seria mais ou menos assim que penso:

Servidor ----10.0.0.1/24-------10.0.0.2/24---Nat Clientes-----Clientes em 192.x.x.x/24

No exemplo acima, eu usarei bridge com os links 5,8Ghz para interligar outras torres com outros NAT para clientes, será usado bridge, mais apenas no enlaces 5,8 entre as torres. Para cada cartão de clientes teríamos um nat e uma faixa de IP diferente.

Minhas dúvidas são:

Meu controle de banda é feito no servidor CentOS, com HTB, é controlado via MAC de cada cliente. Mesmo com o NAT nas RB´s, eu continuarei a ter o repasse de MAC e o controle de banda, ou terei que ter o controle de banda na RB?

Como fica o cache, com o roteamento? Uso cache full, tenho controle de banda do cache separado para cada cliente, será que mesmo depois do roteamento nas RB´s, os pacotes do cache continuarão passando a full para os clientes?

As RB´s fazem o roteamento sem apertar no uso do processador?

Aguardo a opnião de vocês. Grato.

nesse post tem uma resposta para a pergunta que é semelhante a essa questão de roteamento tem uma imagem em anexo da idéia do que digo:
https://under-linux.org/f130687-nat-sobre-nat-alguem-sabe-como-ter-acesso#post427224

quanto ao cache não tem menor problema podes colocar o squid no lugar que qzer da rede... e nesse modelo ainda te da a flexibilidade de balancear e usar protocolos de rotemento que te facilitam a vida na hora de gerenciar...o OSPF por exemplo.... controle de banda se faz em cada nó que o cliente estiver conectado, em cada routerboard ou pcap com mikrotik no caso ou até mesmo com linux, pra RB roteamento e controle de banda não é nada pra potencia que ta os processadores delas...
o cache full se configurado nos mikrotiks continua funcionando sem problemas, talvez até com mais controle sobre eles... (eu não uso cache full mas conheço a solução, fiz poucos testes e laboratorio mas ao meu ver só é interessante quando o proxy esta na rede cabeada) mas o mais vantajoso é aquele modelo que o administador de rede tem mais dominio das ferramentas se não tem dominio de roteamento (sugiro que comece a testar em laboratorio os conceitos disso tem varias ferramentas hoje em dia pra faze miséria com estudos de rede...vbox,vmware,packet tracer, etc...) se não tem dominio sobre roteamento fica com a bridge mesmo, não sei como consegue mas.... ta uma forma de conectar os clientes né? ta funcionando não quer passar por transtornos e custos de migração é a alternativa!

Pois é, uma das idéias que não gosto é de ter que controlar a banda em cada nó, na RB. Aqui a migração foi inversa, de roteadas para bridge. Lógico que na época a rede era pequena. O cache full com HTB pode-se controlar a banda do cache por cliente, no caso ttenho 2 controles de htb, um normal e um do cache, com isso não tenho problemas de excesso de banda e tals. Bom vou dar uma olhada no controle de banda nas RB´s, e ver se consigo fazer nelas o que faço hoje com HTB no CentOS. Já testei OSPF e um dos interesses em migra a rede é justo por causa dele.

quarto: me focalizo em grandes empresas (Embratel,Brt) la é tudo roteado e o trafego é grande!

Pessoal as teles trabalham completamente diferente, através de redes MPLS em equipamentos de alta qualidade que permitem QOS,Mapeamento por tipo de serviço, etc....

Há como fazer isto sobre uma rede com mikrotik ?
Há sim, existe o recurso de MPLS no Mikrotik, no meu caso optei por não faze-lo ainda, por adicionar mais um overhead a minha rede, haja visto que utilizo o PPPoE.