m4d3

MikroTik
DE a-Z PARA TODOS OS NÍVEIS
Escrito por: Luciano Rampanelli / M4D3

Dedico este material aos amigos online que conquistei ao longo destes anos, em especial à minha esposa e nossos três filhos Luciano Junior, João Paulo e Pedro, principais motivadores desta publicação.



“Como bons administradores da multiforme graça de Deus, cada um coloque à disposição dos outros o dom que recebeu” (Pedro I, v 4 a 10)



As práticas relatadas aqui estão em uso desde 2007 em diversos provedores comerciais, passo a dividir com todos na busca de dias melhores na "internet brasileira". As técnicas abordadas são baseadas na experimentação e simulação de acordo com as normas e leis que regem o acesso a internet. As informações aqui contidas são parte de algo maior e não foram copiadas ou tomadas em assalto, mas são fruto do esforço individual deste que vos escreve. Faço este documento de uso livre para aqueles que assim necessitarem para uso pessoal e didático. Exceto para fins comerciais, impressão ou divulgação sem expressa autorização do autor.

__________________________________________________________________

Configurando o MikroTik do Zero

Vamos começar configurando um servidor básico com serviço de autenticação, escolhi o pppoe pela facilidade e compatibilidade com a maioria dos sistemas comerciais adotados no mercado além é claro do meu gosto pessoal.

Comecemos escolhendo a versão do MikroTik a utilizar, eu confio e utilizo a bastante tempo a versão 3.30, 4.17, 5.11, procuro manter uma versão estável até ter confiança suficiente de que todos os recursos que necessito estejam funcionando de acordo em uma versão mais atual, que além disso deve ter novos recursos para merecer um upgrade.

__________________________________________________________________

Configuração as Interfaces

Dito isso vamos definir o nome das interfaces, começando com ether1 que vamos re-nomear para “EthLinkD” que será nossa entrada do link, este por sua vez pode ter qualquer origem seja um link dedicado ou uma adsl, trataremos disso mais tarde.


Sem ordem o sucesso é uma possibilidade remota, na seqüência vamos agora re-nomear a interface ether2 para “EthClientes”, que como o próprio nome diz será a interface por onde forneceremos o acesso aos clientes.

O objetivo deste documento não é ser o mais detalhista possível, mas oferecer uma visão clara de como configurar de maneira ordenada e lógica qualquer equipamento, a metodologia empregada na implantação depende muito da necessidade e pré disposições existentes, porém questões como a nomenclatura a ser utilizada e a seqüência só depende da forma de raciocínio de quem esta a configurar e do nível de compreensão pretendido para qualquer usuário que acessar o sistema.

Em seguida faremos as definições de IP que são necessárias ao sistema, note que ate agora estamos fazendo o acesso via MAC o que é extremamente lento.
Supondo que temos um IP roteado disponível para nosso link, seja ele público ou privado, vou identificar uma classe que servirá de exemplo durante nossas explanações.

Classe de IP: 172.16.50.128/29 – Esta será a classe que recebemos do roteador (dedicado ou adsl não importa), no caso o IP que identifica no gateway será o primeiro IP 72.16.50.129 e para a configuração do nosso sistema iremos utilizar o IP 172.16.50.130/29.

__________________________________________________________________

Configuração da Rota Default

Em seguida devemos informar o default gateway 172.16.50.129 na tabela de rotas.

Resultando conforme abaixo em nossa tabela de rotas.

Se obtiver resultado diferente do exemplo (como uma rota na cor azul), pode ser que o IP do gateway não tenha sido encontrado na rede ou que não tenha definido corretamente o endereço IP na etapa anterior.

__________________________________________________________________

Configuração do DNS

Vamos agora para a configuração de DNS, eu particularmente confio no DNS gratuito OpenDNS, porém devo alertar em em certos casos já tive problema por conta disso, um exemplo é quando um dos clientes sabendo que utiliza dos serviços do OpenDNS vai até o site deste serviço e cadastra o/os IP’s utilizados por seu sistema e cria regras de bloqueio (muito úteis inclusive principalmente para limitar serviços indesejados), fazendo isso qualquer resolução de DNS que partir dos IP’s informados na regra de filtro passam a ter as limitações impostas em tais filtros, imagine um usuário mal intencionado bloqueando os serviços de redes sociais, isso iria gerar uma revolta entre os clientes e com certeza não desejamos algo desse tipo.

Portanto se utilizar deste serviço tenha certeza de que está imune a condição citada, outro DNS que posso sugerir são do Google que apresentam na maioria dos casos bom tempo de resposta e disponibilidade, no geral é o que conta, você pode utilizar os de sua preferência, no exemplo vamos utilizar um DNS do Google e outro do serviço gratuito OpenDNS.

GoogleDNS: 8.8.8.8/8.8.4.4
OpenDNS: 208.67.222.222/208.67.220.220

Vale ressaltar que a opção “Allow Remote Request” permite utilizar o IP do seu MikroTik para resolução de DNS e cache deste serviço, sendo desejável eu recomendo que marque esta opção, tendo o cuidado de bloquear requisições vindas de fora do seu sistema para este serviço (90% dos casos).

Além disso devemos alterar o “Cache Size” para algo entre 4096 e 8192 possibilitando armazenar o maior número de endereços DNS no MikroTik local dessa forma agilizando o processo de resolução dos equipamentos cliente quando fizerem uso do servidor DNS disponível no MikroTik.

Tendo concluído com sucesso esta primeira etapa faremos um teste de ping para aferir o funcionamento do sistema básico, começando com um teste direto a um endereço IP. Para tal abra um terminal e digite:

ping 200.221.2.45

O resultado tem que ser como acima, se “packet loss” informar algo diferente de 0% você tem algum problema de conexão ou então o IP que tentou pingar não esta mais acessível.

O próximo passo é testar a resposta dos servidores DNS e para isso vamos executar um ping informando o endereço de um site e não o seu IP.

ping uol.com.br

O resultado deve ser o mesmo anterior.

Desta vez quando efetuamos uma consulta ao DNS cache do MikroTik encontramos as resoluções já consultadas e com TTL não expirado.

Vamos agora definir um DNS próprio para uso nos clientes deste MikroTik em questão, faremos isso acessando o DNS Static, utilizaremos um IP qualquer que no exemplo será 10.0.0.1.

O TTL é o tempo de expiração que vai manter a consulta a este DNS em cache, quando será necessária nova consulta para resolução do endereço, em certos casos é interessante manipular este tempo tendo em vista o grande número de solicitações que podem ser feitas a um mesmo endereço, no caso de haverem poucas mudanças do IP de destino.

Devemos observar que quando houver a manipulação do TTL padrão o resultado pode ser um destino que aponta para um endereço que não corresponde mais ao endereço desejado até a renovação da consulta e portanto podendo causar falha no acesso, o MikroTik não suporta manipulação da tabela DNS cache, e se pretende utilizar este serviço recomendo o BIND9 em servidor Linux que além disso oferece muitas outras possibilidades.

Observe que após a inserção do “DNS Static” imediatamente a tabela “DNS Cache” foi incrementada e o TTL começa a contar até a próxima renovação.

__________________________________________________________________

Configuração do Concentrador PPPOE

Vamos agora configurar o serviço PPPOE, chamaremos o serviço de ‘PC.PPPoE’ e selecionando a interface pela qual os clientes farão acesso a este serviço vamos definir os valores padrões deste servidor.

Não faremos nenhuma alteração nos valores de MTU / MRRU / Timeout / Max Sessions e na maioria dos casos é isso mesmo que recomendo, só altere se houver uma necessidade que de outra forma não pode ser solucionada.

Marque “One Session Per Host” se desejar que apenas um usuário conecte para cada cadastro de usuário/senha.
Com relação ao tipo de autenticação suportada pelo serviço até agora entre os sistemas comerciais que utilizam o FreeRadius só encontrei autenticação PAP, porém isso pode mudar, se o seu sistema suporta mais de um tipo marque as respectivas opções suportadas, caso contrario basta manter apenas PAP e desmarcar as demais, isso inclusive evita comportamento errôneo de alguns sistemas comerciais em uso hoje em dia.
Recomendo que busque informações adicionais sobre cada método, isso não vai mudar a sua vida, mas o hábito de pesquisar as opções o tornará apto a responder as mais diversas perguntas quando questionado.

Obs: se o seu sistema suporta outros métodos eu gostaria de conhecê-lo.

Vamos agora para a configuração do Profile que nada mais é do que as configurações do plano de acesso ao qual o cliente irá pertencer.

No primeiro plano vamos selecionar algo simples para assimilação rápida, vamos chamar de ‘PC.Conecta’ fazendo referencia a um plano de entrada onde o principal objetivo é que acesso a internet. Sendo este um plano básico não tem como foco a velocidade de acesso, a principal característica deste plano será sua velocidade de acesso limitada em 128kbps para download e 64kbps para upload, o que em teoria deve garantir downloads de até 16kb/s e upload de até 8kb/s.

- criando a pool de endereços ip

Em “Local Address” informaremos o IP que o cliente receberá como gateway e em “Remote Address” indicamos a “Pool” de IP’s a qual o profile pertence, ou seja os IP’s que os clientes irão receber após a conexão ter sido estabelecida com o servidor. Para este primeiro plano vamos criar a “Pool” de nome ‘pool_conecta’ a qual inicia no IP 10.0.0.11 e termina em 10.0.0.249, você deve estar se perguntando porquê não começar no antes e ir até o final dos IP’s, eu faço uma reserva em cada pool quando possível para casos especiais em que eu preciso fixar o IP que um determinado equipamento irá receber.

Como resultado teremos a tabela IP Pool conforme abaixo:

- criando o plano de acesso

Na criação do profile ‘PC.Conecta’, selecionamos a ‘pool_conecta’ para o “Remote Address” e mantemos os campos Bridge / Incomming Filter / Outgoing Filter / Address List / WINS Server inalterados, bastando para tanto configurar apenas o campo “DNS Server”.

Utilizaremos o próprio MikroTik como servidor DNS primário, isso nos trará a vantagem do DNS Cache, como DNS secundário vamos utilizar um DNS qualquer informado pela operadora que pode ser obtido junto ao serviço de atendimento ao cliente ou com uma breve busca na internet. Para este caso vamos configurar o secundário com o SuperDNS servidor 1 cujo endereço é dns1.superdns.com.br e seu ip corresponde a 72.233.55.28, entenda que é apenas um exemplo e não recomendo este como seu DNS secundário.

Ainda no profile em questão, na aba “General” as opções “Use Compression/Use VJ Compression/Use Encryption” devem ficar na posição ‘no’ e “Change TCP MSS” em ‘yes’, esta segunda pode lhe economizar alguma dor de cabeça com MSN e coisas do gênero e você pode optar por não utilizar as configurações indicadas aqui e ainda assim não ter problema algum desde que saiba o que esta fazendo, não tenha medo de experimentar pois é também dessa forma que se adquire conhecimento.

Na aba “Limits” vamos utilizar as velocidades relativas ao plano sendo que no MikroTik como indicado no campo “Rate Limit” onde deve ser informado primeiro o upload do plano que no caso é o rx do servidor (em relação ao cliente que é quem vai utilizar o profile) e em seguida informar o download que é o tx do servidor com as velocidades separadas por “/” da seguinte forma 64k/128k ou ainda 64000/128000. O campo “Rate Limit” permite configurações bastante diversas com ou sem omissão de parâmetros, vale a pena estudar a respeito.

Exemplo 1: 64000/128000 ou 64k/128k
2: 51k/102k 64k/128k 40k/81k
3: 51k/102k 64k/128k 40k/81k 8
4: 51k/102k 64k/128k 40k/81k 6 8
5: 51k/102k 64k/128k 40k/81k 128/192 8
6: 51k/102k 64k/128k 40k/81k 128/192 8 32k/64k

Composição do campo “Rate Limit (tx/rx)”
[rx-rate/rx-rate][rx-burst-rate/tx-burst-rate][rx-threshold/tx-threshold][rx-time/tx-time] [prio/prio] [rx-limit-at/tx-limit-at]


- cadastro de usuário

Para saber mais sobre estas opções consulte o manual do MikroTik e/ou defina os valores de exemplo em um plano e consulte na tabela “Queue Simple” a fila do usuário após conexão. Também pode utilizar usar 1M no lugar de 1024k. Pode-se utilizar k, M ou G.

Configurado o primeiro plano de acesso siga configurando os demais para outras velocidades, mas antes disso voltamos ao serviço “PC.PPPoE” e alteramos o “Default Profile” para ‘PC.Conecta’.

Seguindo com a configuração vamos agora cadastrar o primeiro usuário/cliente para conexão via servidor PPPoE. Acesse o menu “Secrets” e preencha os campos conforme indicado:

“Name:” testepc
“Password:” senhapc
“Profile:” “PC.Conecta”
“Service:” (pppoe, para outros tipos selecione da lista)
“Caller ID:” (opcional, cadastre o MAC se quiser amarração)
“Local Address:” (opcional, pode usar outro IP que será o gateway)
“Remote Address:” (opcional, IP do cliente que vai pegar do profile)

O campo “Caller ID:” pode ser preenchido com o MAC Address do equipamento cliente e tem a função de ‘amarrar’ o login/name ao MAC, podemos ainda preencher o campo “Remote Address” caso desejemos que este login/name conecte sempre com o mesmo endereço IP.
O campo “Local Address” é fornecido automaticamente pelo profile selecionado sendo este o gateway da conexão PPPoE, podendo ser informado manualmente caso haja necessidade.

Curiosidades: em versões antigas (2.x) do MikroTik havia um bug de o cliente conectar e não navegar, a navegação somente era possível quando o mesmo recebia outro IP, esta situação era facilmente evitada preenchendo o endereço do “Local Address” nos cadastros.

__________________________________________________________________

Configuração do servidor NTP

Importante: configurar as informações de data, hora e localização, alguns podem achar que é algo desnecessário, eu afirmo que tem muita importância então vamos a isso. Primeiro configuramos o “Manual Time Zone”, no meu caso estou em Comodoro que fica no interior do estado de Mato Grosso, sendo assim o “Time Zone” é -04:00, em seguida acerte os valores da aba “Time”.

Na seqüência configuramos o “NTP Client” para manter nosso relógio em sincronismo, fazemos isso utilizando os servidores nacionais sendo eles, ‘a.ntp.br’ e ‘b.ntp.br’ ou outro de sua preferência.

Note que ao aplicar a configuração o texto digitado se converte automaticamente no IP de cada servidor e para isso utiliza o serviço DNS configurado neste equipamento.

__________________________________________________________________

Criando o MASCARAMENTO dos IP’s privados

Neste momento dado a natureza dos IP’s que utilizamos na ‘pool_acesso’ vamos criar o mascaramento local para que seja possível o trafego de dados entre os clientes e a internet.

Acesse IP/Firewall/NAT e insira uma nova regra com as seguintes características:

Na aba “General”
Chain: srcnat
Src. Address: 10.0.0.0/24 (classe destinada aos clientes)
Out . Interface: EthLinkD

Na aba “Action”
Action: masquerade

Você pode ter feito esse procedimento dezenas de vezes e de várias maneiras diferentes sem se perguntar por que, neste caso quando fazemos o mascaramento estamos dizendo para o MikroTik que todas as requisições vindas dos clientes (pool_acesso, IP’s 10.0.0.0/24) com saída pela interface “EthLinkD” serão mascaradas pelo NAT, em linhas gerais isso garante que o firewall seja afetado positivamente para os acessos da sua rede interna, o que isso significa? Que quando você for fazer utilização de um servidor externo de quaisquer serviços conectados a outra interface que não seja “EthLinkD” (pode ser EthIntranet ou outra qualquer), estes serviços irão registrar o IP individual de quem estiver buscando pelo serviço e não o IP do servidor o qual seria enviado caso não estivéssemos definindo uma interface especifica para a saída padrão (leia-se rota default).

Um exemplo prático são os redirecionamentos para servidores de proxy cache, sem informar a “Out. Interface” o servidor de cache vai entender que todas as requisições são oriundas do IP do servidor MikroTik que fizer a conexão com o proxy cache, imagine então se for um servidor de firewall e ou autenticações, onde todos os usuários chegassem com o mesmo IP.

Feito isso já podemos conectar nosso primeiro cliente ainda que não tenhamos configurado o servidor de cache, e para tanto se faz necessário configurar um discador pppoe, seja em um rádio ou no próprio sistema operacional do usuário.

De posse do usuário e senha cadatrados na “Secrets” conecte um cabo de rede entre a interface “EthClientes” e o equipamento que fará a discagem, na maioria dos casos os rádios suportam auto-MDIX, para micros ligados diretamente ao servidor e placas de rede que não o suportem utilize um cabo de rede crossover.

http://en.wikipedia.org/wiki/Ethernet_crossover_cable

Após conexão observamos em “Active Connections” a presença da conexão discada e o respectivo endereço MAC na coluna “Caller ID”.

Na aba “Interface é” possível ver a interface criada pelo pppoe com trafego de tx/rx (download/upload pois o sentido é servidor>cliente)

Em “Queue List” na aba “Simple Queue” é possível observar o tráfego do cliente no controle de filas sendo que os valores instantâneos são para o tráfego que passa pelo servidor com destino a internet.

A cor vermelha indica que o trafego excede 75% do valor configurado em “Max Limit”, outras cores são laranja para 50% e verde para 25%.

__________________________________________________________________

Integração ao sistema de cache NIMOC Power

Comecemos por configurar a interface que fará a comunicação com o cache, neste caso especifico recomendo a instalação de uma interface com o único propósito de se comunicar com o servidor de cache.

Vamos agora re-nomear a interface ether3 para “EthCache”, que como o próprio nome diz será a interface exclusiva que será conectada ao NIMOC Power.

Vamos agora configurar a conexão entre o MikroTik e o servidor de cache, no MikroTik acesse o menu ‘IP / Address’ e configure o seguinte IP 192.168.10.253/30 na interface “EthCache”, este será o gateway e dns secundário do servidor de cache.

Feito isso configure o seu servidor de cache N!MOC com as seguintes informações.
IP Address: 192.168.10.254
Mascara: 255.255.255.252
Gateway: 192.168.10.253
Dns primário: 127.0.0.1
Dns secundário: 192.168.10.253

Para tanto vamos utilizar o aplicativo ‘niconfig’ que se encontra presente no sistema instalado a partir do N!MOC INSTALLER CD:

Tento logado como root digite no console do N!MOC Linux:
niconfig <ENTER>

Caso sua placa de rede seja identificada diferente de ‘eth0’, não há problema apenas lembre em qual interface você configurou o IP para futuras configurações ou consultas se necessárias.

Na seqüencia vamos configurar IP 192.168.10.254 e mascara de rede 255.255.255.252, esta classe possui apenas os 2 IP’s livres para uso que necessitamos na comunicação entre os dois servidores.






Ao final clique aceitar sobre a seleção SAIR.

Antes que comece a se questionar sobre o que acabamos de fazer e o uso do sistema de cache com suporte a TPROXY quero adiantar que dessa forma será possível e sem nenhuma limitação o uso do TPROXY tanto para IP’s públicos quanto de IP’s privados, os IP’s configurados acima não influenciam no uso desse recurso e só servem para o transito das demais classes de IP.

Obs: N!MOC Power LYE tem suporte a TPROXY em LINUX/BSD além de muitos outros recursos importantes para a configuração de uma rede profissional.

Note que os IP’s de gateway e dns indicam que o MikroTik será o gateway e dns secundário do servidor de cache e portanto todo trafego que o servidor de cache solicitar irá passar pelo MikroTik, para isso devemos configurar o mascaramento desta classe em ‘IP / Firewall / NAT’, adicione uma nova regra da mesma forma que o fizemos quando criamos o mascaramento para os clientes.

Na aba “General” no campo “Chain” selecione ‘srcnat’ em seguida no campo “Src. Address:” digite 192.168.10.252/30 que será destinada a comunicação entre o cache e o MikroTik, em seguida no campo “Out Interface” selecione a interface utilizada na comunicação com a internet “EthLinkD”, e por último na aba “Action” e campo de mesmo nome selecione ‘masquerade’.

E com isso concluímos o mascaramento da rede que dará suporte ao servidor de cache.

Nossa tabela NAT deve agora estar como abaixo:

Agora vamos criar as marcações para o desvio do trafego via tabela mangle para redirecionar as requisições da porta 80 até o cache N!MOC seguindo o exemplo a seguir .

Acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General” selecione a “Chain” prerouting, “Protocol” tcp e “Dst. Port” 80 ainda em “In. Interface” selecione a ‘EthCache’ e marque a flag “!” que significa negação, ou seja todas as interfaces menos esta, na aba “Extras” em “Src. Address List” informe o nome da lista que irá conter a lista que irá conter os IPs dos clientes e servidores internos que não deverão passar pelo cache. Em seguida informe em “Dst. Address List” a lista de IPs que irá conter os endereços de sites da internet os quais não deseja que passem pelo cache, e não esqueça de marcar a flag de negação “!” para ambas as listas.

Vamos agora para a aba “Action” e na opção de mesmo nome selecionamos “mark routing” e em “New Routing Mark” nossa marcação de rota personalizada chamaremos de “to_nimoc”, com relação a flag “Passthrough” podemos deixar marcada se desejamos que o trafego continue a ser analisado pelas regras seguintes da tabela ou desmarcarmos se não quisermos, é relativo e depende muito do que se vai fazer nas regras seguintes, no exemplo deixaremos marcada pois nosso exemplo será limitado e não teremos regras conflitantes que poderiam sobre gravar nossa marcação.

Esta regra como foi concebida fará a marcação de rota sobre os IP’s 10.0.0.0/24 utilizados pelo plano/profile ”PC.Conecta” do “PPPoE Server” com a identificação de ‘to_nimoc’.

