AWS Site-to-Site VPN: väline, sisemine ja LAN-prefiks

Ühel AWS VPN-il aetakse segi kolm aadressirolli: välised partnerid, sisemine /30 lüli ja kaitstud LAN-prefiksid. Lugege need alla laaditud konfiguratsioonist.

Enamik AWS Site-to-Site VPN-i vigu on aadressivead ja need tehakse enne, kui ükski pakett liigub. Tunneli välisaadressid jõuavad IPsec-partneriteni, siseaadressid moodustavad nendevahelise marsruutimislüli ja kaitstud prefiksid on selle lüli mõte. Kopeeri üks roll teise ja tunnel tõuseb, samal ajal kui miski ei marsruutu. Siin on lugemis-kontrollimis-seadistamise jada, mida ma kasutan BGP kliendi lüüsil, kusjuures väärtused on võetud alla laaditud seadme konfiguratsioonist, mitte mälust.

Kolm aadressirolli, üks tunnel

Välisaadressid on avalikud ja kuuluvad IPsec-partneritele: üks tunneli kohta AWS-i poolel, ja kliendi lüüsi kättesaadav identiteet teie poolel, kohandatud selle NAT-lahendusega, mis teil tegelikult on. Siseaadressid on privaatsed ja kuuluvad loogilisele lülile, mille AWS dokumenteerib kui /30, mis on võetud vahemikust 169.254.0.0/16. Kaitstud prefiksid on VPC, kohalikud või transiitvõrgud, mida te selle lüli kaudu marsruudite ja teavitate.

LAN-prefiksi määramine tunneli liidese aadressiks on selle vea klassikaline versioon. Liides näib seadistatud, LAN-i ei teavitata ja vastaspoolel pole selle jaoks marsruuti. Tunnel võib isegi läbida oma sisemise pingi, samal ajal kui iga rakenduse nimi aegub. Tunneli valikute viide loetleb sisemise CIDR-i piirangud, sealhulgas aadressivahemiku, millest see peab pärinema.

Lugege väärtused alla laaditud konfiguratsioonist

Laadige konfiguratsioon oma konkreetse seadmemudeli jaoks ühendusest alla ja käsitlege selle aadressitabelit tõe allikana. Konsool näitab samu väärtusi tunneli kohta: väline IP, sisemine CIDR ja BGP-partneri aadress AWS-i poolel. Kaks tunnelit on eraldi objektid eraldi väliste lõpp-punktide ja eraldi sisemiste /30-dega, kuigi mõlemad kannavad samu kaitstud võrke.

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]'

Kui alla laaditud fail ja reaalajas konsool lahknevad, on fail aegunud. Laadige see uuesti alla, selle asemel et aadresse käsitsi muuta, sest sisemise paari ja partneri seadistatud naabri lahknevus on vaikne BGP tõrge.

Ehitage lüli õige aadressiga

Linuxi lüüsil on tunnel VTI või XFRM liides ja sisemine /30 läheb sellele liidesele. Kaks tunnelit tähendavad kahte liidest ja kahte BGP-naabrit, üks AWS-i lõpp-punkti kohta. Konventsioon, mille AWS allalaaditud seadme konfiguratsiooni trükib, paneb virtuaalse privaatse lüüsi iga sisemise /30 esimesele aadressile ja teie kliendi lüüsi teisele, nii et te võtate kõrgema aadressi ja peerite madalamaga. Miski siin ei vaja LAN-aadressi.

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

Kui teie seadmemudeli fail trükib vastupidise paari, kasutage selle numbreid ja hoidke reeglist kinni: liidese aadress on teie oma, partneri aadress kuulub AWS-ile. Vastupidi tehes saate tunneli, mis ei jõua kunagi olekusse Established, sest seadistatud naaber on aadress, mida teie enda liides juba hoiab.

Hoidke märgis ja VTI võti kooskõlas sellega, mida IKE-deemon kasutab alam-SA liidesega sidumiseks, muidu saabub liiklus tunnelisse ilma liideseta, kuhu maanduda. Kontrollige MTU-d tee ja IKE-deemoni enda seadete vastu, selle asemel et kopeerida number teisest saidist.

Kontrollige BGP-d enne marsruutide kontrollimist

IPsec-i tõusmine tõestab, et partnerid leppisid kokku turvaassotsiatsioonis, ja mitte midagi muud. BGP sessioon on eraldi läbirääkimine sisemise lüli kaudu, seega lugege naabri olekut ja prefiksite loendureid ning võrrelge neid sellega, mida kavatsesite teavitada.

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'

Olek Established ja null saadud prefiksit on poliitika või teavitamise probleem, mitte tunneli probleem. Korrake kogu kontrolli teisel tunnelil; töötav esimene tunnel ütleb, et aadressid on usutavad, mitte et teine tunnel oleks üldse seadistatud.

Jälgige marsruuditud paketti ja siis lõpetage

Kui sessioon kannab prefikse, testige marsruuti mõlemas suunas lüüsilt: lähteaadress, järgmine hüpe ja turbepoliitika, mis liiklust lubab. BGP sessioon võib olla üleval, samal ajal kui konkreetne prefiks, mida teie rakendus vajab, on filtreeritud, kokku võetud või suunatud vale liidese peale.

Reachability Analyzer on AWS-i poole tööriist, mis võtab allika, sihtkoha ja tee ning teatab, milline komponent toetatud konfiguratsioonis selle blokeeris. Kasutage seda tee testimiseks VPC-st teie kliendi lüüsi aadressini, mitte rakenduse hostist. See analüüsib konfiguratsiooni ega saada paketti läbi kohaliku tulemüüri, seega hoidke selle otsus eraldi teie enda liidese loenduritest ja paketipüüdistest.

Kirjutage iga tunneli väline paar, sisemine /30 ja teavitatud prefiksid ühte tabelisse. Just see tabel muudab järgmise muudatuse ülevaatatavaks.

Seotud artiklid