Documente Academic
Documente Profesional
Documente Cultură
com)
No post a seguir, vamos simular um cenário onde é possível fecharmos um vpn site to site, e um túnel
GRE, isolando essa conectividade em uma tabela de roteamento customizada (inet.0).
A idéia aqui não é trafegar GRE por dentro de um IPSEC, mas sim implementar dois protocolos de
tunelamento independentes um do outro em um mesmo equipamento (no caso do SRX), usando uma
tabela de roteamento diferente da padrão (também SRX) e usando dois fabricantes distintos (Juniper
SRX e Router CISCO).
E vamos “viajar” em uma necessidade de usarmos o GRE, IPSEC e uma instancia de roteamento. A idéia
não é demonstrar um “desenho de rede incrível e máster blaster”, mas mostrar o funcionamento dos
dois protocolos de tunelamento + a customização de rotas em uma tabela de roteamento virtual;
!!!INTERFACE LOOPBACK QUE SERÁ USADA COMO SOURCE IP ADDRESS DOS PACOTES GRE´S!!!
interface Loopback20
ip address 2.2.2.1 255.255.255.255
!
interface Tunnel20
ip address 172.16.0.2 255.255.255.0
tunnel source Loopback20 LOOPBACK CONFIGURADA NO ROTEADOR
tunnel destination 1.1.1.1 LOOPBACK CONFIGURADA NO SRX
!
interface FastEthernet0/0 INTERFACE WAN
ip address 200.200.200.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.20 INTERFACE LAN
encapsulation dot1Q 20
ip address 10.20.20.1 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 200.200.200.1 ROTA PARA ALCANÇAR A LOOPBACK REMOTA. REPARE
QUE O NEXT-HOP É O “LINK WAN”###
ip route 10.10.10.0 255.255.255.0 172.16.0.1 ROTA PARA ALCANÇAR A LAN-10 REMOTA ATRAVÉS DO
TUNEL GRE. REPARE QUE O NEXT-HOP É O IP DA INTERFACE TUNEL REMOTO###
ip route 10.30.30.0 255.255.255.0 172.16.0.1 ROTA PARA ALCANÇAR A LAN-30 REMOTA ATRAVÉS DO
TUNEL GRE. REPARE QUE O NEXT-HOP É O IP DA INTERFACE TUNEL REMOTO ###
###INTERFACE GRE###
set interfaces gr-0/0/0 unit 10 tunnel source 1.1.1.1
set interfaces gr-0/0/0 unit 10 tunnel destination 2.2.2.1 ip DA LOOPBACK 20 DO ROUTER LAN-20
set interfaces gr-0/0/0 unit 10 family inet address 172.16.0.1/24
###CONFIGURAÇÃO DE ZONAS###
set security zones security-zone Trust interfaces ge-0/0/1.10
set security zones security-zone Untrust host-inbound-traffic system-services ping
set security zones security-zone Untrust interfaces lo0.10 ###REPARE QUE A INTERFACE LOOPBACK
FICA VINCULADA A ZONA QUE CONECTA A WAN. NO NOSSO CASO É A ZONA UNTRUST###
set security zones security-zone Untrust interfaces ge-0/0/0.0
set security zones security-zone GRE-TO-RT-CISCO host-inbound-traffic system-services ping
set security zones security-zone GRE-TO-RT-CISCO interfaces gr-0/0/0.10
set security zones security-zone INTERNET host-inbound-traffic system-services ike
set security zones security-zone INTERNET host-inbound-traffic system-services ping
set security zones security-zone INTERNET interfaces ge-0/0/2.0
set security zones security-zone VPN-TO-LAN-30 interfaces st0.10
###CONFIGURAÇÃO DE INSTANCIA DE ROTEAMENTO. REPARE QUE O TUNEL GRE E A INTERFACE TUNEL USADA PELO
TUNEL IPSEC ESTÃO ASSOCIADAS A ESSA INSTANCIA DE ROTEAMENTO. A INTERFACE LOOPBACK E A INTERFACE
QUE É O PEER IPSEC VPN NÃO ESTÃO NESSA INSTANCIA DE ROTEAMENTO###
set routing-instances lab-1 instance-type virtual-router
set routing-instances lab-1 interface gr-0/0/0.10
set routing-instances lab-1 interface ge-0/0/1.10
set routing-instances lab-1 interface st0.10
set routing-instances lab-1 routing-options static route 10.20.20.0/24 next-hop gr-0/0/0.10
set routing-instances lab-1 routing-options static route 0.0.0.0/0 next-table inet.0
###CRIAÇÃO DE POLITICAS DE ROTEAMENTO ONDE NÓS DETERMINAMOS QUE APENAS O RANGE 10.10.10.0/24 QUE
ESTÁ NA INSTANCIA lab-1 DEVE SER ACEITA. LOGO ABAIXO VEREMOS PORQUE CRIAMOS ESSA POLITICA E QUAL
O EFEITO###
set policy-options policy-statement FROM-INSTANCE-LAB term 10 from instance lab-1
set policy-options policy-statement FROM-INSTANCE-LAB term 10 from route-filter 10.10.10.0/24
exact
set policy-options policy-statement FROM-INSTANCE-LAB term 10 then accept
set policy-options policy-statement FROM-INSTANCE-LAB term 20 then reject
###POLITICA DE ROTEAMENTO NEGANDO QUALQUER OUTRA ROTA DE QUALQUER OUTRA INSTANCIA DE ROTEAMENTO
CUSTOMIZADA###
set policy-options policy-statement REJECT term 10 then reject
###APLICAÇÃO DE FILTRO DE ROTAS PARA QUE A TABELA DE ROTEAMENTO PADRÃO CONHEÇA A REDE LAN-10. A
POLICY CRIADA ACIMA SERÁ USADA PARA COMPARTILHAR A ROTA DA REDE 10.10.10.0/24 COM A TABELA DE
ROTEAMENTO PADRÃO (inet.0)###
set routing-options instance-import FROM-INSTANCE-LAB
set routing-options instance-import REJECT
###POLITICA IKE###
set security ike policy IKE-POLICY-IBM mode main
set security ike policy IKE-POLICY-IBM proposals IKE-AES-256-CBC-SHA1-DH2-PSK
set security ike policy IKE-POLICY-IBM pre-shared-key ascii-text "$9$.mT36/t0OR5QF/AtIRNdVsoJDik"
###DEFINIÇÃO DE GATEWAY VPN ASSOCIANDO A INTERFACE DE INTERNET, QUE PERTENCE A TABELA DE
ROTEAMENTO inet.0, VEMOS TAMBÉM POLITICA DE FASE I, E ENDEREÇO IP DO PEER REMOTO###
set security ike gateway GW-LAB ike-policy IKE-POLICY-IBM
set security ike gateway GW-LAB address 22.22.22.2
set security ike gateway GW-LAB external-interface ge-0/0/2.0
###ASSOCIANDO TODOS OS PARAMETROS DE VPN DESCRITOS ACIMA DENTRO DE UMA CONFIGURAÇÃO DE VPN###
set security ipsec vpn VPN-LAB bind-interface st0.10
set security ipsec vpn VPN-LAB ike gateway GW-LAB
set security ipsec vpn VPN-LAB ike ipsec-policy IPSEC-POL-AES-CBC-SHA1-96
set security ipsec vpn VPN-LAB traffic-selector LAB-1-10 local-ip 10.10.10.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-10 remote-ip 10.30.30.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-20 local-ip 10.20.20.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-20 remote-ip 10.30.30.0/24
set security ipsec vpn VPN-LAB establish-tunnels immediately
RT-LAN-20#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/106/132 ms
3- OK, validamos o túnel GRE, agora vamos validar a conectividade entre as duas vlans (vlan 20
Vlan 10). No PC que está na vlan 10, ip 10.10.10.110, eu vou fazer um telnet na porta 3389
do ip 10.20.20.220:
4- Agora vamos analisar o SRX, e a tabela de sessão que ele criou para essa sessão:
root# run show security flow session protocol tcp
Session ID: 184620, Policy name: FROM-LAN-10-TO-LAN-20/5, Timeout: 1794, Valid
In: 10.10.10.110/49163 --> 10.20.20.220/3389;tcp, If: ge-0/0/1.10, Pkts: 2, Bytes: 88
Out: 10.20.20.220/3389 --> 10.10.10.110/49163;tcp, If: gr-0/0/0.10, Pkts: 1, Bytes: 48
Total sessions: 1
Conforme acima, podemos ver que o trafego de entrada chega pelo Tunel GRE interface gr-
0/0/0.10 e o trafego de retorno volta pela interface ge-0/0/1.10.
Ok, túnel GRE está validado. Evidencias estatísticas podem ser obtidas através da verificação de
contadores de interface.
O túnel gre é uma interface lógica, mas o JUNOS considera essa interface como qualquer outra, então,
vamos analisar o que os comandos de verificação de interface podem nos oferecer:
Cabeçalho do pacote gre, repare que ele possui o ip das loopbacks e protocol number 47. Ou
seja na rede WAN, o cabeçalho dos pacotes que irão trafegar possuem apenas os ips 1.1.1.1/32
e 2.2.2.1/32 como source/destination;
Encapsulamento;
Contadores de INPUT e OUTPUT;
MTU.
Não que as outras informações sejam irrelevantes, na verdade o que “julga” a informação relevante ou
não, é a sua necessidade e o que você está verificando.
Agora, vamos verificar o túnel IPSEC e a comunicação que passa por ele:
Ou:
No roteador Cisco:
Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
22.22.22.2 11.11.11.2 QM_IDLE 1018 0 ACTIVE
OU:
Router#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
Funcionou!!! Se funcionou quer dizer que o túnel está 100% estabelecido. Mas, mesmo assim,
seguem abaixo comandos que comprovam isso:
Observe que este comando traz como informação, peer local, remote peer, o nome da vpn,
traffic selector, ou seja, o trafego que precisa ser tunelado e foi definido na config de vpn e
muito mais informação.
interface: FastEthernet0/0
Crypto map tag: LAB, local addr 22.22.22.2
inbound ah sas:
outbound ah sas:
inbound ah sas:
outbound ah sas:
outbound pcp sas:
Voltando ao SRX, para verificar se o túnel vpn está incrementando trafego bidirecional, use o
comando abaixo:
root> show interfaces st0.10
Logical interface st0.10 (Index 71) (SNMP ifIndex 512)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 269
Output packets: 317
Security: Zone: VPN-TO-LAN-30
Protocol inet, MTU: 9192
Flags: Sendbcast-pkt-to-re
Lembre-se que, a interface st0.10, também é uma interface como qualquer outra e o JUNOS
mostrará estatísticas de pacotes entrando e saindo dessa interface.
Já sabemos que está tudo funcionando no nosso laboratório, mas apenas para entendermos
como o JUNOS vai rotear o trafego, vamos analisar a tabela de roteamento customizada (lab-1)
que nós criamos:
root> show route table lab-1.inet.0
Vamos testar o acesso da vlan-10 á “internet”, lembre-se que o RT-LAN-30 possui uma loopback
com ip 8.8.8.8. Então, vamos fechar um telnet nesse ip, na porta 80, e ver como a sessão é
criada no firewall:
No próximo post vou usar basicamente o mesmo cenário, mas irei exemplificar o uso de
roteamento de origem em tabelas de roteamento customizada, para alcançar um determinado
ip.
Até mais,
João Victor