quinta-feira, 30 de novembro de 2017

Como recuperar o boot (MBR) do Windows 7 8 e 10



Quando um sistema operacional é instalado após o Windows, o novo sistema pode sobrescrever os arquivos de inicialização do SO da Microsoft. Distribuições Linux, por exemplo, podem instalar o GRUB na MBR, para que seja possível um dual boot entre o Windows e o Linux, considerando que o gerenciador de boot padrão do Windows não suporta outros sistemas operacionais sem o uso de gambiarras.
Mas, e se eu quiser remover o Linux do computador? A operação seria fácil: utiliza-se um editor de partições, como o EASEUS Partition Master, o conhecido Partition Magic ou o próprio editor do Windows, e então basta deletar as partições do Linux. O problema vem quando você tenta iniciar o Windows novamente. A máquina simplesmente não vai bootar, acusando um “GRUB loading error”.
Na época do Windows XP, era relativamente fácil recuperar o boot: inicie o CD de instalação, tecle R para entrar no console de recuperação, selecione a instalação do Windows que deseja recuperar e rode fixboot e fixmbr. Mas, no caso do Windows 7, esses dois “comandos mágicos” não funcionam mais. A Microsoft resolveu colocar, no DVD de instalação do Windows 7, um utilitário de “Correção de inicialização”, que nem sempre funcionará (e, dessa vez, não funcionou na minha máquina). Quando ele não funcionar, o que fazer? Simples! Aqui vai um passo a passo detalhado de como recuperar a inicialização do Windows 7:
1. Inicie o DVD de instalação do Windows 7, selecione o idioma, formato de hora e layout de teclado de acordo com suas preferências:
2. Na próxima tela, clique na opção Reparar o computador:
3. O assistente de recuperação buscará por instalações existentes do Windows 7. Depois de concluída a busca, selecione a instalação desejada e clique em Avançar:
4. Clique em Prompt de comando. Uma janela será aberta:
5. Digite o comando bootsect /nt60 ALL /force /mbr e dê Enter. Espere o Windows processar tudo. Depois, basta fechar a janela e reiniciar o micro. Pronto! O programa bootsect.exe forçará (/force) uma sobrescrita do MBR (/mbr) de todas as partições (ALL) com um código compatível com o Windows 7 (/nt60).
Extra: segundo o @giulioribas e @JoaoBerdeville, uma maneira mais “XP-like” de fazer isso seria usando os comandos BootRec.exe /fixboot e BootRec.exe /fixmbr. Se você não quiser digitar o comando enorme acima, vale a pena tentar.

OU tente isso!!! 

Windows 7
// bootsect /nt60 ALL /force /mbr
bootsect /nt60 SYS / mbr
Bootrec/FIXBOOT
Windows 8,8.1 e 10
// bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd
Plano B
// bootrec /fixmbr
bootrec /fixboot
bcdedit /export c:\bcdbackup
attrib c:\boot\bcd =h =r =s
ren c: \boot\bcd bcd.old
bootrec /rebuildbcd

quarta-feira, 29 de novembro de 2017

CONFIGURING A MULTIHOMED DHCP SERVER dhcp.conf


A multihomed DHCP server serves multiple networks, that is, multiple subnets. The examples in these sections detail how to configure a DHCP server to serve multiple networks, select which network interfaces to listen on, and how to define network settings for systems that move networks.
Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
The DHCP daemon listens on all network interfaces unless otherwise specified. Use the /etc/sysconfig/dhcpd file to specify which network interfaces the DHCP daemon listens on. The following /etc/sysconfig/dhcpd example specifies that the DHCP daemon listens on the eth0 and eth1 interfaces:
DHCPDARGS="eth0 eth1";
If a system has three network interfaces cards — eth0eth1, and eth2 — and it is only desired that the DHCP daemon listens on the eth0 card, then only specify eth0 in /etc/sysconfig/dhcpd:
DHCPDARGS="eth0";
The following is a basic /etc/dhcp/dhcpd.conf file, for a server that has two network interfaces, eth0 in a 10.0.0.0/24 network, and eth1 in a 172.16.0.0/24 network. Multiple subnet declarations allow you to define different settings for multiple networks:
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
 option subnet-mask 255.255.255.0;
 option routers 10.0.0.1;
 range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
 option subnet-mask 255.255.255.0;
 option routers 172.16.0.1;
 range 172.16.0.5 172.16.0.15;
}
subnet 10.0.0.0 netmask 255.255.255.0;
subnet declaration is required for every network your DHCP server is serving. Multiple subnets require multiple subnet declarations. If the DHCP server does not have a network interface in a range of a subnet declaration, the DHCP server does not serve that network.
If there is only one subnet declaration, and no network interfaces are in the range of that subnet, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: No subnet declaration for eth0 (0.0.0.0).
dhcpd: ** Ignoring requests on eth0.  If this is not what
dhcpd:    you want, please write a subnet declaration
dhcpd:    in your dhcpd.conf file for the network segment
dhcpd:    to which interface eth1 is attached. **
dhcpd:
dhcpd:
dhcpd: Not configured to listen on any interfaces!
option subnet-mask 255.255.255.0;
The option subnet-mask option defines a subnet mask, and overrides the netmaskvalue in the subnet declaration. In simple cases, the subnet and netmask values are the same.
option routers 10.0.0.1;
The option routers option defines the default gateway for the subnet. This is required for systems to reach internal networks on a different subnet, as well as external networks.
range 10.0.0.5 10.0.0.15;
The range option specifies the pool of available IP addresses. Systems are assigned an address from the range of specified IP addresses.
For further information, see the dhcpd.conf(5) man page.