IMPORTANTE: Quando os IP’s a receber a marcação forem privados e mascarados, não há necessidade de tratar o retorno e a regra acima fará toda a marcação necessária bastando adicionar uma rota na tabela de rotas, porém quando se tratar de uma classe de IPs públicos ou mesmo uma classe cujo mascaramento estiver atrás do equipamento onde estamos fazendo esta marcação fazendo com que utilizemos o TPROXY, existe a necessidade de tratarmos o retorno conforme a regra que segue.

Acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General” selecione a “Chain” prerouting, “Protocol” tcp e “Src. Port” 80 ainda em “In. Interface” selecione ‘EthLinkD’, na aba “Extras” em “Src. Address List” informe o nome da lista que irá conter os IP’s dos clientes e servidores internos que não deverão passar pelo cache.

Em seguida informe em “Dst. Address List” a lista de IPs que irá conter os endereços de sites da internet os quais não deseja que passem pelo cache, note que aqui invertemos a posição das listas e isso é proposital já que estamos tratando o trafego de retorno, e por último na aba “Action” no recurso de mesmo nome selecione “mark routing” e em “New Routing Mark” informamos o nome da rota que será “to_nimoc” mantendo a flag “Passthrough” marcada.

A tabela acima contém apenas a marcação de rotas necessária para uso com TPROXY ativado, em caso de TPROXY desativado e classes de IP’s privados como no exemplo 10.0.0.0/24 só é necessária a primeira regra onde utilizamos Src. Address e a segunda deve ser eliminada. Vale ainda lembrar que devemos ter uma regra ou conjunto de regras para cada classe de IP’s que desejamos marcar as rotas para envio ao cache.

__________________________________________________________________

N!MOC Power – Regras úteis

Adiciona IP a interface do MikroTik que fará comunicação com N!MOC Power.

Código :

/ip address
add address=192.168.10.253/24 comment=PC.NiMOC disabled=no interface=EthCache

Ativa resolução DNS para equipamentos remotes.

Código :

/ip dns
set allow-remote-requests=yes

Bloqueio de acesso externo ao cache N!MOC Power.

Código :

/ip firewall filter
add action=drop chain=input comment=PC.NIMOC disabled=no dst-port=8080 in-interface=EthLinkD protocol=tcp

Bloqueio de acesso externo ao DNS N!MOC Power.

Código :

/ip firewall filter
add action=drop chain=input comment=PC.NIMOC disabled=no dst-port=53 in-interface=EthLinkD protocol=udp

Suporte ao SSH N!MOC Power.

Código :

/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.NiMOC disabled=no dst-port=220 protocol=tcp to-addresses=192.168.10.254 to-ports=22

Suporte ao relatório HTTP N!MOC Power.

Código :

/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.NiMOC disabled=no dst-port=8282 protocol=tcp to-addresses=192.168.10.254 to-ports=82

Marcação de rota para IP privado no N!MOC Power.

Código :

/ip firewall mangle
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-address-list=!sem_cache_dst dst-port=80 in-interface=!EthCache new-routing-mark=to_nimoc passthrough=yes protocol=tcp src-address=10.0.0.0/24 src-address-list=!sem_cache_src

Marcação de rota para IP público no N!MOC Power.

Código :

/ip firewall mangle
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-address-list=!sem_cache_dst dst-port=80 in-interface=!EthCache new-routing-mark=to_nimoc passthrough=yes protocol=tcp src-address=200.201.202.0/24 src-address-list=!sem_cache_src
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-address=200.201.202.0/24 dst-address-list=!sem_cache_src in-interface=EthLinkD new-routing-mark=to_nimoc passthrough=yes protocol=tcp src-address-list=!sem_cache_dst src-port=80

Redirecionamento de rota para N!MOC Power.

Código :

/ip route
add comment=PC.NIMOC disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.10.254 routing-mark=to_nimoc scope=30 target-scope=10

Lista de IP dos sites que não deverão passar pelo cache N!MOC Power.

Código :

/ip firewall address-list
add address=1.2.3.4 comment="PC.NIMOC - IP DE SITE SEM CACHE" disabled=no list=sem_cache_dst

Lista de IP dos clientes que não deverão passar pelo cache N!MOC Power.

Código :

/ip firewall address-list
add address=1.2.3.4 comment="PC.NIMOC - IP DE CLIENTE SEM CACHE" disabled=no list=sem_cache_src

Monitoramento do N!MOC Power e desativação automática de marcações.

Código :

/tool netwatch
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find comment=PC.NIMOC ] disabled=yes\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes" host=192.168.10.254 interval=5s timeout=2s up-script=\
    "/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no"

Monitoramento da internet e desativação automática de marcações.

Código :

/tool netwatch
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find comment=PC.NIMOC ] disabled=yes\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes" host=8.8.8.8 interval=30s timeout=5s up-script=\
    "/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no"
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find comment=PC.NIMOC ] disabled=yes\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes" host=200.221.2.45 interval=30s timeout=5s up-script=\
    "/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
    \n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no

__________________________________________________________________

Cache Full

Chegamos a um ponto importante, tanto se ouve falar em Cache Full que a definição propriamente dita se torna confusa, seria um cache cheio ?

Cache Full na definição dos usuários que o utilizam significa enviar o conteúdo web normalmente do tipo multimídia e armazenado em proxy cache local para os usuários/clientes da rede furando o controle de banda convencional da “Queue Simple” utilizando para isso a marcação de pacotes e a “Queue Three” que comumente é utilizada para controle em sistemas de QoS.

O mais comum encontrado em dezenas de paginas web é baseado na marcação de pacotes contendo o parâmetro o que pode ser feito pela tabela “Mangle” na “Chain” postrouting, em seguida na aba “Advanced” em “Content” digitando ‘X-Cache: HIT’ seguindo para a aba “Action” em campo de mesmo nome selecione ‘mark packet’ e em “New Packet Mark” digite cachefull. Sequer darei um exemplo utilizando a “Queue Three” por considerar que este método possui uma série de problemas graves.

No entanto existem outros métodos possíveis que podem ser aplicados, um dos quais relaciono abaixo tópicos que considero mais importantes.

1 – Marcar os pacotes pelo “DSCP/TOS” e não pela “Content”, isso porque este segundo método além de inseguro é ineficaz e exige maior processamento.

2 – Informar por onde o trafego adentra ao MikroTik e/ou para onde segue, isso ajuda a diminuir a carga e evita que a marcação seja utilizada para enviar algum outro conteúdo forjado com a mesma marcação.

3 – Criar uma “Queue Type” que vai fazer o controle individua de uso do conteúdo previamente marcado.

4 – Criar uma “Simple Queue” que será responsável por limitar o tráfego que será enviado para determinada classe de IP’s. E inserir nela o controle individual como veremos a seguir.

1.1 - Comecemos marcando os pacotes, para isso acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General” selecione a “Chain” prerouting, “Protocol” tcp, “In. Interface” EthCache, na aba “Advanced” em “DSCP(TOS)” informe o valor 18 que corresponde a marcação 72 no exemplo.

Ainda na mesma regra na aba “Action”, campo de mesmo nome selecione a opção ‘mark connection’ e logo abaixo no campo “New Connection Mark” digite ‘conn_nimoc’. Clique em OK e esta pronta esta primeira regra, o que ela faz é identificar as conexões oriundas do servidor de cache e que contém a marca desejável recebida via “DSCP/TOS”, ainda falta marcar os pacotes dessas conexões o que faremos na segunda regra.

