Rezumat: cred că îmi lipsesc unele rute de pe serverul meu Ubuntu care se conectează la un VPN AWS cu Strongswan Ipsec. Ai idee ce rute am nevoie pe serverul meu?
Încerc să configurez un VPN direcționat BGP de la un server la AWS. Am avut lucrul acesta cu un VPN direcționat static, așa că știu că partea mea AWS și ipsec sunt corecte. Cu toate acestea, BGP se dovedește complicat.
Folosesc Strongswan pe Ubuntu ca parte „client”. Tunelurile mele ipsec sunt deschise (confirmat de starea ipsec și în consola AWS). Problema pare să fie că clientul meu BGP (frr) nu se poate conecta la procesul BGP din AWS (și invers).
Luând unul dintre cele două tuneluri, ip a arata asa:
5: tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN grup implicit qlen 1000
link/ipip 1.2.3.4 peer 2.3.4.5
inet 169.254.10.146 peer 169.254.10.145/30 domeniu global tunel1
valid_lft pentru totdeauna preferred_lft pentru totdeauna
Interfața este creată cu un script numit de Strongswan, care arată astfel:
tunel ip adăugați ${VTI_INTERFACE} local ${PLUTO_ME} la distanță ${PLUTO_PEER} cheie vti mod ${PLUTO_MARK_IN_ARR[0]}
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.disable_policy=1
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=2 || sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=0
adresă ip adăugați ${VTI_LOCALADDR} la distanță ${VTI_REMOTEADDR} dev ${VTI_INTERFACE}
link-ul IP a setat ${VTI_INTERFACE} în sus mtu ${MTU}
iptables -t mangle -I FORWARD -o ${VTI_INTERFACE} -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -I INPUT -p esp -s ${PLUTO_PEER} -d ${PLUTO_ME} -j MARK --set-xmark ${PLUTO_MARK_IN}
Am un traseu ca acesta:
169.254.10.144/30 dev tunnel1 proto kernel scope link src 169.254.10.146
Pot să-mi pun ping la capătul local (client) (169.254.10.146), dar ping la capătul de la distanță spune:
PING 169.254.10.145 (169.254.10.145) 56(84) octeți de date.
De la 169.254.10.146 icmp_seq=1 Gazdă destinație inaccesibilă
În ciuda faptului că spun că este inaccesibil, văd un pachet pe interfața tunelului, deși nu pare că acesta este de fapt trimis prin tunel către AWS (cel puțin, statisticile AWS Cloudwatch nu arată activitate suplimentară).
Unul dintre pașii de depanare BGP este să încercați să „telnet” la vecinul (169.254.10.145) pe portul 179 - dar acest lucru eșuează cu „nicio rută către găzduire”. În mod curios, pot vedea AWS încercând să se conecteze la clientul meu BGP în tcpdump pe interfața tunelului:
12:49:45.860899 IP 169.254.10.145.43731 > 169.254.10.146.179: Steaguri [S], seq 857645259, win 26880, opțiuni [mss 10.10.146.179, lungime 1370450, 5000000000, 50045259
12:49:45.860931 IP 169.254.10.146.179 > 169.254.10.145.43731: Flags [S.], seq 2284055933, ack 857645260, win 64249, options [mss 1379,sackOK,TS val 936428713 ecr 3261400514,nop,wscale 7 ], lungime 0
Se pare că serverul meu returnează un pachet ACK, dar conexiunea nu este niciodată stabilită. Dacă opresc serviciul BGP, începem să trimitem răspunsuri RST:
12:52:02.055473 IP 169.254.10.145.43679 > 169.254.10.146.179: Steaguri [S], seq 2280717367, win 26880, opțiuni [mss 10.146.179, 3OK 138705 val, 3OK 138705 val, 3OK 138705 val, 3 OK
12:52:02.055498 IP 169.254.10.146.179 > 169.254.10.145.43679: Flags [R.], secv 0, ack 1, win 0, length 0
Din aceasta presupunerea mea este că pachetul ACK al nucleului și pachetul meu ping merg pe interfața tunelului, dar nu intră de fapt în ipsec sau în AWS.
Se pare atunci că am nevoie de câteva rute suplimentare, dar nu îmi pot da seama ce ar putea fi necesar. Mi se pare că am totul la locul lor. M-am uitat la nenumărate exemple și instrucțiuni, dar puține arată ceva ce nu am și și mai puțini confirmă că am nevoie de rutele de care cred că am nevoie sau de ce rute sunt necesare pentru ca BGP să funcționeze. Orice ajutor este mult apreciat.