16.4.1. Host Configuration


Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
Configuring a Single System for Multiple Networks
The following /etc/dhcp/dhcpd.conf example creates two subnets, and configures an IP address for the same system, depending on which network it connects to:
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
 option subnet-mask 255.255.255.0;
 option routers 10.0.0.1;
 range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
 option subnet-mask 255.255.255.0;
 option routers 172.16.0.1;
 range 172.16.0.5 172.16.0.15;
}
host example0 {
 hardware ethernet 00:1A:6B:6A:2E:0B;
 fixed-address 10.0.0.20;
}
host example1 {
 hardware ethernet 00:1A:6B:6A:2E:0B;
 fixed-address 172.16.0.20;
}
host example0
The host declaration defines specific parameters for a single system, such as an IP address. To configure specific parameters for multiple hosts, use multiple hostdeclarations.
Most DHCP clients ignore the name in host declarations, and as such, this name can be anything, as long as it is unique to other host declarations. To configure the same system for multiple networks, use a different name for each host declaration, otherwise the DHCP daemon fails to start. Systems are identified by the hardware ethernet option, not the name in the host declaration.
hardware ethernet 00:1A:6B:6A:2E:0B;
The hardware ethernet option identifies the system. To find this address, run the ip link command.
fixed-address 10.0.0.20;
The fixed-address option assigns a valid IP address to the system specified by the hardware ethernet option. This address must be outside the IP address pool specified with the range option.
If option statements do not end with a semicolon, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
/etc/dhcp/dhcpd.conf line 20: semicolon expected.
dhcpd: }
dhcpd: ^
dhcpd: /etc/dhcp/dhcpd.conf line 38: unexpected end of file
dhcpd:
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
Configuring Systems with Multiple Network Interfaces
The following host declarations configure a single system, which has multiple network interfaces, so that each interface receives the same IP address. This configuration will not work if both network interfaces are connected to the same network at the same time:
host interface0 {
 hardware ethernet 00:1a:6b:6a:2e:0b;
 fixed-address 10.0.0.18;
}
host interface1 {
 hardware ethernet 00:1A:6B:6A:27:3A;
 fixed-address 10.0.0.18;
}
For this example, interface0 is the first network interface, and interface1 is the second interface. The different hardware ethernet options identify each interface.
If such a system connects to another network, add more host declarations, remembering to:
  • assign a valid fixed-address for the network the host is connecting to.
  • make the name in the host declaration unique.
When a name given in a host declaration is not unique, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: /etc/dhcp/dhcpd.conf line 31: host interface0: already exists
dhcpd: }
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
This error was caused by having multiple host interface0 declarations defined in /etc/dhcp/dhcpd.conf.
Autor:  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sect-configuring_a_multihomed_dhcp_server 

terça-feira, 7 de novembro de 2017

Criando túneis seguros com SSH