Dica: para saber como funciona a relação entre valores basta saber que 0 = 0, 1 = 4, 2 = 8, 3 = 12 e finalmente 18 = 72, portanto multiplique a marcação informada no MikroTik por 4 e vai obter o valor a ser configurado no parâmetro DSCP/TOS quando suportado pelo cache. N!MOC Power tem suporte a DSCP/TOS.

1.2 – Adicione uma nova regra e na abra “General” a “Chain” prerouting, e logo abaixo no campo “Connection Mark” selecione a marcação chamada ‘conn_nimoc’, vá até a aba “Action” no campo de mesmo nome selecione ‘mark packet’ e logo abaixo em “New Packet Mark” vamos colocar a identificação dos pacotes como ‘pack_nimoc’, tendo o cuidado de desmarcar “Passthrough” pois não queremos que o mesmo pacote esteja sujeito a receber outra marca depois dessa o que faria com que a marca anterior fosse sobrescrita inutilizando nossa primeira marcação.

Tabela mangle contendo apenas regras para marcação do conteúdo em cache.

Em “Queue Type” adicione uma nova a qual daremos o nome de ‘nimoc_conecta’ levando o nome do servidor de cache mais o plano de acesso onde será utilizada. No campo “kind” selecione o tipo ‘pcq’ se não sabe como funciona cada controle de filas recomendo que busque no manual, o pcq é um dos mais práticos e faz muito bem o trabalho neste caso.


No campo “Rate” podemos definir duas formas distintas de se trabalhar no caso do pcq, deixando o campo com valor 0 significa sem limite ou seja, o que for definido no queue pai será o limite e os casos que se enquadrarem neste queue type dividirão o valor do limite entre si, pode ser desejável em muitos casos. No nosso exemplo vamos definir o valor de 256k pois queremos forçar este limite individual, logo abaixo nos campos “Limit” e “Total Limit” vamos manter os valores padrões que são adequados para o que já configuramos anteriormente neste exemplo, é interessante que busquem estas informações nos manuais pois elas podem fazer a diferença entre um serviço congestionado e uma internet navegando solta.

Na seqüência temos quatro possíveis opções de classificadores ou “Classifier”, vamos marcar apenas uma delas que é a “Dst. Address” ou seja do ponto de vista do servidor “por” endereço de destino.

3.2 – O próximo passo é criar o controle que irá utilizar a “Queue Type” recém criada, acesse “Queue List” e na aba “Simple Queue” criemos uma nova a qual iremos chamar de NIMOC-Conecta, em “Target Address” identifique os IP’s que serão de certa forma favorecidos por ela, no nosso caso os do plano “PC.Conecta” representados pela classe 10.0.0.0/24, nos campos “Max Limit” devemos nos preocupar apenas com o “Target Download”, explicarei logo mais, para este campo vamos utilizar o valor de 2M ou seja 2 Megas.

Seguimos para a próxima aba “Advanced” e nela selecionamos a “Queue Type” de nome ‘nimoc_conecta’ criada no passo anterior.

Chegamos no pulo do gato, temos agora um controle que restringe em 2 Megas para toda a classe de IP’s 10.0.0.0/24 que atende os clientes do plano de 128k sendo que o controle individual quem faz é a “Queue Type” a qual chamamos de ‘nimoc_conecta’, neste estágio você deve estar se perguntando como identificar os pacotes oriundos do cache para que tal controle seja somente para o conteúdo vindo do cache com a marcação que fizemos, para tanto na aba “Advanced” selecione em “Packet Marks” a marcação criada sobre os pacotes vindos do cache que chamamos de ‘pack_nimoc’.

O último passo é fazer com que este controle seja sempre o primeiro na lista “Queue Simple” e para isso basta arrastar para a primeira posição da lista, caso utilize HOTSPOT irá precisar de um script para que cada vez que alguém logue no sistema ele redefina a ordem da lista jogando este controle pra primeira posição, como não é o caso do nosso exemplo vou tomar a liberdade e pular esta etapa.

Com a solução proposta espero liquidar de vez o chamado CacheFull que só traz dores de cabeça e deteriora completamente as conexões wireless, não que o que propomos aqui se implementado erroneamente também não o faça mas o risco é menor se você compreender o que esta fazendo do que configurar as cegas.

O resultado dessa implementação é que o cliente ainda terá os 128k de download quando o trêfego for oriundo da internet porém ele terá mais 256k quando o conteúdo já estiver em cache totalizando uma banda de navegação de 384k fazendo o cliente muito mais satisfeito e o provedor muito mais econômico e competitivo com a banda disponível, como resultado temos uma melhora significativa em serviços com consumo de streaming, o cliente ainda consegue navegar pelos sites mais visitados e falar ao skype ou utilizar tecnologias similares gastando o mínimo de banda do seu link.

__________________________________________________________________

Repasse de IP Público com exemplo para PPPoE

Exemplo 1:
O Provedor recebe o link dedicado e uma classe /29, utiliza o primeiro IP dessa classe como gateway e o segundo como IP do seu servidor MikroTik .

1.1 - Neste caso, configure a interface do Link como proxy-arp e a interface dos clientes como reply-only depois adicione a seguinte regra no MikroTik em NEW TERMINAL e cole:

Código :

/ ip firewall nat
add chain=dstnat action=passthrough src-address=XX.XX.XX.XX/XX  comment="REPASSE DE IP" disabled=no

Onde XX.XX.XX.XX/XX é o IP/MASCARA que tiver disponível do seu link
Após ter feito isso adicione cada IP no campo 'Remote Address' em 'PPP secret' para cada cliente que tiver 'IP Público e fixo'. Ou crie uma pool em ‘IP / Pool' contendo os IPs disponíveis e defina esta 'pool' no 'profile' default de seu servidor PPPoE ou ainda apenas no profile/plano que estiverem os clientes que vão receber IP Público e estes terão um IP dinâmico que poderá mudar a cada nova conexão.

Dica: PROXY-ARP não é o método mais seguro, mas permite alguma flexibilidade quando não dispuser de muitos IP’s e não tiver acesso à configuração do roteador de borda.

Dica: Não crie um mascaramento dito 'genérico', mascare apenas as classes de IP privadas que estiverem em uso. Ex: 10.0.0.0/24

Dica: Sempre informe a 'out-interface' no mascaramento como sendo a interface do link (EthLinkD).

Dica: Cuidado com programas de gerenciamento para provedores que criam regras em seu sistema, essa é pode ser a causa de muitos problemas.


Exemplo 2:
O provedor recebe o link dedicado em uma classe e possui outras classes adicionais para utilizar com clientes, ou ainda pode quebrar em subclasses para criar seu roteamento interno.
Este é o típico caso onde podemos aplicar o roteamento de forma bastante simples.
Basicamente o que deve fazer é seguir com o roteamento da operadora 'pra dentro' da sua estrutura, vamos lá:

2.1 - Coloque um IP público na interface do link.
2.2 - Defina as classes públicas nos pools de IP’s que irá utilizar para seus usuários e a cadeia de conexão que deverão seguir. Ex: PoolA cai no PoolB quando estiver cheio e assim por diante, recomendo que faça isso pois terá um melhor controle e poderá utilizar para cada pool de IP’s um plano diferente e isso pode ter várias implicações positivas em uma futura QoS.
2.3 - No profile padrão do ‘PPPoE Server’ indique que o 'Local Address' que será o gateway default dos clientes é o IP público da interface do link, assim o roteamento estará completo.
Trocando em miúdos, você estará indicando que a rota de saída dos IP’s segue seu roteamento padrão.

