Imaginem que solicitado a você criar uma 08 subnets, mas sua responsabilidade é permitir uma expansão futura para mais quatro subnets adicionais e a rede da sua empresa é de classe B 172.23.0.0. Muito bem, nossa responsabilidade aqui é equalizar a necessidade atual e suportar a demanda futura, então começaremos definindo o número de divisões possíveis para chegar no total de subnets exigida.
Como precisaremos pensar em 12 subnets iremos aplicar a regra de 2N (dois elevado a N que é igual a notação decimal que compoe o total de divisões possíveis). Vamos lá…

2*4 = 16

Isto quer dizer que iremos utilizar 4 bits para a nossa operação, isto em uma composição binária seria:

11111111.11111111.11110000.00000000
255.255.240.0 = 172.23.0.0/20

Ótimo, chegamos na mascara de rede! Já sabemos que dentro desta notação poderemos incluir 16 subnets, agora precisaremos descobrir quais os saltos que ocorrerão na composição das subnets, certo? Isto é simples basta olharmos para o bit de baixa ordem, no nosso caso o 16 (Como assim 16!?!?! Lembra da notação decimal? Cada bit do octeto tem um valor da direita para a esquerda elevando 2 de 0 até 7, faça as contas e verás que quando chegar no bit número 5 teremos que elevar a 4. Logo 2 elevado a 4 é igual a 16). Então os saltos irão ocorrer de 16 em 16 ficando assim:

Rede Original: 172.23.0.0
Mascara Original: 255.255.0.0

Subnet 1: 172.23.0.0
10101100.00010111.00000000.00000000

Subnet 2: 172.23.16.0
10101100.00010111.00010000.00000000

Subnet 3: 172.23.32.0
10101100.00010111.00100000.00000000

Subnet 4: 172.23.48.0
10101100.00010111.00110000.00000000

Subnet 5: 172.23.64.0
10101100.00010111.01000000.00000000

Subnet 6: 172.23.80.0
10101100.00010111.01010000.00000000

Subnet 7: 172.23.96.0
10101100.00010111.01100000.00000000

Subnet 8: 172.23.112.0
10101100.00010111.01110000.00000000

Subnet 9: 172.23.128.0
10101100.00010111.10000000.00000000

Subnet 10: 172.23.144.0
10101100.00010111.10010000.00000000

Subnet 11: 172.23.160.0
10101100.00010111.10100000.00000000

Subnet 12: 172.23.176.0
10101100.00010111.10110000.00000000

Subnet 13: 172.23.192.0
10101100.00010111.11000000.00000000

Subnet 14: 172.23.208.0
10101100.00010111.11010000.00000000

Subnet 15: 172.23.224.0
10101100.00010111.11100000.00000000

Subnet 16: 172.23.240.0
10101100.00010111.11110000.00000000

Nova Mascara: 255.255.240.0
11111111.11111111.11110000.00000000

Primeiro Host: 172.23.0.1
Ultimo Host: 172.23.240.254
Broadcast: 172.23.240.255

11111111.11111111.11111000.00000000 -> 255.255.248.0

Contando o número de zeros da esquerda para a direita teremos 11 portanto o valor será 2 elevado a 11 = 2048, daí subtraimos sempre 2 para os reservados e teremos o total de 2.046 que é a minha resposta para o que foi pedido.

Abaixo transcrevo uma tablela já pronta, envolvendo sub-redes e hosts de uma rede classe A.

Número de sub-redes-Número de bits para sub-rede-Máscara de sub-rede -Número de hosts por sub-rede

1-2…………………………………..1……………………………………255.128.0.0 ou /9……….8.388.606
3-4…………………………………. 2……………………………………255.192.0.0 ou /10……..4.194.302
5-8………………………………… 3…………………………………….255.224.0.0 ou /11………2.097.150
9-16………………………………. 4…………………………………….255.240.0.0 ou /12………1,048.574
17-32………………………………5…………………………………… 255.248.0.0 ou /13………524.286
33-64…………………………….. 6…………………………………….255.252.0.0 ou /14………262.142
65-128…………………………… 7…………………………………….255.254.0.0 ou /15………131.070
129-256…………………………. 8…………………………………….255.255.0.0 ou /16 ………65.534
257-512…………………………. 9…………………………………….255.255.128.0 ou /17……32.766
513-1.024……………………….10……………………………………255.255.192.0 ou /18….. 16.382
1.025-2.048…………………….11……………………………………255.255.224.0 ou /19 ……8.190
2.049-4.096…………………….12……………………………………255.255.240.0 ou /20…….4.094
4.097-8.192…………………….13……………………………………255.255.248.0 ou /21…….2.046
8.193-16.384…………………..14……………………………………255.255.252.0 ou /22…….1.022
16.385-32.768…………………15……………………………………255.255.254.0 ou /23…….. 510
32.769-65.536…………………16……………………………………255.255.255.0 ou /24…….. 254
65.537-131.072……………….17……………………………………255.255.255.128 ou /25…. 126
131.073-262.144……………..18……………………………………255.255.255.192 ou /26……62
262.145-524.288……………..19……………………………………255.255.255.224 ou /27……30
524.289-1.048.576…………..20……………………………………255.255.255.240 ou /28……14
1.048.577-2.097.152………..21……………………………………255.255.255.248 ou /29……..6
2.097.153-4.194.304………..22……………………………………255.255.255.252 ou /30……..2

