Saudações.
Esse tutorial é um guia rápido de uso de todos os túneis e VPNs do Linux.
Pré-requisitos (constam em outros artigos aqui do blog):
- Instalação do Linux (Debian);
- Internet no servidor (sua VPS ou host);
- Opcional: 2 servidores Linux (VPS/VM) com IP público:
- IPv4 público;
- IPv6 global;
1 – Considerações gerais
Túneis envolvem encapsular pacotes ou quadros de uma rede primária (do usuário ou aplicação) e colocar dentro de pacotes IP para transporte na Internet ou backbone.
1.1 – Overhead por camada
Overhead por camada:
- Camada 2 – Quadro:
- Ethernet: 14 bytes;
- Ethernet com VLAN: 18 bytes (14+4);
- Ethernet com PPP (PPPoE): 22 bytes (14+8);
- Ethernet com VLAN e PPPoE: 26 bytes (14+4+8);
- Camada 3 – Pacote:
- IPv4: 20 bytes;
- IPv6: 40 bytes;
- Camada 4 – Segmento:
- ICMP: 8 bytes;
- UDP: 8 bytes;
- TCP: 20 bytes;
- Camadas adicionais de criptografia:
- TLS, SSL, Wireguard, OpenVPN, etc;
1.2 – Pacote dentro de pacote
A Internet possui um tamanho de pacote natural de 1500 bytes por conta do limite natural de ethernet (acesso) de 1518 bytes. Exemplo
- Pacote IPv4 com 1500 bytes capaz de transportar 1480 bytes de payload;
- Pacote IPv6 com 1500 bytes capaz de transportar 1460 bytes de payload.
O payload de um pacote IP não contem dados puros, eles devem estar encapsulados com outros protocolos:
- Outro pacote IPv4 ou IPv6;
- Um cabeçalho de VPN stateless: GRE, SIT;
- Um cabeçalho de camada 4: TCP, UDP, SCTP, …
1.3 – MTU do túnel
O MTU do tunel deve considerar:
- O MTU máximo permitido entre as duas pontas:
- Internet IPoE (padrão): 1500 byes;
- Internet via PPPoE: 1480 a 1492 bytes;
- Internet com provedor usando GRE de anti-DDos:
- GRE em IPv4 com teto de 1476 bytes (-24 bytes);
- GRE em IPv6 com teto de 1448 bytes (-52 bytes);
- Fazer path mtu discovery (PMTU) entre as pontas para saber o MTU real e seguro sem fragmentação;
- Monitorar o PMTU e disparar alertas quando ele for alterado;
- Considerar o overhead do protocolo de túnel para saber o MTU da VPN.
Principais túneis e seus overheads:
| Protocolo | Tunnel Header | Overhead Total | Atravessa NAT | Transporte |
| PPPoE | 8 | 8 | – | LAN only |
| MAC-Sec | ? | ? | – | LAN only |
| IP over IPv4 | 0 | 20 | Não | L3oIPv4 |
| IP over IPv6 | 8 | 40 | Não | L3oIPv6 |
| GRE over IPv4 | 4 | 24 | Não* | L3oIPv4 |
| GRE over IPv6 | 12 | 52 | Não | L3oIPv6 |
| GRE L2 over IPv4 | 22 | 42 | Não | L2oIPv4 |
| GRE L2 over IPv6 | 30 | 70 | Não | L2oIPv6 |
| SIT over IPv4 | 0 | 20 | Não | IPv6oIPv4 |
| VXLAN over IPv4 | 30 | 50 | Sim | L2oUDP-IPv4 |
| VXLANover IPv6 | 30 | 70 | Sim | L2oUDP-IPv6 |
| GENEVE over IPv4 | 30 | 50 | Sim | L2oUDP-IPv4 |
| GENEVE over IPv6 | 30 | 70 | Sim | L2oUDP-IPv6 |
| Wireguard IPv4 | ? | ? | Sim | L3oUDP-IPv4 |
| Wireguard IPv6 | ? | ? | Sim | L3oUDP-IPv6 |
| OpenVPN IPv4 UDP | 88 | 88 | Sim | L3oUDP-IPv4 |
| OpenVPN IPv6 UDP | ? | ? | Sim | L3oUDP-IPv6 |
| Mikrotik EoIP – IPv4 | 8 | 42 | Não | L2oIP-IPv4 |
| Mikrotik EoIP – IPv6 | 8 | 136 | Não | L2oIP-IPv6 |
Exemplos usando a tabela acima:
- Túnel GRE sobre IPv4 com PMTU de 1500 bytes (1500 – 24 = 1476), o túnel terá o MTU de 1476 bytes;
- Túnel GENEVE sobre IPv6 com PMTU de 1492 bytes (1492 – 50 = 1442), túnel terá o MTU de 1442 bytes;
- Túnel Wireguard sobre IPv4 com PMTU de 1480 bytes (1480 – ? = ??), túnel terá o MTU de ??? bytes;
1.4 – Conntrack – Com ou sem estado de conexão
VPN stateless (sem estado) apenas encapsulam um pacote dentro de outro pacote e enviam para o destinatário, não existe negociação entre as pontas para combinar o estabelecimento do túnel.
VPN statefull (com estado) requerem essa negociação prévia para autenticação, negociação de chaves, certificado, troca de atributos, etc…
1.5 – Passagem por NAT
Túneis stateless baseadas em IP (IP over IP, GRE) normalmente não atravessam NAT.
Túneis stateless ou statefull baseados em TCP ou UDP são passiveis de atravessarem de um cliente atras de NAT para um servidor com IP público.
Existe a possibilidade de dois clientes atras de NAT se conectarem diferetamente, isso requer um servidor STUN e um algorítimo bem sensível para que os clientes “acertem” um par de portas de cada lado para enganar o traduzir reverso do NAT.
1.6 – Algoritmo de NAT
Um caso especial de VPN stateless com boot statefull é o PPTP.
Ele inicia negociações usando TCP e depois cria o túnel IP sobre IP com encapsulamento GRE, opcionalmente com IPSEC, que normalmente não atravessa NAT.
O algoritmo de NAT dos roteadores (CPEs, Firewalls, CG-NAT) possuem, ou pelo menos deveria possuir, um algoritmo alg-pptp capaz de entender o NAT desse tipo de conexão, realizando o NAT 1:1 dinâmico do mapa completo de IPs envolvidos no túnel.
A ausência desses “algs” especiais impedem o estabelecimento da conexão, que normalmente inicia o processo de autenticação mas quebra por timeout.
1.7 – Fragmentação transparente
A fragmentação transparente pode ser considerado um recurso ou um problema grave.
Um túnel entre dois roteadores tem seu MTU naturalmente reduzido pelo overhead. Cada tipo de túnel pode se comportar de maneira diferente em relação ao pacote de entrada maior que o MTU do túnel, comportamentos:
- OUTSIDE: Encapsular o pacote, gerando um pacote IP maior que o MTU natural do próximo saldo ou do caminho, isso gera a fragmentação do pacote de transporte. Esse é o comportamento mais comum e mais perigoso pois firewalls no caminho podem destruir os fragmentos tornando impossível remontar o pacote original na ponta remota;
- INSIDE: Fragmentar o pacote original na entrada em pedaços e enviar os pedaços no túnel, isso é desejável pois a Internet não fica sabendo dos fragmentos, é o comportamento mais raro de encontrar nos sistemas operacionais;
- ASSEMBLY e DISASSEMBLY: Modo avançado, os pacotes originais são fragmentados na entrada do túnel e a outra ponta do túnel remonta o pacote original. Isso permite que a VPN transporte qualquer MTU através da Internet.
1.8 – Camada transportada
Túneis podem transportar quadros (L2 = camada 2) ou pacotes (L3 = camada 3).
Os túneis de camada 2 estendem a rede LAN/VLAN/ethernet para saltos distantes, funcionando como um “path-cord” virtual entre dos pontos da rede. São muito utilizados para interligar matriz-filial e interconectar containers e máquinas virtuais.
Os túneis de camada 3 transportam pacotes de redes roteadas, majoritariamente pacotes IPv4 ou IPv6.
2 – Tecnologias de túneis
Cada padrão de transporte de quadros sobre pacotes (ETH over IP) e pacotes sobre pacotes (IP over IP) foi criado para resolver problemas específicos de cada ano.
Tabela de tecnologias, padrões RFC e propósito:
| Ano | Tecnologia | RFC / Origem | Proposito |
|---|---|---|---|
| 1994 | GRE | RFC 1701, RFC 1702 | Interligar matriz-filial e prover VRFs interconectadas. |
| 1995 | IPIP | RFC 1853, RFC 2003 | Alternativa simplificada do GRE |
| 1996 | SIT (6in4) | RFC 1933 | Migração para IPv6 em rede padronizada em IPv4 |
| 1998 | ip6tnl | RFC 2473 | Padronizar túneis IP transportados sobre IPv6 |
| 2000 | GRE | RFC 2784, RFC 2890 | Modernização do padrão GRE |
| 2005 | SIT (6in4) | RFC 4213 | Padronização do SIT generalizado |
| 2005 | VTI/VTI6 | IPsec (RFC 4301) | Padronizar túneis IP sobre IP com criptografia |
| ~2007 | ERSPAN v1 | Cisco, proprietario | Clonagem de tráfego remoto, port-mirror a distância transmitido em GRE |
| ~2008 | ERSPAN v2 | Cisco, proprietario | Novo padrão ERSPAN |
| 2014 | VXLAN | RFC 7348 | Padrão da industria de datacenter para transporte ethernet sobre IP para substituir VLANs |
| 2015 | FOU | Kernel Linux 3.18+ | Túneis white label para VPNs de todos os tipos sobre UDP |
| 2017 | GRE-in-UDP | RFC 8086 | GRE transportado sobre UDP para se aproximar com as funcionalidades do VXLAN |
| 2017 | GUE | draft-ietf | Tentativa de padrão fracassado |
| 2018 | XFRM interface | Kernel Linux 4.19+ | Framework de encapsulamento genérico de dados para montagem de túneis |
| 2019 | bareudp | Kernel Linux 5.4+ | Túneis white label para VPNs de todos os tipos sobre UDP |
| 2020 | WireGuard | Kernel Linux 5.6 / Whitepaper | Túneis IP sobre UDP com criptografia avançada |
| 2020 | GENEVE | RFC 8926 | Standards Track |
2.1 – IP-IP
Os túneis IP-IP são os mais simples possíveis, apenas colocam o pacote IP (IPv4 ou IPv6) dentro de outro pacote IP.
Não há nenhum mistério nisso.
A simplicidade dá lugar a falta de multiplexação: para cada túnel é necessário um par único de IPs pois o túnel não possui um identificador interno.
O objetivo rápido dos túneis IP-IP era implementar o IPsec – criptografia a nível de pacotes – para transportar os dados com segurança a nível de rede camada 3 em uma época que o SSL e TLS não estavam presentes como acontece hoje.
2.2 – GRE
O GRE (Generic Routing Encapsulation) é o mais antigo dos tuneis padronizados e usados por operadoras para transportar quadros ou pacotes encima de redes IP, no backbone (MTU flexível) ou cruzando a Internet (MTU restrito ao máximo 1500 bytes).
Ainda é muito utilizado hoje em dia combinado com IPSEC e para transito BGP remoto em datacenters de anti-DDoS (scrubbing center – centro de limpeza).
Túneis GRE permitem que sejam criados até 4 bilhões de túneis nos mesmos IPs fim-a-fim (endpoints).
2.3 – VXLAN
Criado em 2010 e padronizado em 2014, o VXLAN (Virtual eXtensible Local Area Network) foi criado para transportar quadros ethernet sobre IP (IPv4 ou IPv6) entre servidores em um datacenter.
Seu foco era substituir as VLANs limitadas a 4095 circuitos (total de VIDs – VLAN IDs) e fortemente acopladas aos switchs do datacenter. O VXLAN utiliza UDP e um cabeçalho que define o VNI (VXLAN Network Identifier) com 24 bits, aumentando para 16 milhões de redes possíveis por implementação.
Cada equipamento que encapsula e desencapsula quadros ethernet em VXLAN é chamado de VTEP (VXLAN Tunnel End Point).
Os VTEPs podem se comunicar por IP específico entre si – unicast, ou por grupo multicast.
O VXLAN não possui um campo de identificador de protocolo, assumindo que o payload é sempre Ethernet e utiliza porta UDP padrão 4789.
2.4 – GENEVE
O GENEVE foi iniciado junto com o VXLAN mas demorou mais tempo para ficar pronto, sendo publicado oficialmente em 2020.
A diferença é a flexibilidade, ele pode transportar qualquer tipo de unidade, Ethernet ou IP.
O cabeçalho GENEVE permite adicionar metadados extensíveis que permitem que o protocolo evolua para transportar qualquer tipo de informação para qualquer tipo de finalidade.
Esse protocolo promete substituir todos os protocolos anteriores.
2.5 – WireGuard e OpenVPN
Esses dois tipos de VPNs não possuem RFC ou padrão de industria, apenas o padrão definido pelos criadores e se destacam pelo forte framework de criptografia.
3 – Laboratório de túneis
Você pode realizar esses testes entre máquinas virtuais no seu PC/Desktop/Notebook, entre nós no GNS3 ou onde preferir.
Eu recomendo as seguintes etapas:
- 1 – Montar em VMs locais para aprender o básico;
- 2 – Fazer entre VPSs para integrar comunicação segura;
- 3 – Fazer entre VMs locais e VPSs para testar com travessia de NAT.
Softwares como tcpdump e Wireshark são vitais para analisar e observar os pacotes, programas de comandos como iperf3, fping, ping são vitais para testes de banda e conectividade.
Crie o máximo de problemas nos seus laboratórios!
3.1 – VPS na nuvem para exemplos
Vou utilizar 2 VPSs na nuvem com esses IPs de exemplo para demonstrar o funcionamento das VPNs:
- VPS 1: IPv4 45.255.128.2 e IPv6 2804:cafe::2
- VPS 2: IPv4 200.100.50.25 e IPv6 2001:fada::25
Diagrama:
flowchart TB
VPS1["VPS 1<br>IP: 45.255.128.2<br>2804:cafe::2"] o--o n1["Internet"]
n1 o--o VPS2["IP: 200.100.50.25<br>2001:fada::25<br>VPS 2"]
n1@{ shape: hex}
style VPS1 fill:#00C853,color:#023400
style n1 fill:#FFF9C4
style VPS2 fill:#6ac6ff,color:#213d8aVocê deverá substituir os IPs envolvidos pelos seus IPs reais.
3.2 – Nome das interfaces de túneis
Prefixos dos nomes dos túneis de acordo com o protocolo:
- eth: interface LAN ethernet (acesso ou com vlan);
- vth: interface LAN virtual-ethernet entre namespaces dentro do mesmo Linux;
- br: interface bridge usada para unir outras interfaces L2 como um switch;
- ipi: túnel IP (L3) sobre IPv4;
- ipx: túnel IP (L3) sobre IPv6;
- gre: túnel GRE (L3) sobre IPv4;
- grx: túnel GRE (L3) sobre IPv6;
- gee: túnel GRE-TAP (L2) sobre IPv4;
- gex: túnel GRE-TAP (L2) sobre IPv6;
- gnv: túnel GENEVE sobre IPv4;
- gnx: túnel GENEVE sobre IPv6;
- vxl: VXLAN sobre IPv4;
- vxx: VXLAN sobre IPv6;
- tap: túnel genérico de camada 2 gerida por software;
- tun: túnel genérico de camada 3 gerida por software;
No Linux, o nome das interfaces de rede tem limite de 15 caracteres ASCII, logo, usando um prefixo de 3 dígitos teremos outros 12 dígitos para colocar o nome ou número do túnel.
3.3 – Suporte no kernel Linux
Ferramentas necessárias para setup e manutenção:
# Ferramenta de setup:
apt-get -y install iproute2;
# Ferramentas de testes e diagnosticos:
apt-get -y install mtr;
apt-get -y install vlan;
apt-get -y install fping;
apt-get -y install tcpdump;
apt-get -y install iputils-ping;
apt-get -y install traceroute;
Módulos necessários no kernel Linux para que as interfaces de túneis possam ser criadas. Escolha os módulos de acordo com os tipos que for utilizar. Para o laboratório aplique todos:
# Módulos do kernel para dar suporte a túneis
# - Suporte a VLAN
echo "8021q" > /etc/modules-load.d/vlan.conf;
# - Suporte a VETH (virtual ethernet)
echo "veth" > /etc/modules-load.d/veth.conf;
# - Suporte a bridge L2
echo "bridge" > /etc/modules-load.d/bridge.conf;
# - Suporte a GRE
echo "ip_tunnel" > /etc/modules-load.d/ip_tunnel.conf;
echo "ip_gre" > /etc/modules-load.d/ip_gre.conf;
echo "gre" > /etc/modules-load.d/gre.conf;
# - Suporte a tuneis sobre UDP, pre-requisito para: wireguard, vxlan, geneve
echo "udp_tunnel" > /etc/modules-load.d/udp_tunnel.conf;
echo "ip6_udp_tunnel" > /etc/modules-load.d/ip6_udp_tunnel.conf;
# - Suporte a VXLAN
echo "vxlan" > /etc/modules-load.d/vxlan.conf;
# - Suporte a GENEVE
echo "geneve" > /etc/modules-load.d/geneve.conf;
# Carregar todos imediatamente:
systemctl restart systemd-modules-load;
4 – Túneis IP sobre IP
Vamos abordar os tipos mais simples de túneis stateless baseados em colocar pacotes IP dentro de outros pacotes IP e enviar pela rede.
4.1 – IP over IPv4
Esse é o tipo mais fundamental e básico que existe.
Não há cabeçalho que determine o tipo de túnel, em vez disso, o campo Protocol do cabeçalho IPv4 informa que o conteúdo é diretamente um pacote IPv4 (código 4, 0x04).
O túnel IPoIPv4 (ipip) não transporta IPv6.
O túnel IPoIPv4 não possui um identificador de túnel, só é possivel ter um túnel por par de IPs das pontas.
O overhead total é de 20 bytes (IPv4=20), o MTU padrão é 1480 bytes (infra 1500).
VPS 1
# VPS 1 - IP sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 1
ip link add ipi0102 type ipip local $VPS1v4 remote $VPS2v4 ttl 255;
ip link set up ipi0102;
ip -4 addr add dev ipi0102 198.18.1.1/24;
VPS 2
# VPS 2 - IP sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 2
ip link add ipi0201 type ipip local $VPS2v4 remote $VPS1v4 ttl 255;
ip link set up ipi0201;
ip -4 addr add dev ipi0201 198.18.1.2/24;
4.2 – IP over IPv6
O transporte de IP sobre IPv6 não é tão puro quanto o IPoIPv4, ele adiciona o campo NextHeader do tipo Destination Option(código 60, 0x3c) que por sua vez extende o cabeçalho IPv6 em 8 bytes e, nele, configura-se o próximo NextHeader informando o tipo de payload: pacote IPv4 (código 4, 0x04) ou IPv6 (código 41, 0x29).
O túnel IPoIPv6 não possui um identificador de túnel, só é possivel ter um túnel por par de IPs das pontas.
Com isso o overhead total soma 48 bytes (IPv6=20, DSTOPT=8), o MTU padrão é 1452 bytes (infra 1500).
O driver ip6tnl (IPv6 tunneling) do Linux possui o modo de operação (mode):
- mode ipip6: Transporta exclusivamente IPv4 sobre IPv6, não transporta IPv6 dentro de IPv6;
- mode ip6ip6: Transporta exclusivamente IPv6 sobre IPv6, não transporta IPv4 dentro de IPv6;
- mode any (padrão): Transporta qualquer protocolo de camada 3 sobre IPv6.
VPS 1:
# VPS 1 - IP sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 1
ip link add ipx0102 type ip6tnl local $VPS1v6 remote $VPS2v6 ttl 255;
ip link set up ipx0102;
ip -4 addr add dev ipx0102 198.18.2.1/24;
ip -6 addr add dev ipx0102 2001:db8:198:18:2::1/120;
VPS 2:
# VPS 2 - IP sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 2
ip link add ipx0201 type ip6tnl local $VPS2v6 remote $VPS1v6 ttl 255;
ip link set up ipx0201;
ip -4 addr add dev ipx0201 198.18.2.2/24;
ip -6 addr add dev ipx0201 2001:db8:198:18:2::2/120;
4.3 – GRE over IPv4
Transporta pacotes de camada 3 de todos os tipos (IPv4, IPv6) sobre pacotes IPv4 com overhead total de 24 bytes (IPv4=20, GRE=4). MTU padrão 1476 bytes (infra 1500).
O cabeçalho de 4 bytes do GRE em IPv4 possui o campo opcional KEY (32 bits, 4 bilhões de túneis) que identifica o túnel, permitindo vários túneis usando os mesmos pares de IPs das pontas. Isso permite que dois túneis com KEYs diferentes participem de VRFs diferente, possuam custos de roteamento ou tratamento de QoS diferenciado, etc. A presença do KEY incrementa o overhead em 4 bytes, passando para 24 bytes (IPv4=20, GRE=8). MTU padrão 1472 bytes (infra 1500).
VPS 1:
# VPS 1 - GRE-TUN sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 1
ip link add gre0102 type gre local $VPS1v4 remote $VPS2v4 ttl 255 key 100;
ip link set up gre0102;
ip -4 addr add dev gre0102 198.18.3.1/24;
ip -6 addr add dev gre0102 2001:db8:198:18:3::1/120;
VPS 2:
# VPS 2 - GRE-TUN sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 2
ip link add gre0201 type gre local $VPS2v4 remote $VPS1v4 ttl 255 key 100;
ip link set up gre0201;
ip -4 addr add dev gre0201 198.18.3.2/24;
ip -6 addr add dev gre0201 2001:db8:198:18:3::2/120;
4.4 – GRE over IPv6
Transporta pacotes de camada 3 de todos os tipos (IPv4, IPv6) sobre pacotes IPv6 com overhead total de 52 bytes (IPv6=40, GRE=12). MTU padrão 1448 bytes (infra 1500).
Se o campo opcional KEY (32 bits, 4 bilhões de túneis) for informado, o overhead aumenta em 4 bytes, passando a 56 bytes e MTU de 1444 bytes (infra 1500).
VPS 1:
# VPS 1 - GRE-TUN sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 1
ip link add grx0102 type ip6gre local $VPS1v6 remote $VPS2v6 ttl 255 key 134;
ip link set up grx0102;
ip -4 addr add dev grx0102 198.18.4.1/24;
ip -6 addr add dev grx0102 2001:db8:198:18:4::1/120;
VPS 2:
# VPS 2 - GRE-TUN sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 2
ip link add grx0201 type ip6gre local $VPS2v6 remote $VPS1v6 ttl 255 key 134;
ip link set up grx0201;
ip -4 addr add dev grx0201 198.18.4.2/24;
ip -6 addr add dev grx0201 2001:db8:198:18:4::2/120;
4.5 – GRE-TAP over IPv4
Transporta pacotes de camada 2 sobre pacotes IPv4 com overhead total de 38 bytes (IPv4=20, GRE=4, ETH=14). MTU padrão 1462 bytes (infra 1500).
A presença do campo opcional KEY (32 bits, 4 bilhões de túneis) incrementa o overhead em 4 bytes passando para 42 bytes (IPv4=20, GRE=8, ETH=14). MTU padrão 1458 bytes (infra 1500). Com o KEY é possível criar vários túneis usando o mesmo par de IPs de base e cada túnel pode participar de bridges diferentes.
VPS 1:
# VPS 1 - GRE-TAP sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 1
ip link add gee0102 type gretap local $VPS1v4 remote $VPS2v4 ttl 255 key 350;
ip link set up gee0102;
ip -4 addr add dev gee0102 198.18.5.1/24;
ip -6 addr add dev gee0102 2001:db8:198:18:5::1/120;
VPS 2:
# VPS 2 - GRE-TAP sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 2
ip link add gee0201 type gretap local $VPS2v4 remote $VPS1v4 ttl 255 key 350;
ip link set up gee0201;
ip -4 addr add dev gee0201 198.18.5.2/24;
ip -6 addr add dev gee0201 2001:db8:198:18:5::2/120;
4.6 – GRE-TAP over IPv6
Transporta pacotes de camada 2 sobre pacotes IPv6 com overhead total de 66 bytes (IPv6=40, GRE=12, ETH=14). MTU padrão 1434 bytes (infra 1500).
A presença do campo opcional KEY (32 bits, 4 bilhões de túneis) incrementa o overhead em 4 bytes passando para 70 bytes (IPv6=40, GRE=16, ETH=14). MTU padrão 1430 bytes (infra 1500). Com o KEY é possível criar vários túneis usando o mesmo par de IPs de base e cada túnel pode participar de bridges diferentes.
VPS 1:
# VPS 1 - GRE-TAP sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 1
ip link add gex0102 type ip6gretap local $VPS1v6 remote $VPS2v6 ttl 255 key 9;
ip link set up gex0102;
ip -4 addr add dev gex0102 198.18.6.1/24;
ip -6 addr add dev gex0102 2001:db8:198:18:6::1/120;
VPS 2:
# VPS 2 - GRE-TAP sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 2
ip link add gex0201 type ip6gretap local $VPS2v6 remote $VPS1v6 ttl 255 key 9;
ip link set up gex0201;
ip -4 addr add dev gex0201 198.18.6.2/24;
ip -6 addr add dev gex0201 2001:db8:198:18:6::2/120;
4.7 – SIT over IPv4
O sit (Simple Internet Transition) implementa o mecanismo 6in4, que encapsula pacotes IPv6 dentro de pacotes IPv4 (código 41, 0x29). Ele também transporta IPv4 (código 4, 0x04).
O tunel sit opera exclusivamente com cabeçalho externo IPv4.
O sit possui um modo de transporte (mode) que pode controlar a capacidade de transporte do túnel:
- mode any: Transporta qualquer protocolo de camada 3;
- mode ipv6: Transporta apenas IPv6 (não suportado no Linux);
- mode ipip: Transporta apenas IPv4 (IPIP);
- mode mpls: Transporta apenas pacotes MPLS (não suportado no Linux);
O overhead total é de 20 bytes (IPv4=20), o MTU padrão é 1480 bytes (infra 1500).
VPS 1:
# VPS 1 - SIT IPv6 sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 1
ip link add sit0102 type sit local $VPS1v4 remote $VPS2v4 ttl 255 mode any;
ip link set up sit0102;
ip -4 addr add dev sit0102 198.18.7.1/24;
ip -6 addr add dev sit0102 2001:db8:198:18:7::1/120;
VPS 2:
# VPS 2 - SIT IPv6 sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 2
ip link add sit0201 type sit local $VPS2v4 remote $VPS1v4 ttl 255 mode any;
ip link set up sit0201;
ip -4 addr add dev sit0201 198.18.7.2/24;
ip -6 addr add dev sit0201 2001:db8:198:18:7::2/120;
5 – Túneis Ethernet ponto a ponto sobre UDP
Os túneis IP sobre UDP sem negociação de estado (stateless) são onipresentes, eles fazem o provimento de redes overlay rapidamente e suportam atravessar NAT.
Eles estão onipresentes em ambientes onde outros serviços de provisionamento fazem a configuração do túnel e entrega para as pontas (canal de controle SDN), que se apontarão uma para as outras.
5.1 – VXLAN Unicast – Ethernet over IPv4
O VXLAN de ponto-a-ponto unicast interliga as pontas (VTEPs) por IPs específicos e aparecem combinadas com bridges que entregam o hub-and-spoke para os hosts da rede virtual.
O overhead total é de 50 bytes (IPv4=20, UDP=8, VXLAN=8, ETH=14), o MTU na Internet é de 1450 bytes (infra 1500).
A interface VXLAN é iniciada com MTU de 1500 pois o foco não é transportar pela Internet e sim dentro do datacenter. Isso gera um problema de fragmentação (1500+50=1550, pacote 1 fragmento de 1500, pacote 2 fragmento de 70). É necessário definir o MTU de 1450 bytes na interface VXLAN manualmente.
VPS 1:
# VPS 1 - VXLAN Unicast sobre IPv4
VPS1v4="45.255.128.2";
VPS2v4="200.100.50.25";
#-------------------- VPS 1
DEV=vxl0102;
MTU=1450;
ip link add $DEV type vxlan local $VPS1v4 remote $VPS2v4 ttl 64 id 4004 dstport 4789;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.41.1/24;
ip -6 addr add dev $DEV 2001:db8:198:18:41::1/120;
VPS 2:
# VPS 2 - VXLAN Unicast sobre IPv4
VPS1_IPV4="45.255.128.2";
VPS2_IPV4="200.100.50.25";
#-------------------- VPS 2
DEV=vxl0201;
MTU=1450;
ip link add $DEV type vxlan local $VPS2v4 remote $VPS1v4 ttl 64 id 4004 dstport 4789;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.41.2/24;
ip -6 addr add dev $DEV 2001:db8:198:18:41::2/120;
5.2 – VXLAN Unicast – Ethernet over IPv6
Esse modo VXLAN Unicast sobre IPv6 tem overhead maior com total de 70 bytes (IPv6=40, UDP=8, VXLAN=8, ETH=14), o MTU na Internet é de 1430 bytes (infra 1500).
Ainda é necessário definir o MTU explicitamente.
VPS 1:
# VPS 1 - VXLAN Unicast sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 1
DEV=vxx0102;
MTU=1430;
ip link add $DEV type vxlan local $VPS1v6 remote $VPS2v6 ttl 64 id 4006 dstport 4789;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.42.1/24;
ip -6 addr add dev $DEV 2001:db8:198:18:42::1/120;
VPS 2:
# VPS 2 - VXLAN Unicast sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 2
DEV=vxx0201;
MTU=1430;
ip link add $DEV type vxlan local $VPS2v6 remote $VPS1v6 ttl 64 id 4006 dstport 4789;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.42.2/24;
ip -6 addr add dev $DEV 2001:db8:198:18:42::2/120;
5.3 – GENEVE Unicast – Ethernet over IPv4
Aqui temos uma novidade técnica: o GNV não se ancora em IP de origem, o foco dele é identificar o túnel pela porta UDP (padrão 6081) e pelo VNI (identificador da rede virtual).
O overhead total é de 50 bytes (IPv4=20, UDP=8, VXLAN=8, ETH=14), o MTU na Internet é de 1450 bytes (infra 1500).
O GNV suporta cabeçalhos em sequência para metadados que podem aumentar o overhead.
VPS 1:
# VPS 1 - GENEVE Unicast sobre IPv4
VPS1_IPV4="45.255.128.2";
VPS2_IPV4="200.100.50.25";
#-------------------- VPS 1
DEV=gnv0102;
MTU=1450;
ip link add $DEV type geneve id 8004 dstport 6081 remote $VPS2v4 ttl 64;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.43.1/24;
ip -6 addr add dev $DEV 2001:db8:198:18:43::1/120;
VPS 2:
# VPS 2 - GENEVE Unicast sobre IPv4
VPS1_IPV4="45.255.128.2";
VPS2_IPV4="200.100.50.25";
#-------------------- VPS 2
DEV=gnv0201;
MTU=1450;
ip link add $DEV type geneve id 8004 dstport 6081 remote $VPS1v4 ttl 64;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.43.2/24;
ip -6 addr add dev $DEV 2001:db8:198:18:43::2/120;
x
5.4 – GENEVE Unicast – Ethernet over IPv6
Ao usar GENEVE sobre IPv6 o overhead total é de 70 bytes (IPv6=40, UDP=8, VXLAN=8, ETH=14), o MTU na Internet é de 1430 bytes (infra 1500).
VPS 1:
# VPS 1 - GENEVE Unicast sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 1
DEV=gnx0102;
MTU=1430;
ip link add $DEV type geneve id 8006 dstport 6081 remote $VPS2v6;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.44.1/24;
ip -6 addr add dev $DEV 2001:db8:198:18:44::1/120;
VPS 2:
# VPS 2 - GENEVE Unicast sobre IPv6
VPS1v6="2804:cafe::2";
VPS2v6="2001:fada::25";
#-------------------- VPS 2
DEV=gnx0201;
MTU=1430;
ip link add $DEV type geneve id 8006 dstport 6081 remote $VPS1v6 ttl 64;
ip link set dev $DEV mtu $MTU;
ip link set up $DEV;
ip -4 addr add dev $DEV 198.18.44.2/24;
ip -6 addr add dev $DEV 2001:db8:198:18:44::2/120;
6 – Túneis Ethernet distribuidos por multicast
Quando um datacenter precisa conectar várias máquinas virtuais (VM, VPS) ou containers (OCI, Swarm, Kubernets) que se encontram espalhados por vários servidores.
Antigamente, a solução era criar um ambiente hub-and-spoke para concentrar os túneis unicast em uma bridge, ou pior, realizar um full-mesh entre todos os servidores com proteção anti-loop baseada em STP (spanning-tree protocol).
Uma abordagem moderna e pontual é usar um endereço IP de multicast como destino dos pacotes do túnel e deixar que a camada de rede resolver a entrega do pacote para vários destinatários registrados no grupo.
Fases:
- Cada rede virtual (VNI) usará um endereço IP de grupo multicast;
- Os servidores (VTEP) que desejarem participar da rede virtual devem ingressar no grupo multicast (IGMP JOIN):
- Rede L2: Switchs aprendem quais portas participam dos grupos;
- Redes L3: O roteamento multicast distribui os IPs dos grupos e os membros do grupo;
- Ao enviar um pacote IP contendo o payload VXLAN ou GENEVE para o endereço IP do grupo multicast, a rede L2 ou L3 entregará uma cópia do pacote para cada porta onde há um membro registrado.
Essa abstração multicast economiza o hub central e transforma a rede existente, seja os switchs ou a rede roteada em um switch virtual amorfo, sem um ponto central.
.
.
. (vxlan multicast over IPv4)
.
.
. (vxlan multicast over IPv6)
.
.
. (GENEVE multicast over IPv4)
.
. (GENEVE multicast over IPv6)
.
.
.
.GENERIC TUNNELS OVER UDP
.
.
WIREGUARD
.
.
OPENVPN
.
.
MAC SEC Point-to-Point
.
MAC SEC Multihost
.
.
IPSEC IPv4
.
IPSEC IPv6
.
.
“Os homens mais ricos são aqueles que possuem amigos mais poderosos.“
O Poderoso Chefão
Terminamos por hoje!
Patrick Brandão, patrickbrandao@gmail.com