AWS Site-to-Site VPN: bûten, binnen en it LAN-prefiks

Trije adresrollen reitsje trochinoar op ien AWS VPN: bûtenpeers, de binnenste /30-ferbining en de beskerme LAN-prefiksen. Lês se yn ’e deladen konfiguraasje.

De measte flaters by AWS Site-to-Site VPN binne adresflaters, en se wurde makke foardat der ea in pakket beweecht. De bûtenadressen fan de tunnel berikke de IPsec-peers, de binnenadressen foarmje de routing-ferbining tusken har, en de beskerme prefiksen binne dêr’t dy ferbining foar is. Kopiearje ien rol yn in oare en de tunnel komt omheech wylst neat rûtelet. Hjir is de folchoarder lês-kontrolearje-konfigurearje dy’t ik op in BGP-klantpoarte brûk, mei de wearden út ’e deladen apparaatkonfiguraasje yn stee fan út it ûnthâld.

Trije adresrollen, ien tunnel

De bûtenadressen binne iepenbier en hearre by de IPsec-peers: ien per tunnel oan de AWS-kant, en de berikbere identiteit fan ’e klantpoarte oan jo kant, oanpast oan hokker NAT-regeling jo eins hawwe. De binnenadressen binne privee en hearre by de logyske ferbining, dy’t AWS dokumintearret as in /30 lutsen út 169.254.0.0/16. De beskerme prefiksen binne de VPC-, lokale of transitnetwurken dy’t jo oer dy ferbining rûtele en advertearje.

In LAN-prefiks as adres fan ’e tunnelinterface tawize is de klassike ferzje fan dizze flater. De interface liket konfigurearre, de LAN wurdt net advertearre, en de oare kant hat gjin rûte derfoar. De tunnel kin sels syn eigen binnenste ping helje wylst elke applikaasjenamme op tiid útrint. De referinsje foar tunnelopsjes listet de beheiningen fan it binnenste CIDR op, wêrûnder it adresberik dêr’t it út komme moat.

Lês de wearden út de deladen konfiguraasje

Download de konfiguraasje foar jo spesifike apparaatmodel fan ’e ferbining en behannelje de adrestabel as de boarne fan wierheid. De konsôle toant deselde wearden per tunnel: bûten-IP, binnen-CIDR en it BGP-peeradres oan ’e AWS-kant. De twa tunnels binne aparte objekten mei aparte bûteneinpunten en aparte binnenste /30, ek al drage beide deselde beskerme netwurken.

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 it deladen bestân en de live-konsôle net oerienkomme, is it bestân ferâldere. Download opnij ynstee fan adressen mei de hân te bewurkjen, want in mismatch tusken it binnenpear en de konfigurearre buorman fan ’e peer is in stille BGP-flater.

Bou de ferbining mei it goede adres derop

Op in Linux-poarte is de tunnel in VTI- of XFRM-interface, en it binnenste /30 giet op dy interface. Twa tunnels betsjutte twa interfaces en twa BGP-buorlju, ien per AWS-einpunt. De konvinsje dy’t AWS yn ’e deladen apparaatkonfiguraasje printsjelet, set de firtuele partikuliere poarte op it earste adres fan elk binnenste /30 en jo klantpoarte op it twadde, dus jo nimme it hegere adres en peerje mei it legere. Neat hjir hat in LAN-adres nedich.

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 it bestân foar jo apparaatmodel it tsjinoerstelde pear printsjelet, brûk dan syn sifers en hâld de regel: it adres op ’e interface is fan jo, it peeradres heart by AWS. Dat oarsom dwaan jout in tunnel dy’t nea Established berikt, om’t de buorman dy’t jo konfigurearre hawwe it adres is dat jo eigen interface al hat.

Hâld de mark en de VTI-kaai lyk mei wat de IKE-daemon brûkt om in bern-SA oan ’e interface te binen, oars komt ferkear op ’e tunnel oan sûnder interface om op te lânjen. Kontrolearje de MTU tsjin it paad en tsjin ’e eigen ynstellings fan ’e IKE-daemon ynstee fan in sifer fan in oar plak te kopiearjen.

Kontrolearje BGP foardat jo rûtes kontrolearje

Dat IPsec omheech komt bewiist dat de peers it iens binne oer in feiligensassosjaasje en neat oars. De BGP-sesje is in aparte ûnderhanneling oer de binnenferbining, dus lês de buormanstatus en de prefikstelders, en fergelykje se dêrnei mei wat jo fan doel wiene te advertearjen.

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'

Steat Established mei nul ûntfongen prefiksen is in belied- of advertinsjeprobleem, gjin tunnelprobleem. Werhelje de hiele kontrôle op ’e twadde tunnel; in wurkjende earste tunnel fertelt jo dat de adressen leauwich binne, net dat de twadde tunnel oait konfigurearre is.

Folgje in rûtele pakket en stop dan

Sadree’t de sesje de prefiksen draacht, test de rûte yn beide rjochtingen fan ’e poarte: boarneadres, folgjende hop en it feiligensbelied dat it ferkear tasteat. In BGP-sesje kin omheech wêze wylst it konkrete prefiks dat jo applikaasje nedich hat, filtere, gearfette of nei de ferkearde interface wiisd is.

Reachability Analyzer is it helpmiddel oan ’e AWS-kant dat in boarne, in bestimming en in paad nimt, en rapportearret hokker komponint yn in stipe konfiguraasje it blokkearre. Brûk it om it paad fan ’e VPC nei it adres fan jo klantpoarte te testen, net fan in applikaasjehost ôf. It analysearret konfiguraasje en stjoert gjin pakket troch in lokale firewall, dus hâld syn oardiel apart fan jo eigen interfacetelders en pakketopnames.

Skriuw it bûtenpear, it binnenste /30 en de advertearre prefiksen foar elke tunnel yn ien tabel. Dy tabel is wat de folgjende feroaring kontrolearber makket.

Relatearre artikelen