Uma das principais características que tínhamos observado na versão anterior era a grande quantidade de conexões HTTPS com servidores externos, na ocasião verificamos que o UltraSurf realizava em média 10 conexões simultâneas na porta 443. Utilizamos essa sua peculiaridade para criar o script stopUltraSurf.sh, que, até à versão anterior do UltraSurf, funcionava perfeitamente bloqueando as conexões.

Agora tudo mudou. Na versão 9.6, o UltraSurf tenta inicialmente se conectar a um servidor pertencente à rede 65.49.2.0/24, caso consiga, o acesso será estabelecido e a estação acessará livremente a Internet. Aliás, verificamos que conectado dessa maneira o acesso será bem mais rápido se comparado às versões anteriores do UltraSurf. Como os IPs dessa rede não respondem ao DNS reverso, não têm como serem verificados pelo script stopUltraSurfe.sh, logo a conexão não será bloqueada pelo script.

Uma forma elegante de quebrar essa conexão seria bloqueando o acesso HTTPS a endereços IP que não respondessem ao DNS reverso, fizemos até uma versão do script com essa característica, mas a quantidade de falsos positivos foi bastante grande, pois, infelizmente, vários sites não seguem a recomendação do Comitê Gestor Internet Brasil (CGI.br) que diz: “Todas as redes conectadas à Internet brasileira devem operar com registros direto e reverso de DNS corretamente configurados.”, se assim fizessem, teríamos como diferenciar IPs idôneos de IPs supostamente maliciosos. O pior é que sites como o do Banco do Brasil, do Banco Real, do Banco Itaú, do Hotmail etc., que deveriam ser exemplos, não têm o DNS Reverso configurado para os IPs que respondem às conexões HTTPS. Uma pena.

Qual a solução então? Bloquear esses endereços no firewall, o problema é que, se os mantenedores do UltraSurf mudarem a sua range de IPs, o bloqueio falhará. Para efetivar o bloqueio na solução OpçãoLinux PDC, acesse as regras do firewall (opl > Firewall > Editar Regras de Firewall) e altere a linha:

HTTPS/ACCEPT     loc     net
para:

HTTPS/ACCEPT     loc     net:!65.49.2.0/24
Problema resolvido? Ainda não, caso não consiga acesso aos IPs da rede 65.49.2.0/24, o UltraSurf 9.6 tentará acessar os servidores remotos da mesma maneira que fazia nas versões anteriores, só que dessa vez não abrirá diversas conexões HTTPS, fará apenas uma única conexão. Para fazer com que o script stopUltraSurf.sh consiga detectar essa conexão, edite o arquivo /usr/local/bin/stopUltraSurf e altere a variável limitServersHttps=8 para limitServersHttps=1, ou baixe a nova versão do script stopUltraSurf.sh (veja como mais adiante).

Pronto, com o bloqueio da rede 65.49.2.0/24 no firewall e com esse ajuste na variável limitServersHttps, o script stopUltraSurf.sh deverá voltar a funcionar. Bem, pelo menos em nossos testes voltou…

Prefira utilizar a nova versão do script stopUltraSurf.sh, pois, além de estar mais rápido devido a otimizações feitas no código, será informado também qual nome do servidor que provocou o bloqueio da estação e a data e hora do bloqueio em opl > Firewall > Configurações Avançadas… > BlackList.

Caso esteja utilizando a versão mais recente da solução OpçãoLinux PDC, que já vem com o script stopUltraSurf.sh nativamente, atualize para a versão mais recente do script através dos comandos abaixo:

# wget http://www.opcaolinux.com.br/download/scripts/stopUltraSurf.sh.gz
# gunzip stopUltraSurf.sh.gz
# cat stopUltraSurf.sh > /usr/local/bin/stopUltraSurf
# rm stopUltraSurf.sh

Fonte: http://www.opcaolinux.com.br/gnulinux/tutoriais/27-seguranca/126-ultrasurf-96-como-bloquear.html

Traduzindo isso para o TCP/IP ficaria:

Suponha que

  rede 1 = 192.168.1.0 / 255.255.255.0
  rede 2 = 192.168.0.0 / 255.255.0.0
  rede 3 = 10.100.1.0 / 255.255.255.0
  rede 4 = 10.100.2.0 / 255.255.255.0
  rede 5 = 10.100.3.0 / 255.255.255.0
  ….
  ubuntu#> route add -net 192.168.0.0/16 gw 192.168.10.1
  ubuntu#> route add -net 10.100.0.0/16 gw 192.168.10.10

Com isso a tabela de roteamento da máquina que estamos configurando ficaria assim:

  ubuntu#> route
  Tabela de Roteamento IP do Kernel
  Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface
  192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
  192.168.0.0     192.168.10.1    255.255.0.0     UG    0      0        0 eth0
  10.100.0.0      192.168.10.10   255.255.0.0     UG    0      0        0 eth0
Note que a primeira linha foi adicionada automaticamente quando configuramos o endereço IP da própria máquina.

Uma maneira de melhorarmos isso é trabalhando com default gateway, ou seja, ao adicionarmos um gateway default, ele será adicionado na última linha da tabela de roteamento, de forma que todo IP com destino a uma rede que não se encaixa nas definições iniciais da tabela de roteamento serão mandadas para o default gateway (que por isso está na última linha).

Mas o escopo dessa dica é como transformar as rotas estáticas, que até aqui foram adicionadas manualmente, em configurações adicionadas automaticamente sempre que ligamos a máquina.

Já vi várias formas de adicionarmos estas rotas, desde comandos adicionados no script de inicialização do usuário, o /etc/init.d/rc.local até scripts executados ao iniciar o ambiente gráfico (arghhhh!!!), porém o mais adequado é utilizarmos os recursos que o sistema oferece para isso que são:

No Ubuntu (debian em geral): basta adicionarmos no arquivo /etc/network/interfaces as seguintes linhas:

  post-up route add -net 192.168.0.0/16 gw 192.168.10.1
  post-up route add -net 10.100.0.0/16 gw 192.168.10.10

Já em sistemas como o RedHat devemos criar o arquivo /etc/sysconfig/network-scripts/route-eth0 contendo:

  GATEWAY0=192.168.10.1
  NETMASK0=255.255.0.0
  ADDRESS0=192.168.0.0
 
  GATEWAY1=10.100.0.0
  NETMASK1=255.255.0.0
  ADDRESS1=192.168.10.10

Sendo assim toda vez que o serviço de rede subir estas rotas estáticas serão adicionadas automaticamente na tabela de roteamento de sua máquina.

Fonte: http://www.dicas-l.com.br/dicas-l/20061010.php

# apt-get [opções] comando

# apt-get [opções] install pacote [pacote ...]

A linha de comando pode ser uma variação dos tipos básicos, descritos a seguir:

apt-get update

Atualiza o banco de dados local do apt-get com os arquivos pkglist do servidor.

apt-get check

Verifica a integridade do seu sistema. Execute este comando quando tiver dúvidas quanto à integridade dos pacotes do seu sistema. É recomendável executá-lo antes de executar uma atualização de distribuição.

apt-get install algum-pacote

Instala algum pacote novo, solucionando e carregando automaticamente os pacotes dos quais o aplicativo a ser instalado depende. Caso o pacote algum-pacote já esteja instalado, o apt-get tentará atualizá-lo. Feito isto o próprio apt-get instala o pacote.

apt-get source algum-pacote

Faz o download dos fontes de um pacote (SRPM). Note que é necessário que haja uma linha com o TIPO rpm-src no arquivo sources.list para que este comando execute.

apt-get upgrade

Procura por pacotes desatualizados no sistema e os atualiza automaticamente. Atualizará todos os pacotes antigos no sistema. Para atualizar um pacote e suas dependências utilize o comando:

apt-get install pacote-a-ser-instalado
Procura nos servidores ftp pelo pacote, caso ele encontre esse pacote ele baixara ele juntamente com suas dependências.

apt-get dist-upgrade

Semelhante ao apt-get upgrade, mas instala todos os pacotes básicos e tenta atualizar tudo, instalando novos pacotes caso seja necessário. É uma maneira mais fácil de fazer uma atualização de sua distribuição.

apt-get remove algum-pacote

Remove o pacote algum-pacote e todos os demais pacotes que dele dependam.

apt-get clean

Remove os arquivos encontrados no diretório cache, liberando um pouco de espaço no seu disco de sistema. É uma maneira automática de apagar os arquivos que já foram instalados e que não são mais necessários ao sistema.

# tail -f /var/log/squid/access.log | grep 10.0.0.230