Dica: Nunca mascare classes de IP’s públicos a não ser que tenha uma boa justificativa, como por exemplo por possuir poucos IP’s pode criar um mascaramento para cada plano e indicar uma saída para cada plano ou grupo de clientes ou seja, clientes do planoA/grupoA saem mascarados pelo ip público A, do B pelo B e assim por diante.

Exemplo 3:
Repassando mais de um IP pela conexão PPPoE utilizando roteamento estático.

3.1 - Defina um IP fixo para o cadastro do secret/usuário em questão no campo 'Remote Address', pode até ser um IP privado.
3.2 - Acesse o menu ‘IP / Route’ e adicione uma rota contendo no destino ‘Dst-Address’ os IP’s que deseja repassar e no gateway o IP do usuário que definiu no cadastro do usuário/secret no passo anterior.

Obs.: Se tiver muitos clientes com esta mesma necessidade este método é inviável e se faz necessário implantar o OSPF para o gerenciamento das rotas. Na maioria dos casos a implantação é simples e rápida e vai depender de como a rede estiver configurada.


Exemplo 4:
Repasse de IP público utilizando roteamento interno por OSFP.

No caso de muitas rotas e/ou onde já tiver a autenticação na borda deverá optar por um método de roteamento dinâmico e uma das vantagens é que com isso economizará recursos da central, diminuindo o tráfego de broadcast e possivelmente aumentando a segurança da sua rede de distribuição.

Se for migrar uma bridge de distribuição por exemplo, o primeiro passo é passar a autenticação para as bordas, e na seqüência rotear os dispositivos conectados a borda, seguindo em direção a saída do link, com isso será possível fazer a migração a quente e continuar usufruindo da estrutura em bridge até a virada total.

OSPF básico é também rápido de fazer configurar, você tem de definir a network área que fará o transporte redistribuindo a rota default e redistribuir as conectadas tipo 1 no seu servidor ou apenas as conectadas quando tiver fixa a rota default.

FIG

Nas bordas precisa configurar a mesma network para o transporte e na instância redistribuir a rota default e conectadas tipo 2 ou apenas as conectadas na maioria dos casos.

FIG

Dessa forma teremos o funcionamento esperado e será possível visualizar as instâncias UP em ambos os lados.
No exemplo temos 22 pontos participando do OSPF na área backbone.

FIG

Também podem existir outras áreas entre a borda e o seu concentrador aumentando a complexidade e até terminar num anel podendo utilizar essa topologia como backup de rotas com stp ou rstp e a possibilidade de custos diferenciados para cada saída permitindo balancear melhor o tráfego.

__________________________________________________________________

PCC Load Balance

No exemplo utilizaremos Mikrotik 3.30 e 3 links de mesma velocidade.

EthLinkA = Interface do 1º link
EthLinkB = Interface do 2º link
EthLinkC = Interface do 3º link
EthLB = Interface de saída do balance

Quando em modo roteado:
10.1.10.129 = IP do modem A
10.1.10.161 = IP do modem B
10.1.10.193 = IP do modem C

Endereços das interfaces no MikroTtik ROS – PCC Balance
10.1.10.130/27 = IP da interface EthLinkA
10.1.10.162/27 = IP da interface EthLinkB
10.1.10.194/27 = IP da interface EthLinkC
172.22.22.1/30 = IP de saída do balance

Endereço da interface do Servidor - Autenticador
172.22.22.2/30 = IP do servidor conectado a saída do balance


Regras e explanações sobre PCC

Tabela MANGLE – Lista de destinos sem balanceamento

Código :

/ip firewall mangle
add action=accept chain=prerouting comment="PC.SB" disabled=no dst-address-list=sem_balance in-interface=EthLB

Esta regra aceita as conexões para todos os IP’s de destino que se encontrarem na lista 'sem_balance' que irão sair pela rota padrão, veja o texto mais adiante.


Tabela MANGLE – Marcação de conexões

Código :

/ip firewall mangle
add action=mark-connection chain=input comment="PC.IN" connection-state=new disabled=no in-interface=EthLinkA new-connection-mark=conn_na passthrough=yes
add action=mark-connection chain=input comment="" connection-state=new disabled=no in-interface=EthLinkB new-connection-mark=conn_nb passthrough=yes
add action=mark-connection chain=input comment="" connection-state=new disabled=no in-interface=EthLinkC new-connection-mark=conn_nc passthrough=yes

Cria as marcas (conn_na, conn_nb, conn_nc) para novas conexões em cada uma das interfaces (EthLinkA, EthLinkB, EthLinkC)


Tabela MANGLE – Marcação de rotas

Código :

/ip firewall mangle
add action=mark-routing chain=output comment="PC.OUT" connection-mark=conn_na disabled=no new-routing-mark=to_ra passthrough=no
add action=mark-routing chain=output comment="" connection-mark=conn_nb disabled=no new-routing-mark=to_rb passthrough=no
add action=mark-routing chain=output comment="" connection-mark=conn_nc disabled=no new-routing-mark=to_rc passthrough=no

Utiliza as marcações (conn_na, conn_nb, conn_nc) para criar as marcações das respectivas rotas (to_ra, to_rb, to_rc)


Tabela MANGLE – Peer Connection Classifier (Identificação das conexões)
Aqui começa o PCC propriamente dito.

Código :

/ip firewall mangle
add action=mark-connection chain=prerouting comment="PC.CON" disabled=no dst-address-type=!local in-interface=EthLB new-connection-mark=conn_na passthrough=yes per-connection-classifier=both-addresses:3/0
add action=mark-connection chain=prerouting comment="" disabled=no dst-address-type=!local in-interface=EthLB new-connection-mark=conn_nb passthrough=yes per-connection-classifier=both-addresses:3/1
add action=mark-connection chain=prerouting comment="" disabled=no dst-address-type=!local in-interface=EthLB new-connection-mark=conn_nc passthrough=yes per-connection-classifier=both-addresses:3/2

Agora utilizando os classificadores (0, 1 e 2) na interface de saída do balance ‘EthLB’ criamos novas marcas de conexão (conn_na, conn_nb, conn_nc).

Note que se tivéssemos 4 links seria aqui que faríamos as alterações para (0, 1, 2 e 3) ficando 4/0, 4/1, 4/2, 4/3 ou ainda se tivéssemos links assimétricos ( Ex: LinkX de 512k - LinkY de 1024k - LinkZ de 2048k), deveríamos somar os valores de todos os links e dividir pelo valor do menor link então teríamos:

Exemplo: (512k + 1024k + 2048k )/ 512k = 7

Assim teríamos 7 marcações de PCC indo de 7/0 até 7/6 das quais deveríamos direcionar a primeira pro link X, a segunda e terceira pro link Y e as quatro restantes para o link Z fazendo nosso sistema perfeitamente equilibrado, vale ressaltar que sistemas do tipo ADSL não garantem a banda.

Portanto devemos fazer testes em cada um dos links para aferir as velocidades possíveis em cada um, já vi muitos casos onde um link desse tipo de 2MB era melhor do que o de 4MB da mesma operadora instalada no mesmo local, essa relação depende diretamente da ocupação/uso instantâneo do concentrador da operadora ao que cada link estiver conectado, normalmente adsl.