Uma forma simples de encriptar protocolos que em condições normais não suportam encriptação é usar o SSH para criar túneis seguros, ligando uma das portas da sua máquina à porta do servidor onde o serviço em questão está ativo. Nesse caso, é criada uma espécie de VPN temporária, através da qual é possível acessar o serviço de forma segura. Todas as informações transmitidas são encriptadas pelo SSH, tornando seguros mesmo protocolos "escancarados", como o Telnet e o FTP. Um dos usos mais comuns para este recurso é encriptar sessões do VNC, evitando que pessoas mal intencionadas tenham acesso ao que foi feito dentro da sessão, mesmo que ela seja interceptada.
O VNC utiliza uma chave de encriptação de mão única durante a autenticação, de forma que a senha não circula abertamente pela rede. Isso impede que alguém sniffando a rede consiga capturar sua senha do VNC, como acontece no caso do Telnet, por exemplo. Apesar disso, o algoritmo de encriptação de senha usado pelo VNC não é muito seguro e, depois que a conexão é iniciada, os dados são enviados de forma não-encriptada, abrindo a possibilidade de que alguém capaz de capturar os pacotes transmitidos possa ver o que você está fazendo e até mesmo capturar as teclas digitadas no teclado.
Se você utiliza o VNC para tarefas sensíveis, como administrar servidores, acessar sistemas bancários, etc., pode implantar uma camada extra de segurança, utilizando o VNC em conjunto com o SSH. Nesse caso, a segurança é quase total, pois além de ser necessária uma dupla autenticação (primeiro no SSH e depois no VNC), todos os dados são transmitidos através da rede de forma encriptada, utilizando um algoritmo reconhecidamente seguro.
Para utilizar o SSH em conjunto com o VNC, utilizamos a opção "-L", que permite redirecionar uma determinada porta local para uma porta no servidor, criando o túnel. A sintaxe do SSH, neste caso, seria "ssh -L porta_local:servidor:porta_do_servidor servidor". Parece complicado, mas vai melhorar... :)
O servidor VNC escuta na porta 5900 + o número do display (5901, 5902, 5903, etc.). Note que a porta é diferente do servidor Java, acessível utilizando o browser, que utiliza as portas de 5800 em diante.
Se você vai acessar o display 1 (porta 5901), na máquina 220.132.54.78, precisamos orientar o SSH a redirecionar esta porta para uma porta acessível pelo cliente VNC (a própria porta 5901, ou qualquer outra) no PC local. Para isso, é necessário que o servidor SSH esteja aberto no servidor remoto e que você tenha uma conta nele. O comando seria:
$ ssh -f -N -L5901:220.132.54.78:5901 -l login 220.132.54.78

Substitua o "login" pela sua conta de usuário na máquina remota. O SSH pedirá a senha (ou passphrase) e, pronto, o túnel estará criado.
Tudo o que você precisa fazer agora é abrir o cliente VNC e acessar o endereço "127.0.0.1:1". Isso fará com que o cliente acesse a porta 5901 na máquina local, que por sua vez será redirecionada (através do túnel) para a porta 5901 do servidor remoto. Você usará o VNC da mesma forma, mas desta vez usando um túnel seguro.
Se por acaso a porta 5901 local já estiver em uso, você pode simplesmente criar o túnel apontando para outra porta da sua máquina. Se você fosse acessar o display 4 (porta 5904) no servidor 192.168.0.4, redirecionando-o para a porta 5905 (display 5) da máquina local, logando-se usando o usuário "tux", o comando seria:
$ ssh -f -N -L5905:192.168.0.4:5904 -l tux 192.168.0.4

Nesse caso, você acessaria o endereço "127.0.0.1:5" no cliente VNC, que faz com que ele se conecte na porta 5905.
A desvantagem de utilizar o SSH em vez de acessar o servidor VNC diretamente é que a atualização de tela ficará um pouco mais lenta, pois o servidor terá dois trabalhos, o de compactar os dados usando um dos algoritmos do VNC e, em seguida, encriptar os pacotes usando a chave do SSH, uma dupla jornada. Entretanto, se pensarmos do ponto de vista da segurança, a troca acaba sendo vantajosa.
Além do VNC, este comando pode ser usado para criar túneis para outras portas. Para redirecionar portas privilegiadas, da 1 a 1024, você precisa executar o comando como root. Para as portas altas (como as usadas pelo VNC), você pode usar um login normal de usuário.
O parâmetro "-f" dentro do comando faz com que ele seja executado em background, liberando o terminal depois que a conexão é estabelecida. O "-N" faz com que o SSH apenas crie o redirecionamento da porta, sem abrir um terminal do servidor remoto, enquanto o "-L" é a opção principal, que especifica que queremos fazer um redirecionamento de portas. Ele é seguido (sem espaços) pela porta local que receberá a porta remota, o endereço do servidor e a porta do servidor que será redirecionada ("-L2525:192.168.0.4:25" redireciona a porta 25 do servidor remoto para a porta 2525 da máquina local). Concluindo, o "-l" em seguida especifica o login que será usado para estabelecer a conexão, seguido pelo endereço IP do servidor.
Em resumo, a sintaxe deste longo comando é "ssh -f -N -Lporta-local:servidor:porta-do-servidor -l login servidor" (veja que é necessário especificar o endereço do servidor remoto duas vezes).
Seja qual for a porta destino, todo o tráfego é transportado através da porta do SSH e encaminhada localmente para a porta final. Graças a essa peculiaridade, os túneis são uma forma muito usada para acessar ferramentas como o Webmin, phpMyAdmin ou Swat em servidores remotos, sem precisar manter as respectivas portas abertas para toda a Internet. Basta que a porta 22 (ou outra em que o servidor SSH esteja escutando) esteja aberta para que você consiga acessar qualquer outra usando túneis. Em casos em que o servidor remoto esteja configurado para usar uma porta diferente da padrão para o SSH, adicione a opção "-p porta" no início do comando, como em:
# ssh -p 2222 -f -N -L901:gdhn.com.br:901 -l login gdhn.com.br