* o comando tail lista o conteúdo de um arquivo;
* o parâmetro -f fica com o arquivo aberto mostrando tudo que for adicionado a ele, como o arquivo é de log, ele sempre terá novas informações adicionadas;
* | grep é um filtro de pesquisa no resultado de um comando, ou seja, se você quiser ver quem está acessando o site www.luizoliveira.org, basta trocar o ip por luizoliveira, o comando ficaria assim:

# tail -f /var/log/squid/access.log | grep luizoliveira

Obs.: Após o grep você pode colocar um IP, nome ou site que deseja monitorar, com isso no filtro aparecerá apenas o que deseja e não várias máquinas com todos os acessos a internet que tem no momento.

zip:

gunzip nomedoarquivo.zip

rar:

unrar x nomedoarquivo.rar

tar:

tar -xvf nomedoarquivo.tar

tar.gz:

tar -vzxf nomedoarquivo.tar.gz

bz2:

bunzip nomedoarquivo.bz2

tar.bz2:

tar -jxvf nomedoarquivo.tar.bz2

Instale o pacote “debmirror” disponível em testing ou unstable:

# apt-get install debmirror

Crie um usuário e um grupo que será dono do processo que iremos automatizar para o uso do debmirror:

# groupadd mirror
# useradd -g mirror -d /mirror -c “Debian Mirror” mirror

Crie os diretórios necessários para o repositório.

# mkdir -p /mirror/debian # mkdir /mirror/non-US # chown -R mirror:mirror /mirror

Criando os scripts para a sincronização

Iremos criar agora os script para a sincronização dos repositórios:

Repositório US:

# emacs /usr/local/bin/mirror1.sh

#!/bin/bash
su mirror -c “debmirror /mirror/debian –method=http –progress –nosource –host=ftp.br.debian.org –root=/debian –dist=woody,sarge,sid –section=main,contrib,non-free –arch=i386 –cleanup –getcontents”

Repositório non-US:

# emacs /usr/local/bin/mirror2.sh

#!/bin/bash
su mirror -c “debmirror /mirror/non-US –method=http –progress –nosource –host=ftp.br.debian.org –root=/debian-non-US –dist=woody/non-US,sarge/non-US,sid/non-US –section=main,contrib,non-free –arch=i386 –cleanup ?getcontents”

Você pode alterar a opção –method por ftp, http ou rsync -e. Leia o manual do debmirror para maiores detalhes.

# man debmirror

Permitindo a leitura escrita e execução somente para o usuário root:

# chmod 700 /usr/local/bin/mirror*.sh

Repositório local, http e ftp na sua LAN
Para uso local, em seu /etc/apt/sources.list coloque as linhas:

deb file:/mirror/debian sid main non-free contrib
deb file:/mirror/non-US sid/non-US main contrib non-free

Você pode alterar a versão conforme a sua necessidade trocando onde esta sid por woody ou sarge.

Vamos agora configurar para que você possa ter o repositório disponível para outras máquinas.

Configurando o Apache:

Edite o arquivo de configuração /etc/apache/httpd.conf:

# emacs /etc/apache/httpd.conf

Troque “<Directory /var/www>” por “<Directory /mirror>”.

Reinicie o Apache:

# /etc/init.d/apache restart

Edite o arquivo /etc/apt/sources.list nos clientes para configurar o repositório no protocolo HTTP:

# emacs /etc/apt/sources.list

deb http://(ip_ou_host_do_servidor)/debian/ sid main non-free contrib
deb http://(ip_ou_host_do_servidor)/non_US/ sid/non-US main contrib non-free

Configurando o proftpd:

Para ter o repositório disponível por ftp, edite o arquivo de configuração do proftpd:

# emacs /etc/proftpd.conf

Altere as TAGS da configuração compreendidas entre <Anonymous …> </Anonymous> por:

<Anonymous ~mirror>
User                     ftp
Group                    nogroup
UserAlias                anonymous ftp
RequireValidSh           off
# Limit the maximum number of anonymous logins
MaxClients               20
DisplayLogin             welcome.msg
DisplayFirstChdir        .message
# Limit WRITE everywhere in the anonymous chroot
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>

Edite o arquivo /etc/apt/sources.list nos clientes para configurar o repositório no protocolo FTP:

deb ftp://(ip_ou_host_do_servidor)/debian/ sid main non-free contrib
deb ftp://(ip_ou_host_do_servidor)/non_US/ sid/non-US main contrib non-free

Automatizando o processo
Com o crontab podemos se aproveitar das horas de menor uso da rede para fazer a sincronização:

# crontab -e

insira a linha:

0 22 * * * /usr/local/mirror1.sh 2>&1 > /dev/null;/usr/local/mirror2.sh 2>&1 > /dev/null

Salve e feche.

# /etc/init.d/cron restart

No crontab configurei para que todos os dias a partir das 22:00hs o servidor atualize o repositório.