AWS Site-to-Site VPN: buite, binne en die LAN-prefiks

Drie adresrolle word op een AWS VPN verwar: buite-eweknieë, die /30 binne-skakel en die beskermde LAN-prefikse. Lees hulle uit die afgelaaide konfigurasie.

Die meeste foute met AWS Site-to-Site VPN is adresfoute, en hulle word gemaak voordat enige pakkie beweeg. Die tonnel se buite-adresse bereik die IPsec-eweknieë, die binne-adresse vorm die roeteringskakel tussen hulle, en die beskermde prefikse is waarvoor daardie skakel dien. Kopieer een rol in ’n ander en die tonnel kom op terwyl niks roeteer nie. Hier is die lees-kontroleer-konfigureer-volgorde wat ek op ’n BGP-kliëntpoort gebruik, met die waardes uit die afgelaaide toestelkonfigurasie eerder as uit die geheue.

Drie adresrolle, een tonnel

Die buite-adresse is publiek en behoort aan die IPsec-eweknieë: een per tonnel aan die AWS-kant, en die kliëntpoort se bereikbare identiteit aan jou kant, aangepas vir watter NAT-reëling jy ook al het. Die binne-adresse is privaat en behoort aan die logiese skakel, wat AWS dokumenteer as ’n /30 uit 169.254.0.0/16. Die beskermde prefikse is die VPC-, perseel- of deurvoernetwerke wat jy oor daardie skakel roeteer en adverteer.

Om ’n LAN-prefiks as die tonnelkoppelvlak se adres toe te wys, is die klassieke weergawe van hierdie fout. Die koppelvlak lyk gekonfigureer, die LAN word nie geadverteer nie, en die ander kant het geen roete daarvoor nie. Die tonnel kan selfs sy eie binne-ping slaag terwyl elke toepassingsnaam tyd uitloop. Die verwysing vir tonnelopsies lys die binne-CIDR-beperkings, insluitend die adresreeks waaruit dit moet kom.

Lees die waardes uit die afgelaai konfigurasie

Laai die konfigurasie vir jou spesifieke toestelmodel vanaf die verbinding af en behandel sy adrestabel as die bron van waarheid. Die konsole wys dieselfde waardes per tonnel: buite-IP, binne-CIDR en die BGP-eweknie-adres aan die AWS-kant. Die twee tonnels is aparte objekte met aparte buite-eindpunte en aparte binne-/30s, al dra albei dieselfde beskermde netwerke.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

As die afgelaaide lêer en die lewendige konsole verskil, is die lêer verouderd. Laai weer af eerder as om adresse met die hand te wysig, want ’n wanverhouding tussen die binne-paar en die eweknie se gekonfigureerde buur is ’n stil BGP-faling.

Bou die skakel met die regte adres daarop

Op ’n Linux-poort is die tonnel ’n VTI- of XFRM-koppelvlak, en die binne-/30 gaan op daardie koppelvlak. Twee tonnels beteken twee koppelvlakke en twee BGP-bure, een per AWS-eindpunt. Die konvensie wat AWS in die afgelaaide toestelkonfigurasie druk, plaas die virtuele privaatpoort op die eerste adres van elke binne-/30 en jou kliëntpoort op die tweede, so jy neem die hoër adres en peer met die laer een. Niks hier het ’n LAN-adres nodig nie.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

As die lêer vir jou toestelmodel die teenoorgestelde paring druk, gebruik sy nommers en hou by die reël: die adres op die koppelvlak is joune, die eweknie-adres behoort aan AWS. Om dit omgekeerd te doen lewer ’n tonnel wat nooit Established bereik nie, want die buur wat jy gekonfigureer het, is die adres wat jou eie koppelvlak al hou.

Hou die mark en die VTI-sleutel in lyn met wat die IKE-daemon gebruik om ’n kind-SA aan die koppelvlak te bind, anders kom verkeer op die tonnel aan sonder ’n koppelvlak om op te land. Kontroleer die MTU teen die pad en teen die IKE-daemon se eie instellings eerder as om ’n nommer van ’n ander werf te kopieer.

Verifieer BGP voordat jy roetes verifieer

Dat IPsec opkom, bewys die eweknieë stem oor ’n sekuriteitsassosiasie en niks anders nie. Die BGP-sessie is ’n aparte onderhandeling oor die binne-skakel, so lees die buurtoestand en die prefikstekkers en vergelyk dit met wat jy bedoel het om te adverteer.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Toestand Established met nul prefikse ontvang is ’n beleid- of advertensieprobleem, nie ’n tonnelprobleem nie. Herhaal die hele kontrole op die tweede tonnel; ’n werkende tonnel een sê vir jou die adresse is aanneemlik, nie dat tonnel twee hoegenaamd gekonfigureer is nie.

Volg ’n geroteerde pakkie en stop dan

Sodra die sessie die prefikse dra, toets die roete in albei rigtings vanaf die poort: bronadres, volgende sprong en die sekuriteitsbeleid wat die verkeer toelaat. ’n BGP-sessie kan op wees terwyl die spesifieke prefiks wat jou toepassing nodig het, gefiltreer, weggesommeer of na die verkeerde koppelvlak gepunt word.

Reachability Analyzer is die AWS-kant-gereedskap wat ’n bron, ’n bestemming en ’n pad neem en rapporteer watter komponent in ’n ondersteunde konfigurasie dit geblokkeer het. Gebruik dit om die pad van die VPC na jou kliëntpoort-adres te toets, nie vanaf ’n toepassingsgasheer nie. Dit ontleed konfigurasie en stuur nie ’n pakkie deur ’n perseel-firewall nie, so hou sy uitspraak apart van jou eie koppelvlak-tellers en pakkie-opnames.

Teken die buite-paar, die binne-/30 en die geadverteerde prefikse vir elke tonnel in een tabel aan. Dit is die tabel wat die volgende verandering hersienbaar maak.

Verwante artikels