Continuando, um segundo exemplo interessante de uso seria usar um túnel para encriptar todo o tráfego web, de forma que você possa navegar de forma segura, ler seus e-mails, etc. mesmo ao acessar através de uma conexão wireless sem qualquer tipo de encriptação.
Para isso, é preciso que o gateway da rede (ou alguma máquina na Internet, que seja acessível por você) esteja com um servidor proxy aberto (se você estiver usando o Squid, por exemplo, o proxy ficará aberto na porta 3128 do servidor). Podemos usar então o SSH para criar um túnel, ligando a porta 3128 do servidor à porta 3128 (ou qualquer outra) do seu micro, como em:
$ ssh -f -N -L3128:gdhn.com.br:3128 -l tux gdhn.com.br

O próximo passo é configurar o navegador na sua máquina para acessar usando o proxy. Entretanto, em vez de configurar o navegador para acessar o proxy diretamente, vamos configurá-lo para procurar o proxy na porta 3128 do localhost. Isso faz com que todos os acessos sejam direcionados ao túnel criado através do SSH e cheguem até o proxy de forma encriptada:






Para ser usado dessa forma, o proxy rodando no servidor remoto deve ser configurado para aceitar conexões de qualquer cliente, já que mesmo passando pelo túnel, o acesso será computado pelo Squid como partindo do seu IP de Internet atual. Um exemplo de configuração do Squid para que o servidor permitisse a conexão de qualquer cliente remoto seria:
http_port 3128
visible_hostname gdh
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow all

Como você pode ver, essa configuração simplesmente permite acessos provenientes de qualquer endereço. O truque é que como o servidor será acessado através dos túneis criados usando o SSH, você pode manter a porta 3128 fechada no firewall do servidor, permitindo apenas conexões através da porta 22. Com isso, o servidor não ficará vulnerável, já que a única forma de chegar
até o proxy é criando um túnel até ele através do SSH.



SSH no Windows


Existem diversas versões do SSH. A maioria das distribuições Linux inclui o OpenSSH, que não possui um cliente para Windows. No entanto, isso não chega a ser um problema, pois o SSH é um protocolo aberto, o que permite o desenvolvimento de clientes para várias plataformas, inclusive Windows. Eles são usados por muita gente para administrar servidores Linux remotamente.
Um exemplo de cliente simples e gratuito é o PuTTY, que inclui também o PSFTP, um cliente de SFTP, que permite também transferir arquivos usando os comandos de transferência que já vimos (put, get, cd, lcd, pwd, lpwd, etc.). Ambos podem ser baixados no: http://www.putty.nl/
Usar o PuTTY para se conectar a servidores Linux é bem simples, pois ele não precisa sequer ser instalado. Basta baixar o arquivo e executá-lo:

m23effb76
O PuTTY também permite criar túneis encriptados. Para isso, comece colocando o IP ou o domínio do servidor a que vai se conectar no campo "Host Name (or IP address)" na tela principal, como se estivesse abrindo uma conexão normal, mas, ao invés de clicar no "open", acesse a opção "Connection > SSH > Tunels".
Na opção "source port" vai a porta do seu micro que receberá o túnel (3128, por exemplo) e no "Destination" vai o endereço IP ou domínio do servidor remoto a que você está se conectando, seguido da porta, como em "meuservidor.com.br:3128". Clique no "Add" (você pode adicionar várias portas) e em seguida no "Open", para abrir a conexão.
53132bcc
Outro exemplo de cliente SSH para Windows é a versão da SSH Security, que possui vários recursos mas é gratuita apenas para universidades e usuários domésticos e é por isso bem menos usada. O link é: http://www.ssh.com
O PuTTY e o SSH da SSH Security são inteiramente compatíveis com o OpenSSH. A grande limitação é que esses dois clientes são limitados ao modo texto, pois para exibir aplicativos gráficos via SSH, é necessário que o sistema cliente possua um servidor X, coisa que o Windows não possui nativamente. Ao tentar abrir qualquer aplicativo gráfico, você recebe a fatídica mensagem "cannot connect to X server". Também não existem servidores SSH "de verdade" para Windows, que permitam administrar um servidor Windows remotamente. As soluções de servidores SSH para Windows se concentram nos recursos de encriptação para transferências de arquivos e criação de túneis.
Voltando ao tema principal, existem alguns servidores X para Windows, que abrem uma sessão do X dentro de uma janela, como o X-Win32 (http://xwin32.dk) e o WinaXe (http://labf.com), mas uma opção muito melhor é o Xming, um software gratuito e de código aberto, disponível no:
http://www.straightrunning.com/XmingNotes/.
Quando aberto, o Xming fica residente ao lado do relógio, esperando que algum aplicativo precise dele. Para usá-lo em conjunto com o PuTTY, marque (no PuTTY) a opção "Connection > SSH > X11 > Enable X11 forwarding" (sem colocar nada no campo "X display location"). Isso faz com que o PuTTY encaminhe todas as requisições gráficas para o Xming, permitindo que os aplicativos gráficos rodem normalmente, mesmo no Windows. Embora não seja uma solução muito elegante, realmente funciona:
m337a57cf
m1226ea33
O Xming resolve o problema do uso de aplicativos gráficos via SSH no Windows, mas ele ainda não é a solução ideal para muitas situações, já que exige uma certa dose de configuração e o uso é centralizado em torno do terminal. Se você está procurando uma solução mais prática e simples, a melhor opção é o Cliente NX, que (uma vez configurado o servidor) é muito mais simples de usar e oferece uma performance muito melhor que a obtida ao rodar aplicativos gráficos através do SSH "puro", graças às várias otimizações utilizadas. Veremos mais detalhes sobre ele logo a seguir.
Você pode baixar o cliente NX for Windows no http://nomachine.com. No site, você pode fazer um "testdrive", acessando um dos servidores da empresa. O NX trabalha sobre o SSH, implementando um conjunto de otimizações para reduzir o tráfego e a latência das conexões. O resultado é algo similar ao VNC, mas com um desempenho bem melhor. Ao contrário do PuTTY, no NX tudo é feito através de um cliente gráfico:
m7f47465b
Na hora de transferir arquivos via SFTP, uma boa opção é o FileZilla, um cliente de FTP gráfico e bastante amigável, que inclui suporte ao SFTP. Você pode baixá-lo no:
http://filezilla.sourceforge.net/
Para conectar via SFTP, use a opção "File > Site Manager > New Site" para criar a conexão. Só assim você tem acesso à opção de usar o SFTP, já que os campos na tela principal servem apenas para servidores FTP:
m71c75333
Na tela seguinte, informe o IP do servidor, a porta (22) e a conta de acesso. Uma vez conectado, você acessa os arquivos usando a interface tradicional dos clientes de FTP, com as duas janelas, uma mostrando os arquivos locais e outra mostrando os do servidor. Para transferir arquivos, basta arrastá-los entre as duas.

segunda-feira, 30 de outubro de 2017

Substituindo ifconfig por ip Debian 8 e 9


jack-ip-1
Se você esteve no Linux por tempo suficiente, você sabe que as ferramentas vão e vem. Este foi considerado o caso em torno de 2009, quando a lista de discussão debian-devel anunciou planos de depreciação do pacote de ferramentas líquidas devido à falta de manutenção. Agora é 2015 e as ferramentas de rede ainda estão por aí. Na verdade, a partir do Ubuntu 14.10, você ainda pode emitir o comando ifconfig para gerenciar sua configuração de rede.
No entanto, em alguns casos (por exemplo, o recipiente Ubuntu Docker ), o conjunto de ferramentas de rede não está instalado por padrão. Isso significa que o comando ifconfig não está disponível. Embora você possa instalar net-tools com o comando
  sudo apt-get install net-tools 
é mais frequente recomendar avançar com o comando que substituiu ifconfig. Esse comando é ip, e faz um ótimo trabalho para entrar no ifconfig desatualizado.
A coisa é, ip não é uma substituição drop-in para ifconfig. Existem diferenças na estrutura dos comandos. Mesmo com essas diferenças, ambos os comandos são usados ​​para fins semelhantes.Na verdade, ip pode fazer o seguinte:
  • Descubra quais interfaces são configuradas em um sistema
  • Consulta o status de uma interface de rede
  • Configure as interfaces de rede (incluindo loopback local e Ethernet)
  • Traga uma interface para cima ou para baixo
  • Gerencie o roteamento padrão e estático
  • Configurar o túnel sobre IP
  • Configurar a entrada de cache ARP ou NDISC
Com tudo isso dito, vamos embarcar em substituir ifconfig por ip. Vou oferecer alguns exemplos de como o comando de substituição é usado. Compreenda que este comando exige privilégios de administrador (então você terá que su para criar ou fazer uso de sudo - dependendo da sua distribuição). Como esses comandos podem fazer alterações nas informações de rede da sua máquina, use-as com cautela.
NOTA: Todos os endereços usados ​​neste procedimento são exemplos. Os endereços que você usará serão ditados pela sua rede e seu hardware.
Agora, com o how-to.

Juntando informações

A primeira coisa que a maioria das pessoas aprende com o comando ifconfig é como descobrir qual endereço IP foi atribuído a uma interface. Isso geralmente é feito com o comando ifconfig e sem sinalizadores ou argumentos. Para fazer o mesmo com o comando ip, ele é executado como tal:
  ip a 
Este comando irá listar todas as interfaces com as informações associadas (Figura 1 acima).
Digamos que você só deseja ver as informações IPv4 (para maior clareza). Para fazer isso, emita o comando:
  ip -4 a 
Ou, se você quiser apenas ver informações IPv6:
  ip -6 a 
E se você quiser apenas ver informações sobre uma interface específica? Você pode listar informações para uma conexão sem fio com o comando:
 ip um show wlan0 
Você pode até se tornar mais específico com este comando. Se você quiser apenas ver IPv4 na interface wlan0, emita o comando:
  ip -4 um show wlan0 
Você pode até listar apenas a interface executando usando:
  ip link ls up 

Modificando uma interface

Agora entramos no coração do comando ... usando-o para modificar uma interface. Suponha que você quisesse atribuir um endereço específico à primeira interface ethernet, eth0. Com o comando ifconfig, isso pareceria:
  ifconfig eth0 192.168.1.101 
Com o comando ip, isso agora parece:
  ip a add 192.168.1.101/255.255.255.0 dev eth0 
Você poderia encurtar um pouco com:
  ip a add 192.168.1.101/24 dev eth0 
Claramente, você precisará saber a máscara de sub-rede do endereço que você está atribuindo.
E sobre como excluir um endereço de uma interface? Com o comando ip, você também pode fazer isso. Por exemplo, para excluir o endereço apenas atribuído ao eth0, emita o seguinte comando:
  ip a del 192.168.1.101/24 dev eth0 
E se você quiser simplesmente liberar todos os endereços de todas as interfaces? O comando ip tem coberto com este comando:
  ip -s -saf to 192.168.1.0/24 
Outro aspecto crucial do comando ip é a capacidade de abrir / desligar uma interface. Para reduzir o eth0, emita:
  ip link set dev eth0 down 
Para fazer backup do eth0, use:
  conjunto de links IP dev eth0 up 
Com o comando ip, você também pode adicionar e excluir gateways padrão. Isso é assim:
  ip route add default via 192.168.1.254 
Se você quiser se detalhar sobre suas interfaces, você pode editar a fila de transmissão. Você pode configurar a fila de transmissão para um valor baixo para interfaces mais lentas e um valor maior para interfaces mais rápidas. Para fazer isso, o comando pareceria:
  ip link set txqueuelen 10000 dev eth0 
O comando acima configuraria uma fila de transmissão elevada. Você pode brincar com esse valor para encontrar o que funciona melhor para o seu hardware.
Você também pode definir a unidade de transmissão máxima (MTU) da sua interface de rede com o comando:
  ip link set mtu 9000 dev eth0 
Depois de ter feito as alterações, use ip uma lista eth0 para verificar se as mudanças entraram em vigor.

Gerenciando a tabela de roteamento

Com o comando ip você também pode gerenciar as tabelas de roteamento do sistema. Este é um elemento muito poderoso do comando ip, e você deve usá-lo com cautela.
Suponha que você deseja visualizar todas as tabelas de roteamento. Para fazer isso, você emitiria o comando:
  ip r 
A saída deste comando será semelhante à mostrada na Figura 2.
jack-ip-2-crop
Agora, diga que deseja encaminhar todo o tráfego através do gateway 192.168.1.254 conectado via interface de rede eth0: Para fazer isso, emita o comando:
  ip route add 192.168.1.0/24 dev eth0 
Para excluir a mesma rota, emita:
  ip route del 192.168.1.0/24 dev eth0 
Este artigo deve servir como apenas uma introdução ao comando ip. Isso, é claro, não significa que você deve pular imediatamente do ifconfig. Como a desaprovação do ifconfig foi tão lenta, o comando ainda existe em várias distribuições. Mas, por ocasião de que o falecimento finalmente desapareça da visão, você estará pronto para fazer a transição com facilidade. Para obter informações mais detalhadas sobre o comando ip, dê uma olhada na página ip man emitindo o comando man ip a partir de uma janela de terminal.

sábado, 28 de outubro de 2017

Nomes de interface de rede previsível nova nomenclatura


Começando com o v197 systemd / udev atribuirá automaticamente nomes de interface de rede estáveis ​​e estáveis ​​para todas as interfaces Ethernet, WLAN e WWAN locais. Esta é uma partida do esquema de nomeação da interface tradicional ("eth0", "eth1", "wlan0", ...), mas deve consertar problemas reais.

Por quê?

O esquema de nomeação clássico para interfaces de rede aplicado pelo kernel é simplesmente atribuir nomes que começam com "eth0", "eth1", ... para todas as interfaces à medida que são testadas pelos drivers. Como a sondagem do driver geralmente não é previsível para a tecnologia moderna, isso significa que, assim que as várias interfaces de rede estiverem disponíveis, a atribuição dos nomes "eth0", "eth1" e assim por diante geralmente não é corrigida e pode muito bem acontecer que " eth0 "em uma inicialização acaba sendo" eth1 "no próximo. Isso pode ter sérias implicações de segurança, por exemplo em regras de firewall que são codificadas para determinados esquemas de nomeação e, portanto, muito sensíveis a nomes de mudanças imprevisíveis.
Para resolver este problema, foram propostas e implementadas várias soluções. Durante mais tempo, o udev enviou suporte para atribuir nomes "ethX" permanentes a certas interfaces com base em seus endereços MAC. Isso resultou em uma grande quantidade de problemas, entre eles: isso exigiu um diretório raiz gravável que geralmente não está disponível; a apatridia do sistema é perdida quando a inicialização de uma imagem do sistema operacional em um sistema resultará na alteração da configuração da imagem; em muitos sistemas, os endereços MAC não são realmente corrigidos, como em muitos hardware incorporado e particularmente em todos os tipos de soluções de virtualização. O maior de todos, no entanto, é que os componentes do espaço de usuários que tentam atribuir o nome da interface correu contra o kernel atribuindo novos nomes do mesmo espaço de nomes "ethX", uma condição de corrida com todos os tipos de efeitos estranhos, entre eles que a atribuição de nomes às vezes falhou. Como resultado, o suporte para isso foi removido do systemd / udev há algum tempo.
Outra solução que foi implementada é "biosdevname" que tenta encontrar informações de topologia de slot fixas em certas interfaces de firmware e as usa para atribuir nomes fixos a interfaces que incorporam sua localização física na placa-mãe. De certa forma, esse esquema de nomeação é semelhante ao que já foi feito nativamente em udev para vários nós de dispositivos via / dev / * / by-path / links simbólicos. Em muitos casos, o biosdevname parte dos esquemas de identificação de dispositivo de núcleo de baixo nível que a udev geralmente usa para esses links simbólicos e, em vez disso, inventa seus próprios esquemas de enumeração.
Finalmente, muitas distribuições suportam interfaces de renomeação para nomes escolhidos pelo usuário (pense: "internet0", "dmz0", ...) bloquearam seus endereços MAC ou locais físicos como parte de seus scripts de rede. Esta é uma escolha muito boa, mas tem o problema de que isso implica que o usuário está disposto e capaz de escolher e atribuir esses nomes.
Acreditamos que é uma boa escolha padrão para generalizar o esquema iniciado pelo "biosdevname". A atribuição de nomes fixos com base em informações de firmware / topologia / localização tem a grande vantagem de os nomes serem totalmente automáticos, totalmente previsíveis, que eles permaneçam fixos, mesmo que o hardware seja adicionado ou removido (ou seja, não há reenenção) e que o hardware quebrado pode ser substituído perfeitamente. Dito isto, eles são, às vezes, mais difíceis de ler do que o "eth0" ou "wlan0", todos estão acostumados. Exemplo: "enp5s0"

O que mudou exatamente em v197?

Com o sistema 197, adicionamos suporte nativo para uma série de diferentes políticas de nomeação no sistema / udevd propriamente dito e criamos um esquema semelhante aos sistemas de identificação de dispositivos internos do biosdevname (mas geralmente mais poderosos e mais próximos do kernel) padrão. Os seguintes diferentes esquemas de nomeação para interfaces de rede agora são suportados pela udev nativamente:
  1. Os nomes que incorporam o Firmware / BIOS forneceram números de índice para dispositivos de bordo (exemplo: eno1 )
  2. Os nomes que incorporam o firmware / BIOS fornecem números de índice de slot de hotplug PCI Express (exemplo: ens1 )
  3. Nomes que incorporam a localização física / geográfica do conector do hardware (exemplo: enp2s0 )
  4. Nomes que incorporam o endereço MAC das interfaces (exemplo: enx78e7d1ea46da )
  5. Clássico, imprevisível kernel-native ethX nomeação (exemplo: eth0 )
Por padrão, o sistema v197 agora nomeará as interfaces após a política 1) se essas informações do firmware forem aplicáveis ​​e disponíveis, retornando para 2) se essa informação do firmware for aplicável e disponível, voltando para 3) se aplicável, caindo de volta para 5) em todos os outros casos. Política 4) não é usada por padrão, mas está disponível se o usuário assim o optar.
Esta política combinada só é aplicada em último recurso. Isso significa que, se o sistema tiver o biosdevname instalado, prevalecerá. Se o usuário tiver adicionado regras udev que alterem o nome dos dispositivos kernel, isso também terá precedência. Além disso, todos os esquemas de nomenclatura específicos da distribuição geralmente têm precedência.