Utilizando das novas marcações de conexão (conn_na, conn_nb e conn_nc) do passo anterior (PCC), criamos uma nova marcação de rota para os pacotes entrando pela interface EthLB que chamaremos novamente de ‘to_ra’, ‘to_rb’ e ‘to_rc’.


Tabela MANGLE – Peer Connection Classifier (marcação das rotas)

Código :

/ip firewall mangle
add action=mark-routing chain=prerouting comment="PC.MR" connection-mark=conn_na disabled=no in-interface=EthLB new-routing-mark=to_ra passthrough=no
add action=mark-routing chain=prerouting comment="" connection-mark=conn_nb disabled=no in-interface=EthLB new-routing-mark=to_rb passthrough=no
add action=mark-routing chain=prerouting comment="" connection-mark=conn_nc disabled=no in-interface=EthLB new-routing-mark=to_rc passthrough=no

Assim tendo as conexões devidamente identificadas (conn_nX) e rotas definidas para cada conexão (to_rX), seguimos para o mascaramento.


Tabela NAT - Mascaramento

Código :

/ip firewall nat
add action=masquerade chain=srcnat comment="PC.MSQ " disabled=no out-interface=EthLinkA
add action=masquerade chain=srcnat comment="" disabled=no out-interface=EthLinkB
add action=masquerade chain=srcnat comment="" disabled=no out-interface=EthLinkC

Vale ressaltar que o mascaramento pode ser feito de várias formas, indicando por exemplo o IP da interface de saída utilizando a action ‘src-nat’ (no caso de termos mais de um IP de saída na mesma interface). Pela interface de cada link como acima, ou ainda apenas mascarando a interface de saída do balance ‘EthLB’ em negação como abaixo, escolha a sua de acordo com o seu entendimento e necessidade.

Código :

/ip firewall nat
add action=masquerade chain=srcnat comment="PC.MSQ " disabled=no out-interface=!EthLB

Tabela NAT – DMZ / Demilitarized Zone

Código :

/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.DMZ disabled=no dst-port=!8291 in-interface=!EthLB protocol=tcp to-addresses=172.22.22.2

O exemplo acima redireciona todas (menos as da porta 8291 que é do acesso ao winbox) as entradas pelas interfaces ‘diferentes’ da ‘EthLB’, portanto estamos nos referindo as entradas dos links, para o IP 172.22.22.2 que no caso será o servidor ligado a saída do balance.

O DMZ evita ter que criar uma regra para cada porta e cria uma zona de acesso direto havendo correspondência entre as portas, pode-se excluir uma ou mais portas do DMZ caso tenham um destino diferente.
No caso da porta de origem ser diferente da porta destino, devemos criar uma regra indicando tal situação e posicioná-la antes da regra do DMZ.

Código :

/ip firewall nat
add action=dst-nat chain=dstnat comment=”PC.WBX” disabled=no dst-port=8292 in-interface=!EthLB protocol=tcp to-addresses=172.22.22.2 to-ports=8291

A regra acima serve para o acesso do servidor pelo winbox a partir da internet por qualquer dos links conectados ao balance e deve estar na tabela NAT antes da regra de DMZ.

Seguimos para a próxima etapa onde iremos definir as rotas padrão e backup para cada marcação criada até agora.

Tabela ROUTE – Indicação de rotas e redundância

Definimos 3 rotas sendo que cada uma tem um custo diferente e portanto a primeira terá a preferência (distance=1), caso venha a faltar a segunda assume(distance=2), em seguida a terceira(distance=3).

Código :

/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.1.10.129 
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=10.1.10.161 
add comment="" disabled=no distance=3 dst-address=0.0.0.0/0 gateway=10.1.10.193

Sendo a rota de custo menor (ex: distance=1) a rota padrão (default) para todas as conexões que não receberem marca de rotas, nesta lista incluem-se os serviços e destinos da lista ‘sem_balance’ comentada no inicio, portanto é interessante que este link tenha boa capacidade pois além das conexões oriundas das marcações irá receber o trafego sem marcação.

Em seguida todas as 3 rotas que utilizam marca de rotas ‘to_ra’, ‘to_rb’ e ‘to_rc’ dividem a carga que foi previamente marcada na tabela mangle.

Enviando ‘to_ra’ para o gateway 10.1.10.129, ‘to_rb’ para o gateway 10.1.10.161 e ‘to_rc’ para o gateway 10.1.10.193 todas com ‘distance=1’ ou seja, como primeira opção de todas as marcações.

Código :

/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.1.10.129 routing-mark=to_ra
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.1.10.161 routing-mark=to_rc
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.1.10.193 routing-mark=to_rb

Podemos ainda definir links de backup para cada marcação e no caso se um dos links cair, o link de backup assume a tarefa de transmitir os pacotes como fizemos para a rota padrão, agora também para as marcações de rota.

Código :

/ip route
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=10.1.10.161 routing-mark=to_ra
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=10.1.10.193 routing-mark=to_rc
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=10.1.10.129 routing-mark=to_rb

Note que a o gateway de backup para ‘to_ra’ é 10.1.10.161, para ‘to_rb’ é 10.1.10.193 e para a ‘to_rc’ é 10.1.10.129.

Pode-se opcionalmente criar várias rotas de backup com custos (distance) diferentes até cobrir todas as possibilidades.

Dica: Também é possível fazer com que o próprio Mikrotik ROS disque as conexões do tipo ADSL/PPPOE aumentando a eficiência do sistema e utilizando modens em bridge, sendo que neste caso é recomendado fazer o mascaramento e indicação do gateway ambos pela interface pppoe-out e não mais pelo IP.

Dica: com relação ao usar o check ping, devemos tomar cuidado pois links de diferentes tipos tendem a ter diferentes tempos de resposta ao ping e quando este método é utilizado pode ocorrer desigualdade entre os consumos dos links apesar de as marcações estarem corretas, isso porque o sistema leva em consideração o tempo de resposta de cada gateway.

Dica: para que o balance PCC funcione de maneira mais adequada, o menor link deve ser superior ao maior plano comercializado e a maior eficiência do balance depende de requisições menores chegando ao balance em grande quantidade e não a poucas requisições em maior quantidade, lembre-se disso, balance não é soma de link mas sim a divisão das requisições.

__________________________________________________________________

DMZ no MikroTik

Se o que você quer no caso é apenas um redirecionamento público/privado e seu retorno, tens duas formas bastante simples de fazer, por dst-nat e src-nat ou utilizando netmap, observe os exemplos que seguem.

Adicione o ip público e mascara a interface pública do mikrotik (entrada do link).

Na tabela NAT adicione uma regra cuja chain dst-nat redirecione o que chegar para o ip público utilizando também a action dst-nat para o ip privado, identificando a interface de entrada como sendo o seu link.

Código :

/ip firewall nat 
add action=dst-nat chain=dstnat comment="PC.DSTR" disabled=no dst-address=200.201.202.1 in-interface=EthLinkD to-addresses=10.90.1.1

Na sequencia faça o oposto, mascarando as requisições que chegarem do ip privado para sairem pelo ip público identificando a interface de saída como sendo o link.

Código :

/ip firewall nat
action=src-nat chain=srcnat comment="PC.MSQR" disabled=no out-interface=EthLinkD src-address=10.90.1.1 to-addresses=200.201.202.1

