Estou tendo problemas para configurar uma VPN entre o escritório e o AWS VPC. Os "túneis" parecem estar ativos, mas não sei se estão configurados corretamente.
O dispositivo que estou usando é um firewall VPN Netgear - FVS336GV2
Se você vê na configuração anexada baixada da VPC (# 3 Tunnel Interface Configuration), ela me fornece alguns endereços "internos" para o túnel. Ao configurar os túneis IPsec, eu uso os IPs do túnel interno (por exemplo, 169.254.254.2/30) ou uso minha sub-rede de rede interna (10.1.1.0/24)
Eu tentei os dois, quando tentei a rede local (10.1.1.x) o tracert pára no roteador. Quando eu tentei com o "inside" ips, o tracert para o amazon VPC (10.0.0.x) sai pela internet.
tudo isso me leva à próxima pergunta, para esse roteador, como configuro o estágio nº 4, o próximo salto estático?
Quais são esses endereços "internos" aparentemente aleatórios e de onde a amazon os gerou? 169.254.254.x parece estranho?
Com um dispositivo como esse, a VPN está por trás do firewall?
Eu modifiquei os endereços IP abaixo para que eles não sejam "reais". Tenho plena consciência de que isso provavelmente está mal formulado. Por favor, se houver mais informações / screenshots que ajudarão, me avise.
AmazonWebServicesVirtualPrivateCloudIPSecTunnel#1================================================================================#1:InternetKeyExchangeConfigurationConfiguretheIKESAasfollows-AuthenticationMethod:Pre-SharedKey-Pre-SharedKey:----AuthenticationAlgorithm:sha1-EncryptionAlgorithm:aes-128-cbc-Lifetime:28800seconds-Phase1NegotiationMode:main-PerfectForwardSecrecy:Diffie-HellmanGroup2#2:IPSecConfigurationConfiguretheIPSecSAasfollows:-Protocol:esp-AuthenticationAlgorithm:hmac-sha1-96-EncryptionAlgorithm:aes-128-cbc-Lifetime:3600seconds-Mode:tunnel-PerfectForwardSecrecy:Diffie-HellmanGroup2IPSecDeadPeerDetection(DPD)willbeenabledontheAWSEndpoint.WerecommendconfiguringDPDonyourendpointasfollows:-DPDInterval:10-DPDRetries:3IPSecESP(EncapsulatingSecurityPayload)insertsadditionalheaderstotransmitpackets.Theseheadersrequireadditionalspace,whichreducestheamountofspaceavailabletotransmitapplicationdata.Tolimittheimpactofthisbehavior,werecommendthefollowingconfigurationonyourCustomerGateway:-TCPMSSAdjustment:1387bytes-ClearDon'tFragmentBit:enabled-Fragmentation:Beforeencryption#3:TunnelInterfaceConfigurationYourCustomerGatewaymustbeconfiguredwithatunnelinterfacethatisassociatedwiththeIPSectunnel.AlltraffictransmittedtothetunnelinterfaceisencryptedandtransmittedtotheVirtualPrivateGateway.TheCustomerGatewayandVirtualPrivateGatewayeachhavetwoaddressesthatrelatetothisIPSectunnel.Eachcontainsanoutsideaddress,uponwhichencryptedtrafficisexchanged.Eachalsocontainaninsideaddressassociatedwiththetunnelinterface.TheCustomerGatewayoutsideIPaddresswasprovidedwhentheCustomerGatewaywascreated.ChangingtheIPaddressrequiresthecreationofanewCustomerGateway.TheCustomerGatewayinsideIPaddressshouldbeconfiguredonyourtunnelinterface.OutsideIPAddresses:-CustomerGateway:217.33.22.33-VirtualPrivateGateway:87.222.33.42InsideIPAddresses-CustomerGateway:169.254.254.2/30-VirtualPrivateGateway:169.254.254.1/30Configureyourtunneltofragmentattheoptimalsize:-TunnelinterfaceMTU:1436bytes#4:StaticRoutingConfiguration:ToroutetrafficbetweenyourinternalnetworkandyourVPC,youwillneedastaticrouteaddedtoyourrouter.StaticRouteConfigurationOptions:-Nexthop:169.254.254.1YoushouldaddstaticroutestowardsyourinternalnetworkontheVGW.TheVGWwillthensendtraffictowardsyourinternalnetworkoverthetunnels.IPSecTunnel#2================================================================================#1:InternetKeyExchangeConfigurationConfiguretheIKESAasfollows-AuthenticationMethod:Pre-SharedKey-Pre-SharedKey:----AuthenticationAlgorithm:sha1-EncryptionAlgorithm:aes-128-cbc-Lifetime:28800seconds-Phase1NegotiationMode:main-PerfectForwardSecrecy:Diffie-HellmanGroup2#2:IPSecConfigurationConfiguretheIPSecSAasfollows:-Protocol:esp-AuthenticationAlgorithm:hmac-sha1-96-EncryptionAlgorithm:aes-128-cbc-Lifetime:3600seconds-Mode:tunnel-PerfectForwardSecrecy:Diffie-HellmanGroup2IPSecDeadPeerDetection(DPD)willbeenabledontheAWSEndpoint.WerecommendconfiguringDPDonyourendpointasfollows:-DPDInterval:10-DPDRetries:3IPSecESP(EncapsulatingSecurityPayload)insertsadditionalheaderstotransmitpackets.Theseheadersrequireadditionalspace,whichreducestheamountofspaceavailabletotransmitapplicationdata.Tolimittheimpactofthisbehavior,werecommendthefollowingconfigurationonyourCustomerGateway:-TCPMSSAdjustment:1387bytes-ClearDon'tFragmentBit:enabled-Fragmentation:Beforeencryption#3:TunnelInterfaceConfigurationOutsideIPAddresses:-CustomerGateway:217.33.22.33-VirtualPrivateGateway:87.222.33.46InsideIPAddresses-CustomerGateway:169.254.254.6/30-VirtualPrivateGateway:169.254.254.5/30Configureyourtunneltofragmentattheoptimalsize:-TunnelinterfaceMTU:1436bytes#4:StaticRoutingConfiguration:StaticRouteConfigurationOptions:-Nexthop:169.254.254.5YoushouldaddstaticroutestowardsyourinternalnetworkontheVGW.TheVGWwillthensendtraffictowardsyourinternalnetworkoverthetunnels.Depoisdeescreverestepost,continueiamexerealgocomeçouafuncionar,nãomuitoconfiável.OsIPslocaisparausaraoconfigurarostúneisondedefatominhassub-redes.OquemaismeconfundesobreoquesãoessesendereçosIP"internos".
O problema é que os resultados não são consistentes. Eu posso "às vezes" ping, eu posso "às vezes" RDP usando a VPN. Às vezes, o túnel 1 ou o túnel 2 pode estar ativo ou inativo.
Quando voltei ao trabalho hoje, o Túnel 1 estava inativo, então o excluí e o recriou do zero. Agora eu não consigo pingar nada, mas a Amazon E o roteador estão me dizendo túnel 1/2 estão bem.
Eu acho que o hardware do roteador / vpn que eu acabei de deixar para o trabalho .....
Agora, o túnel 1 está ativo, o túnel 2 está desativado (não alterei nenhuma configuração) e posso fazer ping / rdp novamente.
Captura de tela da tabela de roteamento que o roteador construiu. Estado atual (o túnel 1 ainda está ativo e em sequência, 2 ainda está inativo e não se reconectará)
Não tenho certeza, mas não acho que você possa fazer isso com esse dispositivo. O Guia de Rede do AWS VPC exige que o seu Portal do Cliente seja configurado com um tela de túnel que está associada ao túnel IPSec e não vejo essa opção em Manual do Netgear .
Editar: você pode tentar as seguintes configurações: (VPN / IPSec VPN / VPN Wizard)
Gateway,
ConnectionName,
<preshared_key>
Remote WAN: 87.222.33.42
Local WAN: 217.33.22.33
Remote LAN: 10.0.0.0
Remote Subnet mask: 255.255.252.0
Eu não acho que seja um problema que apenas um túnel funcione de cada vez. Isso é por design; O AWS mantém um túnel inoperante e só o conecta se o outro túnel falhar. Veja este texto da documentação do Windows na AWS.
"We suggest that you configure both tunnels as part of the VPN connection. Each tunnel connects to a separate VPN concentrator on the Amazon side of the VPN connection. Although only one tunnel at a time is up, the second tunnel automatically establishes itself if the first tunnel goes down. Having redundant tunnels ensure continuous availability in the case of a device failure. Because only one tunnel is available at a time, the AWS Management Console displays a yellow icon indicating that one tunnel is down. This is expected behavior, so there's no action required from you."
Eu tenho o mesmo drama conectando você usando um roteador Cisco / Linksys IPsec. Esse roteador funciona bem com vários outros sistemas IPsec aos quais ele se conecta, como o Cisco ASA, Vyatta e StrongSwan, mas o Amazon AWS VPN tem esse problema interno de IP. Para dispositivos 'genéricos', ele diz para você usar essa numeração interna, mas para outras plataformas, como Cisco e Windows, não faz menção à numeração interna. Só funciona se ignorar a numeração interna e configurar minha sub-rede e a sub-rede VPC. Mas então não há como fazer essa rota estática, e o túnel só funciona da AWS para mim, e não na outra direção.
Geralmente, acho muito mais fácil configurar o StrongSwan em um t1.micro que é usar o AWS VPN.