AWS Site-to-Site VPN: ekstere, interne kaj la LAN-prefikso

Plej multaj eraroj ĉe AWS Site-to-Site VPN estas adresaj eraroj, kaj ili fariĝas antaŭ ol eĉ unu pako moviĝas. La eksteraj adresoj de la tunelo atingas la IPsec-parojn, la internaj adresoj formas la enkursigan ligilon inter ili, kaj la protektitaj prefiksoj estas tio, por kio tiu ligilo ekzistas. Kopiu unu rolon en alian kaj la tunelo leviĝas dum nenio enkursiĝas. Jen la sinsekvo legi-kontroli-agordi, kiun mi uzas sur BGP-klienta pordego, kun la valoroj prenitaj el la elŝutita aparata agordo, ne el memoro.

Tri adresaj roloj, unu tunelo

La eksteraj adresoj estas publikaj kaj apartenas al la IPsec-paroj: unu por tunelo ĉe la AWS-flanko, kaj la atingebla identeco de la klienta pordego ĉe via flanko, adaptita al kia ajn NAT-aranĝo vi efektive havas. La internaj adresoj estas privataj kaj apartenas al la logika ligilo, kiun AWS dokumentas kiel /30 prenitan el 169.254.0.0/16. La protektitaj prefiksoj estas la VPC-, surlokaj aŭ transitaj retoj, kiujn vi enkursigas kaj anoncas tra tiu ligilo.

Doni LAN-prefikson kiel adreson de la tunela interfaco estas la klasika versio de ĉi tiu eraro. La interfaco aspektas agordita, la LAN ne estas anoncata, kaj la kontraŭa flanko havas neniun itineron por ĝi. La tunelo eĉ povas trapasi sian propran internan ping dum ĉiu aplikaĵa nomo tempas for. La referenco pri tunelaj opcioj listigas la limigojn de la interna CIDR, inkluzive de la adresaro, el kiu ĝi devas veni.

Legu la valorojn el la elŝutita agordo

Elŝutu la agordon por via specifa aparata modelo el la konekto, poste traktu ĝian adresan tabelon kiel fonton de vero. La konzolo montras la samajn valorojn por tunelo: ekstera IP, interna CIDR, kaj la BGP-paro-adreso ĉe la AWS-flanko. La du tuneloj estas apartaj objektoj kun apartaj eksteraj finpunktoj kaj apartaj internaj /30, kvankam ambaŭ portas la samajn protektitajn retojn.

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

Se la elŝutita dosiero kaj la viva konzolo malkonsentas, la dosiero estas kaduka. Elŝutu denove anstataŭ redakti adresojn permane, ĉar malkongruo inter la interna paro kaj la agordita najbaro de la paro estas silenta BGP-fiasko.

Konstruu la ligilon kun la ĝusta adreso sur ĝi

Sur Linux-pordego la tunelo estas VTI aŭ XFRM-interfaco, kaj la interna /30 iras sur tiun interfacon. Du tuneloj signifas du interfacojn kaj du BGP-najbarojn, unu por ĉiu AWS-finpunkto. La konvencio, kiun AWS presas en la elŝutita aparata agordo, metas la virtualan privatan pordegon sur la unuan adreson de ĉiu interna /30 kaj vian klientan pordegon sur la duan, do vi prenas la pli altan adreson kaj parigas kun la pli malalta. Nenio ĉi tie bezonas LAN-adreson.

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

Se la dosiero por via aparata modelo presas la kontraŭan paron, uzu ĝiajn nombrojn kaj konservu la regulon: la adreso sur la interfaco estas via, la paro-adreso apartenas al AWS. Fari tion malrekte produktas tunelon, kiu neniam atingas Established, ĉar la najbaro, kiun vi agordis, estas la adreso, kiun via propra interfaco jam tenas.

Tenu la markon kaj la VTI-ŝlosilon kongruaj kun tio, kion la IKE-demono uzas por ligi infanan SA al la interfaco, alie trafiko alvenas sur la tunelon sen interfaco sur kiun eki. Kontrolu la MTU kontraŭ la vojo kaj kontraŭ la propraj agordoj de la IKE-demono anstataŭ kopii nombron el alia loko.

Kontrolu BGP antaŭ ol kontroli itinerojn

Tio, ke IPsec leviĝas, pruvas ke la paroj konsentas pri sekureca asocio kaj nenion alian. La BGP-saluto estas aparta intertraktado super la interna ligilo, do legu la najbaran staton kaj la prefiksajn nombrilojn, poste komparu ilin kun tio, kion vi intencis anonci.

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'

Stato Established kun nula ricevitaj prefiksoj estas politika aŭ anonca problemo, ne tunela problemo. Ripetu la tutan kontrolon sur la dua tunelo; funkcianta unua tunelo diras al vi, ke la adresoj estas kredindaj, ne ke la dua tunelo entute agordiĝis.

Sekvu enkursigitan pakon, poste haltu

Post kiam la saluto portas la prefiksojn, testu la itineron en ambaŭ direktojn de la pordego: fonta adreso, sekva salto, kaj la sekureca politiko, kiu permesas la trafikon. BGP-saluto povas esti supre dum la specifa prefikso, kiun via aplikaĵo bezonas, estas filtrita, resumita for, aŭ direktita al la malĝusta interfaco.

Reachability Analyzer estas la ilo ĉe la AWS-flanko, kiu prenas fonton, celon kaj vojon, kaj raportas, kiu komponanto en subtenata agordo blokis ĝin. Uzu ĝin por testi la vojon de la VPC al via klienta pordega adreso, ne de aplikaĵa gastiganto. Ĝi analizas agordon kaj ne sendas pakon tra surloka fajroŝirmilo, do tenu ĝian verdikton aparte de viaj propraj interfacaj nombriloj kaj pakaj kaptaĵoj.

Notu la eksteran paron, la internan /30 kaj la anoncitajn prefiksojn por ĉiu tunelo en unu tabelo. Tiu tabelo estas tio, kio faras la sekvan ŝanĝon revizebla.