E não esqueça de colocar estas regras antes do seu mascaramento geral para que tenha o resultado esperado, este é um exemplo de NAT 1:1, você também pode utilizar o netmap para a função e fazer o repasse para uma range de IPs sem necessidade de criar uma regra para cada IP.

__________________________________________________________________

Utilização de Burst no MikroTik

Acredito que a dúvida seja compartilhada com muitos, vou tentar explicar apartir de exemplo simples o funcionamento do burst.

ML - Max Limit 120k = Máxima taxa de transferência após atingido o limite que será calculado com base no tempo de 8s podendo atingir a velocidade máxima de 'Burst Limit = 300k'
BL - Burst Limit 300k = Limite máximo de velocidade usando o recurso de Burst ou em português 'Rajada' ou ainda ‘Estouro’.
BT - Burst Threshold 96k = Valor que poderá ser consumido para ter direito a novo BL de 300k
TB - Burst Time 8s = Tempo sobre o qual são calculados os limites de velocidade


Na prática: o burst é calculado utilizando ciclos com base no TB/16 (dividido por 16), no exemplo acima teremos o ciclo de calculo executado a cada 0.5s ou seja, duas vezes por segundo, o que significa dizer que a cada meio segundo serão analisados os últimos 8s (TB) do tráfego.

De uma forma geral para ter direito ao burst o resultado calculado de BT deve ser inferior ao valor informado para BT, seguindo fórmula: “(BTT/TB) < BT”, onde BTT é a média do consumo nos últimos ‘X’ segundos definidos em TB.

Exemplo:
1s 2s 3s 4s 5s 6s 7s 8s
300k + 100k + 200k + 50k + 30k + 200k + 250k + 150k = 1280k
1280k/8s = 160k/s

Sendo a fórmula para a liberação de novo burst “BTT / TB < BT” e o valor definido de BT atual definido de 96k, o calculo deste ciclo nos mostra o BT em 160k/s, ou seja, maior que 96k, o burst não será liberado e o valor limite continua sendo de ML.

Ainda que o consumo nos próximos 6 segundos se mantenham em 120k:
250k + 150k + 120k + 120k + 120k + 120k +120k + 120k = 1120k
1120k/8s = 140k/s

O resultado continua acima do valor definido para BT que é de 96k, não tendo direito a novo burst até que o resultado do ciclo seja inferior a BT.

Suponhamos que nos próximos 2 segundos o consumo caia:
120k + 120k 120k + 120k + 120k + 120k + 12k + 12k = 744k
744k/8s = 93k

Neste instante o valor calculado é inferior ao definido em BT, sendo assim já estará liberado novamente o valor de BL para a próxima solicitação.


Se você chegou até aqui parabéns, já consegui o que buscava ao escrever este material.

__________________________________________________________________

NIMOC Power Cache

Se quiser continuar farei uma explanação sobre o N!MOC Power, um sistema de cache que desenvolvemos focado em alto desempenho entenda-se isso por rapidez e alto ganho.


O N!MOC Power incorpora os mais importantes recursos suportados por servidores cache, trabalha com conteúdo dinâmico e estático dos mais diversos sites suportando grande volume de carga e armazenamento. Orkut, YouTube, Microsoft, dezenas de antivírus e sites de conteúdo multimídia de todos os tipos são suportados, hoje são mais de 480 plugins já disponíveis e mesmo sem a existência destes todo o trafego que passar pelo NIMOC terá seu conteúdo analisado e alocado em disco quando configurado.

Suporte nativo a T-PROXY, REDIRECT, DSCP/TOS em diversos níveis, personalização de plugins e listas são alguns dos recursos básicos presentes.

Recursos inovadores e exclusivos garantem a desempenho superior, a versão LYE agrega adicionais importantíssimos e na maioria inéditos.

O sistema N!MOC distingue-se dos similares por oferecer um ganho superior tanto em economia quanto em desempenho, o tempo de resposta é aproximadamente 6x menor que os demais, podendo ultrapassar incríveis 50x para abertura de páginas e não estou falando sobre aceleração via “Queue Type” como alguns podem estar imaginando.

O conteúdo armazenado localmente é passível de uso por outras aplicações, sendo que nada é adicionado aos arquivos originais, os mesmos são armazenados da mesma forma que são recebidos ou armazenados na internet excluído os utilizadores de responsabilidade por hospedar conteúdo ilegal e mantendo-se dentro das normativas e leis internacionais que protegem alguns tipos de conteúdo.

O N!MOC tem suporte incluso, você não precisa se preocupar com o suporte do servidor, faremos isso pra você sem custo adicional e o valor é acessível a provedores ou empresas de qualquer porte.

Não é necessário acessar nenhum painel, configurar nenhuma opção, basta ligar o servidor e já estará funcionando, quando e se for necessária alguma intervenção ela será feita por pessoal altamente capacitado e homologado na plataforma.

Quando a implantação for feita por nossa equipe, oferecemos a “Garantia Life Time”, ou seja, pelo tempo que você utilizar o sistema. Só quem tem o melhor pode oferecer algo assim, garantia por toda a vida do produto só com máxima qualidade do N!MOC Power LYE.

As atualizações são disponibilizadas sem custo conforme o plano escolhido e não é necessária uma parada do sistema para 90% das atualizações, ou seja, as conexões dos usuários não são interrompidas, os downloads não param no meio e isso significa muito menos aborrecimentos pra você.

Se você tem interesse em ser representante ou desenvolvedor homologado de aplicações, envie-nos o seu currículo, é necessária experiência em sistemas operacionais e desejável conhecimento de duas das plataformas suportadas, nossa intenção não é limitar o número de profissionais homologados, mas nivelar por cima as solicitações para que os clientes ao receberem o suporte, este seja adequado e livre falhas.

Fornecemos o treinamento necessário inclusive para o sistema operacional então se você ainda não possui o conhecimento não deixe de buscá-lo.

E não se esqueça de quando usar ou citar material de terceiro em incluir as fontes, isso não é vergonha muito pelo contrário é sinal de respeito e reconhecimento e também nos qualifica.

Meus sinceros agradecimentos ao under-linux, seus mantenedores e colaboradores que fazem desse o melhor fórum técnico da América Latina.

Ao colega de fórum Anderson Machado por sua dedicação e incontáveis colaborações, também o meu reconhecimento ao MK-AUTH e seu mantenedor Pedro Filho e aos demais amigos que conquistei durante estes anos online, os meus cumprimentos de elevada estima.


Luciano Rampanelli

e-mail: r[email protected] / skype: m4d3m4n
Contato profissional: (46) 9 9918-8088

Encontrou erros? Quer fazer um comentário ou dar sua sugestão?
http://goo.gl/Cw6Kh

Links úteis:
PCQ > http://goo.gl/p9Mfx / ConLiNUXCD > http://goo.gl/IMUtq
PCC > http://goo.gl/0yMZP / 3x1 > http://goo.gl/Kb3L2


Demonstrativo de Resultado NIMOC Power



Exemplo de gráficos após 6 meses da implantação do sistema em uma rede com 560 usuários, alto ganho entre consumo de banda (em verde) e entrega para os usuários (em azul) velocidade de acesso que melhorada exponencialmente a experiência do usuário com conteúdo multimídia sem comparação.

N!MOC conta com modo turbo um diferencial exclusivo que torna a navegação muito mais rápida sem depender de outros sistemas. Surpreenda-se com o que há de melhor em otimização de estrutura para internet com N!MOC Power LYE

DEUS SEJA LOUVADO