Venha novamente, o que isso faz?

Com este novo esquema, você agora obtém:
  • Nomes de interface estáveis ​​em reinicializações
  • Nomes de interface estáveis ​​mesmo quando o hardware é adicionado ou removido, ou seja, não existe uma nova enumeração (para o nível que o firmware permite)
  • Nomes de interface estáveis ​​quando kernels ou drivers são atualizados / alterados
  • Nomes de interface estáveis ​​mesmo se você tiver que substituir cartões de ethernet quebrados por novos
  • Os nomes são determinados automaticamente sem a configuração do usuário, eles apenas funcionam
  • Os nomes das interfaces são totalmente previsíveis, ou seja, apenas olhando para lspci, você pode descobrir o que a interface será chamada
  • Operação totalmente apátrida, alterar a configuração de hardware não resultará em mudanças em / etc
  • Compatibilidade com a raiz somente leitura
  • A nomeação da interface de rede agora segue mais de perto o esquema usado para aliasing nodos de dispositivo de bloco e outros nós de dispositivo em / dev via links simbólicos
  • Aplicabilidade às máquinas x86 e não x86
  • O mesmo em todas as distribuições que adotaram systemd / udev
  • É fácil cancelar o esquema (veja abaixo)
Isso tem alguma desvantagem? Sim. Anteriormente, estava praticamente garantido que os hosts equipados com uma única placa ethernet possuíam uma única interface "eth0". Com este novo esquema no lugar, um administrador agora tem que verificar primeiro o nome da interface local antes que ele possa invocar comandos sobre ele onde anteriormente ele tinha uma boa chance de que "eth0" fosse o nome certo.

Eu não gosto disso, como desativar isso?

Você basicamente tem três opções:
  1. Você desabilita a atribuição de nomes fixos, de modo que os nomes de kernel imprevisíveis sejam usados ​​novamente. Para isso, simplesmente mascara o arquivo .link da udev para a política padrão: ln -s /dev/null /etc/systemd/network/99-default.link
  2. Você cria seu próprio esquema de nomeação manual, por exemplo, nomeando suas interfaces "internet0", "dmz0" ou "lan0". Para isso, crie seus próprios arquivos .link em / etc / systemd / network /, que escolha um nome explícito ou um esquema de nomeação melhor para um, alguns ou todas as suas interfaces. Consulte systemd.link (5) para obter mais informações.
  3. Você passa a net.ifnames = 0 na linha de comando do kernel

Como o novo esquema de nomeação se parece, precisamente?

Isso está documentado em detalhes em um comentário, bloqueando as origens do net_id incorporado . Por favor, consulte isso caso você esteja se perguntando como decodificar os novos nomes de interface.

Original: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/