Strongswan
Strongswan é uma solução de VPN baseada em IPSec de código-fonte aberto. A maioria das distribuições do Linux inclui o Libreswan ou facilita a instalação dele. Você pode instalá-lo nos hosts em uma rede local ou uma rede do provedor de nuvem.
Este tópico fornece a configuração do CPE que executa o Strongswan. A ramificação Strongswan 5.x suporta os protocolos de intercâmbio de chaves IKEv1 e IKEv2 com a pilha NETKEY IPSec nativa do kernel do Linux.
A Oracle fornece instruções de configuração para um conjunto testado de fornecedores e dispositivos. Use a configuração correta para o fornecedor e a versão do software.
Se a versão do dispositivo ou do software que a Oracle usou para verificar se a configuração não corresponde exatamente ao dispositivo ou ao software, você ainda poderá criar a configuração necessária no dispositivo. Consulte a documentação do fornecedor e faça as alterações necessárias.
Se o dispositivo for de um fornecedor que não está na lista de fornecedores e dispositivos verificados ou se você já estiver familiarizado com a configuração do dispositivo para IPSec, consulte a lista de parâmetros IPSec suportados e consulte a documentação do fornecedor para obter ajuda.
O Oracle Cloud Infrastructure oferece VPN Site a Site, uma conexão IPSec segura entre uma rede on-premises e uma VCN (Virtual Cloud Network).
O diagrama a seguir mostra uma conexão IPSec básica com o Oracle Cloud Infrastructure que tem túneis redundantes. Os endereços IP usados neste diagrama são apenas exemplos.
Melhores Práticas
Esta seção trata das melhores práticas gerais e de considerações para o uso da VPN Site a Site.
Configurar Todos os Túneis para Todas as Conexões IPSec
A Oracle implanta dois headends IPSec para conexões a fim de fornecer alta disponibilidade para cargas de trabalho de missão crítica. No lado Oracle, esses dois headends estão em roteadores distintos para fins de redundância. Recomendamos a configuração de todos os túneis disponíveis para redundância máxima. Essa é uma parte essencial da filosofia "Design para Falhas".
Ter CPEs Redundantes nas Redes Locais
Recomendamos que cada site que se conecta ao IPSec com o Oracle Cloud Infrastructure tenha dispositivos de borda redundantes (também conhecidos como CPE (customer-premises equipment)). Você adiciona cada CPE à Console do Oracle e cria uma conexão IPSec separada entre um DRG (dynamic routing gateway) e cada CPE. Para cada conexão IPSec, o sistema Oracle provisiona dois túneis em headends IPSec redundantes geograficamente. Para obter mais informações, consulte o Guia de redundância de conectividade (PDF).
Considerações sobre o Protocolo de Roteamento
Quando você cria uma conexão IPSec da VPN Site a Site, ela tem dois túneis IPSec redundantes. A Oracle incentiva você a configurar o CPE para usar ambos os túneis (se o CPE o suportar). Anteriormente, a Oracle criava conexões IPSec com até quatro túneis IPSec.
Os seguintes três tipos de roteamento estão disponíveis e você seleciona o tipo de roteamento separadamente para cada túnel na VPN Site a Site:
- Roteamento dinâmico BGP: as rotas disponíveis são obtidas dinamicamente por meio de BGP. O DRG obtém dinamicamente as rotas provenientes da rede local. No lado Oracle, o DRG propaga as sub-redes da VCN.
- roteamento estático: ao configurar a conexão IPSec com o DRG, você especifica para a rede local as rotas específicas que a VCN deverá saber. Você também deve configurar o dispositivo CPE com rotas estáticas para as sub-redes da VCN. Essas rotas não são aprendidas dinamicamente.
- roteamento baseado em política: ao configurar a conexão IPSec com o DRG, você especifica para a rede local as rotas específicas que a VCN deverá saber. Você também deve configurar o dispositivo CPE com rotas estáticas para as sub-redes da VCN. Essas rotas não são aprendidas dinamicamente.
Para obter mais informações sobre roteamento com a VPN Site a Site, incluindo recomendações da Oracle sobre como manipular o algoritmo de seleção de melhor caminho do BGP, consulte Roteamento da VPN Site a Site.
Outras Configurações Importantes do CPE
Verifique se as listas de acesso do CPE estão configuradas corretamente para não bloquear o tráfego necessário de origem ou destino do Oracle Cloud Infrastructure.
Se houver vários túneis ativos simultaneamente, você poderá experimentar um roteamento assimétrico. Para levar em conta o roteamento assimétrico, certifique-se de que o CPE esteja configurado para tratar o tráfego proveniente da VCN em qualquer um dos túneis. Por exemplo, você precisa desativar a inspeção do ICMP e configurar o bypass de estado do TCP. Para obter mais detalhes sobre a configuração apropriada, entre em contato com o suporte do fornecedor do CPE. Para configurar o roteamento para ser simétrico, consulte Encaminhamento da VPN Site a Site.
Cuidados e Limitações
Esta seção trata de características e limitações gerais importantes da VPN Site a Site que você esteja ciente. Consulte Limites de Serviço para obter uma lista de limites e instruções aplicáveis a uma solicitação de aumento de limite.
Roteamento Assimétrico
O Oracle usa o roteamento assimétrico entre os túneis que compõem a conexão IPSec. Configure firewalls com isso em mente. Caso contrário, os testes de ping ou o tráfego de aplicativos na conexão não funcionarão de forma confiável.
Quando você usa vários túneis para o Oracle Cloud Infrastructure, Recomendamos que você configure o roteamento para rotear deterministicamente o tráfego pelo túnel preferido. Para usar um túnel IPSec como principal e outro como backup, configure rotas mais específicas para o túnel principal (BGP) e rotas menos específicas (rota padrão ou resumida) para o túnel de backup (BGP/estático). Caso contrário, se você propagar a mesma rota (por exemplo, uma rota padrão) por meio de todos os túneis, o tráfego de retorno de uma VCN para uma rede on-premises será roteado para qualquer um dos túneis disponíveis. Isso acontece porque o sistema Oracle usa roteamento assimétrico.
Para obter recomendações específicas de roteamento da Oracle sobre como impor o roteamento simétrico, consulte Roteamento da VPN Site a Site.
VPN Site a Site Baseada em Rota ou em Política
O protocolo IPSec usa SAs (Security Associations) para decidir como criptografar pacotes. Dentro de cada SA, você define domínios de criptografia para mapear o tipo de protocolo e o endereço IP de origem e de destino de um protocolo até uma entrada no banco de dados SA, a fim de definir como criptografar ou decriptografar um pacote.
Outros fornecedores e a documentação utilizada no setor podem usar os termos ID do proxy, índice de parâmetro de segurança (SPI) ou seletor de tráfego ao fazer referência a SAs ou domínios de criptografia.
Há dois métodos gerais para implementar túneis IPSec:
- Túneis baseados em rota: também chamados de túneis baseados no próximo salto. Uma pesquisa de tabela de roteamento é executada no endereço IP de destino de um pacote. Se a interface de saída da rota for um túnel IPSec, o pacote será criptografado e enviado para a outra extremidade do túnel.
- Túneis baseados em política: o protocolo e o endereço IP de origem e de destino do pacote são validados em relação a uma lista de instruções de política. Se não houver uma correspondência, o pacote será criptografado com base nas regras dessa instrução de política.
Os cabeçalhos da VPN Site a Site da Oracle usam túneis baseados em rota, mas podem funcionar com túneis baseados em política, com algumas limitações listadas nas seções a seguir.
Se o CPE estiver por trás de um dispositivo NAT
Em geral, o identificador IKE de CPE configurado na extremidade local da conexão deve corresponder ao identificador IKE de CPE que o sistema Oracle está usando. Por padrão, o sistema Oracle usa o endereço IP público do CPE, que você fornece ao criar o objeto CPE na Console do sistema Oracle. No entanto, se um CPE estiver atrás de um dispositivo NAT, o identificador IKE do CPE configurado na extremidade local poderá ser o endereço IP privado do CPE, conforme mostrado no diagrama a seguir.
Algumas plataformas CPE não permitem que você altere o identificador IKE local. Se não puder alterar, altere o ID de IKE remoto na Console do sistema Oracle para corresponder ao ID de IKE local do CPE. Você pode fornecer o valor quando configurar a conexão IPSec ou posteriormente, editando a conexão IPSec. O sistema Oracle espera que o valor seja um endereço IP ou um nome de domínio totalmente qualificado (FQDN), como cpe.example.com. Para obter instruções, consulte Alterando o Identificador IKE do CPE Usado pelo Sistema Oracle.
Parâmetros IPSec Suportados
Para obter uma lista não dependente de fornecedor contendo parâmetros IPSec suportados para todas as regiões, consulte Parâmetros IPSec Suportados.
O ASN do BGP da Oracle para o realm do Cloud do setor governamental é 31898. Se você estiver configurando a VPN Site-to-Site para a Nuvem do Governo dos EUA, consulte Parâmetros Obrigatórios da VPN Site-to-Site para a Nuvem do Governo e também ASN de BGP da Oracle. Para o Cloud do Governo do Reino Unido, consulte Regiões.
Configuração do CPE
As instruções de configuração nesta seção são fornecidas pelo Oracle Cloud Infrastructure para este CPE. Se você precisar de suporte ou ajuda adicional, entre em contato diretamente com o suporte do fornecedor do CPE.
A figura a seguir mostra o layout básico da conexão IPSec.
Arquivo de Configuração Padrão do Strongswan
A instalação padrão do Strongswan cria os seguintes arquivos:
etc/strongswan/ipsec.conf: A raiz da configuração do Strongswan./etc/strongswan/ipsec.secrets: A raiz do local onde o Strongswan procura segredos (as chaves pré-instaladas do túnel).
O arquivo padrão etc/strongswan/ipsec.conf inclui esta linha:
Include /etc/strongswan/*.confO arquivo padrão etc/strongswan/ipsec.secrets inclui esta linha:
include /etc/strongswan/ipsec.d/*.secretsAs linhas anteriores mesclam automaticamente todos os arquivos .conf e .secrets do diretório /etc/strongswan na configuração principal e os arquivos de segredos que o Strongswan utiliza.
Sobre a Utilização do IKEv2
O sistema Oracle suporta o Internet Key Exchange versão 1 (IKEv1) e versão 2 (IKEv2). Se você configurar a conexão IPSec na Console para usar IKEv2, deverá configurar o CPE para usar somente IKEv2 e os parâmetros relacionados de criptografia IKEv2 suportados pelo CPE. Para obter uma lista de parâmetros que o Oracle suporta para IKEv1 ou IKEv2, consulte Parâmetros IPSec Suportados.
Especifique a versão do IKE ao definir o arquivo de configuração IPSec na tarefa 3 da seção a seguir. Nesse arquivo de exemplo, um comentário mostra como configurar IKEv1 ou IKEv2.
Processo de Configuração
O processo de configuração a seguir discute como um túnel baseado em rota é configurado no Strongswan. Os headends da Oracle VPN usam túneis baseados em rota. Recomendamos que você configure Strongswan com a sintaxe da configuração Virtual Tunnel Interface (VTI).
Para obter detalhes sobre os parâmetros específicos usados neste documento, consulte Parâmetros IPSec Suportados.
Dependendo da distribuição do Linux que você está usando, talvez seja necessário ativar o encaminhamento de IP na interface para permitir que os clientes enviem e recebam tráfego por meio do Strongswan. No arquivo /etc/sysctl.conf, defina os valores a seguir e aplique as atualizações com sudo sysctl -p.
Se você estiver usando uma interface que não seja eth0, altere o eth0 no exemplo a seguir para a interface (linhas 5 e 7).
Se você estiver usando diversas interfaces, configure as linhas 5 e 7 para essa interface também.
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens3.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.ens3.accept_redirects = 0
A configuração do Strongswan usa as variáveis a seguir. Decida os valores antes de continuar com a configuração.
${cpeLocalIP}: O endereço IP do dispositivo Strongswan.${cpePublicIpAddress}: O endereço IP público para Strongswan, também o endereço IP da interface externa. Dependendo da topologia da rede, o valor poderá ser diferente da${cpeLocalIP}.${oracleHeadend1}: Para o primeiro túnel, o ponto final IP público Oracle obtido da Console do sistema Oracle.${oracleHeadend2}: Para o segundo túnel, o ponto final IP público Oracle obtido da Console do sistema Oracle.${sharedSecret1}: a chave pré-compartilhada para o primeiro túnel. Você pode usar a chaves pré-compartilhadas fornecidas pela Oracle padrão ou fornecer uma quando configurar a conexão IPSec na Console da Oracle.${sharedSecret2}: a chave pré-compartilhada para o segundo túnel. Você pode usar a chaves pré-compartilhadas fornecidas pela Oracle padrão ou fornecer uma quando configurar a conexão IPSec na Console da Oracle.${vcnCidrNetwork}: o intervalo de IP da VCN.
A configuração Strongswan usa o conceito de esquerda e direita para definir os parâmetros de configuração para o dispositivo CPE local e o gateway remoto. Qualquer lado da conexão (a conexão na configuração Strongswan) pode ser à esquerda ou à direita, mas a configuração dessa conexão deve ser consistente. Nesse exemplo:
- esquerda: o CPE local do Strongswan
- direita: o headend da Oracle VPN
Use o modelo a seguir para o arquivo /etc/strongswan/ipsec.conf. O arquivo define os dois túneis que o sistema Oracle cria quando você configura a conexão IPSec.
Se o CPE estiver atrás de um dispositivo NAT um para um, remova o comentário do parâmetro leftid e defina-o como igual ao ${cpePublicIpAddress}.
# basic configuration
config setup
conn %default
ikelifetime=28800s
keylife=3600s
rekeymargin=3m
keyingtries=%forever
mobike=no
ike=aes256-sha2_384-ecp384!
esp=aes256gcm16-modp1536!
conn oci-tunnel-1
left=${cpeLocalIP}
#leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend1}
rightid=${oracleHeadend1}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=13 # Needs to be unique across all tunnels
conn oci-tunnel-2
left={cpeLocalIP}
#leftid=${cpePublicIpAddress}
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend2}
rightid=${oracleHeadend2}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=14 # Needs to be unique across all tunnels
Instruções como ike= e esp= podem ser alteradas para parâmetros específicos com base nos Parâmetros IPSec Suportados.
Use o modelo a seguir para o arquivo /etc/strongswan/ipsec.secrets . Ele contém duas linhas por conexão IPSec (uma linha por túnel).
${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"
O comando a seguir cria uma interface VTI com o nome definido e a vincula ao túnel usando IPs locais e remotos.
ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <mark><name>pode ser qualquer nome de dispositivo válido (ipsec0, vti0 etc.). O comando ip trata os nomes que começam comvticomo especiais em algumas instâncias (como ao recuperar estatísticas do dispositivo). Os endereços IP são os pontos finais do túnel IPSec. Um IP privado pode ser usado quando a CPE está atrás de um dispositivo NAT.-
<mark>deve corresponder à marca configurada para a conexão.
Depois de criar a VTI, ela deve ser ativada (use ip link set <name> up) e você pode instalar rotas e usar protocolos de roteamento conforme mostrado no exemplo a seguir.
ip tunnel add vti1 mode vti local 10.0.3.78 remote 193.123.68.187 key 13
ip link set vti1 upA instalação da rota pelo daemon IKE deve ser desativada. Para fazer isso, altere charon.conf conforme mostrado.
Directory - /etc/strongswan/strongswan.d/Charon.conf
#Uncomment below statement
install_routes = no
Depois de configurar os arquivos da configuração e segredos, reinicie o serviço Strongswan. Use o seguinte comando:
Strongswan restart
A reinicialização do serviço Strongswan pode afetar os túneis existentes.
Use o seguinte comando ip para criar rotas estáticas que enviem tráfego para uma VCN por meio dos túneis IPSec. Se você estiver acessando uma conta de usuário sem privilégio, talvez seja necessário usar o sudo antes do comando.
As rotas estáticas criadas com o comando de rota de ip não persistem por meio de uma reinicialização. Para saber como tornar as rotas persistentes, consulte a documentação da distribuição Linux de sua escolha.
ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show
Verificação
O serviço Monitoring também está disponível no Oracle Cloud Infrastructure para monitorar de forma ativa e passiva os recursos de nuvem. Para obter informações sobre o monitoramento de uma VPN Site a Site, consulte Métricas da VPN Site a Site.
Se você tiver problemas, consulte Diagnóstico e Solução de Problemas da VPN Site a Site.
Você também pode ativar o registro em log do OCI para obter acesso aos logs da VPN.
Verificando o Status da Interface do Túnel
Verifique o estado atual dos túneis Strongswan usando o comando a seguir.
strongswan statusSe a saída retornada for semelhante ao exemplo a seguir, o túnel será estabelecido.
oci-tunnel-1[591]: ESTABLISHED 43 minutes ago, 10.0.3.78[129.148.216.212]...193.123.68.187[193.123.68.187]
oci-tunnel-1{399}: INSTALLED, TUNNEL, reqid 102, ESP in UDP SPIs: ce6a1525_i 4829c65c_o
oci-tunnel-1{399}: 0.0.0.0/0 === 0.0.0.0/0
No futuro, se você precisar abrir um ticket de suporte com a Oracle sobre o túnel Strongswan, inclua a saída completa do comando strongswan status.
Verificando o Status da Interface do Túnel
Verifique se as interfaces do túnel virtual estão ativas ou inativas usando o comando ifconfig ou o comando ip link show. Também é possível usar aplicativos, como o tcpdump, com as interfaces.
Este é um exemplo da saída ifconfig com uma implementação do Strongswan em funcionamento que mostra as VTIs disponíveis.
ifconfig
<output trimmed>
vti1: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 10.10.10.1 netmask 255.255.255.252 destination 10.10.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 69209 bytes 4050022 (3.8 MiB)
RX errors 54 dropped 54 overruns 0 frame 0
TX packets 50453 bytes 3084997 (2.9 MiB)
TX errors 1016 dropped 0 overruns 0 carrier 1016 collisions 0
vti2: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 192.168.10.1 netmask 255.255.255.252 destination 192.168.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 101256 bytes 6494872 (6.1 MiB)
RX errors 12 dropped 12 overruns 0 frame 0
TX packets 70023 bytes 4443597 (4.2 MiB)
TX errors 2142 dropped 0 overruns 0 carrier 2142 collisions 0
Este é um exemplo da saída do comando ip link show:
ip link show
<output trimmed>
vti2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 139.185.34.172
14: vti1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 193.123.68.187
Configurar o Roteamento Dinâmico com o Strongswan
Recomendamos o uso do quagga para configurar o BGP. Para instalar quagga, use o seguinte comando Oracle Linux (se você está usando uma distribuição Linux diferente, os comandos podem variar um pouco):
sudo yum -y install quaggaAltere a configuração do zebra (/etc/quagga/zebra.conf) para definir o endereço IP da VTI, que é obrigatório porque o BGP usa pareamento. Defina as seguintes variáveis para o zebra:
${vti_name1}: O nome da primeira VTI usada. Por exemplo, vti1.${vti_name2}: O nome da segunda VTI usada. Por exemplo, vti2.${vti_ipaddress1}: O endereço IP alocado para a primeira VTI usada.${vti_ipaddress2}: O endereço IP alocado para a segunda VTI usada.${local_subnet}: A sub-rede do CPE local.
Essas variáveis são usadas no seguinte trecho do arquivo de configuração:
!
hostname strongswan-centos
log file /var/log/quagga/quagga.log
!
interface ens3
ipv6 nd suppress-ra
!
interface ens5
ipv6 nd suppress-ra
!
interface lo
!
interface <Vti_name1>
ip address ${vti_ipaddress1}
ipv6 nd suppress-ra
!
interface <Vti_name2>
ip address ${vti_ipaddress2}
ipv6 nd suppress-ra
!
ip route ${local_subnet} <Vti_name1>
ip route ${local_subnet} <Vti_name2>
!
ip forwarding
!
!
line vty
!
O arquivo de configuração bgpd também é obrigatório para a configuração do BGP. Defina as seguintes variáveis para o bgpd:
${LOCAL_ASN}: O ASN BGP da rede on-premises.${router-id_ipaddress}: O ID do BGP da rede local.${local_subnet}: A sub-rede local que precisa ser propagada.${bgp_peer-ip _network}: O CIDR /30 da rede IP de pareamento no OCI.${neighbor_peer_ip_address}: O endereço IP de pareamento de BGP do OCI.
Essas variáveis são usadas no seguinte trecho do arquivo de configuração de /etc/quagga/bgpd.conf:
hostname <host-name>
router bgp ${LOCAL_ASN}
bgp router-id ${router-id_ipaddress}
network ${bgp_peer-ip _network}
network ${bgp_peer-ip _network}
network ${local_subnet}
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
log file bgpd.log
log stdout
A ativação do Strongswan para usar rotas e IPs virtuais exige alterações no /etc/strongswan/strongswan.d/Charon.conf.
Remova o comentário das linhas que leem #install_routes = yes e #install_virtual_ip = yes e altere os valores para "no", conforme mostrado:
#Tunnels
install_routes = no
#Install virtual IP addresses.
install_virtual_ip = no
Use os seguintes comandos para ativar e iniciar o serviço para zebra e BGPD:
systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd