Trebuia să configurez un VPN de la site la site între serverele A și B, unde serverul A este gestionat de mine și serverul B este administrat de un client.
Serverul A rulează Ubuntu 20.04 și folosesc strongswan pentru a configura VPN-ul din partea mea. Folosesc UFW pentru a gestiona firewall-ul serverului A.
Adresa IP publică a lui A: 16.XX.XXX.17
Adresa IP publică a lui B: 14.XXX.XXX.94
Acum, după ce am făcut modificările de configurare necesare pentru configurarea VPN-ului și l-am pornit, pot vedea următoarele loguri /var/log/syslog
Mar 21 13:58:47 worker0 charon: 01[ENC] analizat răspunsul IKE_AUTH 1 [ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr ]
21 mar 13:58:47 worker0 charon: 01[IKE] autentificare pentru „14.XXX.XXX.94” cu cheie pre-partajată reușită
Mar 21 13:58:47 worker0 charon: 01[IKE] IKE_SA s-to-s[1] stabilit între 16.XX.XXX.17[16.XX.XXX.17]...14.XXX.XXX. 94[14.XXX.XXX.94]
21 mar 13:58:47 worker0 charon: 01[IKE] programând reautentificare în 2644s
21 mar 13:58:47 worker0 charon: 01[IKE] durata maximă de viață IKE_SA 3184s
21 mar 13:58:47 worker0 charon: 01[IKE] a primit ESP_TFC_PADDING_NOT_SUPPORTED, nu folosește umplutura ESPv3 TFC
Mar 21 13:58:47 worker0 charon: 01[CFG] propunere selectată: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Mar 21 13:58:47 worker0 charon: 01[IKE] CHILD_SA s-to-s{1} stabilit cu SPI-uri c97fea32_i f60175ca_o și TS 10.132.86.142/32 === 10.128.27.9.
21 mar 13:58:53 worker0 charon: 14[NET] pachet primit: de la 14.XXX.XXX.94[4500] la 16.XX.XXX.17[4500] (80 de octeți)
Mar 21 13:58:53 worker0 charon: 14[ENC] analizat cerere INFORMAȚIONALĂ 0 [ ]
Mar 21 13:58:53 worker0 charon: 14[ENC] generează răspuns INFORMAȚIONAL 0 [ ]
21 mar 13:58:53 worker0 charon: 14[NET] trimitere pachet: de la 16.XX.XXX.17[4500] la 14.XXX.XXX.94[4500] (80 de octeți)
21 mar 13:58:58 worker0 charon: 07[NET] pachet primit: de la 14.XXX.XXX.94[4500] la 16.XX.XXX.17[4500] (80 de octeți)
Mar 21 13:58:58 worker0 charon: 07[ENC] parsed INFORMATIONAL request 1 [ ]
21 mar 13:58:58 worker0 charon: 07[ENC] generează răspuns INFORMAȚIONAL 1 [ ]
21 mar 13:58:58 worker0 charon: 07[NET] trimitere pachet: de la 16.XX.XXX.17[4500] la 14.XXX.XXX.94[4500] (80 de octeți)
21 mar 13:59:03 worker0 charon: 05[NET] pachet primit: de la 14.XXX.XXX.94[4500] la 16.XX.XXX.17[4500] (80 de octeți)
Ieșire din starea ipsec:
Asociații de securitate (1 în sus, 0 conexiuni):
s-to-s[1]: INSTALAT acum 5 minute, 16.XX.XXX.17[16.XX.XXX.17]...14.XXX.XXX.94[14.XXX.XXX.94]
s-to-s{1}: INSTALLED, TUNNEL, reqid 1, ESP SPI-uri: c97fea32_i f60175ca_o
s-to-s{1}: 10.132.86.142/32 === 10.128.28.96/27
The starea ufw
Stare: activ
La Acțiune De la
-- ------ ----
666 LIMIT Oriunde # Pentru ssh
62626 ALLOW Oriunde # Pentru wireguard
Oriunde pe pv0 ALLOW Oriunde
666 (v6) LIMIT Oriunde (v6) # Pentru ssh
62626 (v6) ALLOW Oriunde (v6) # Pentru wireguard
Oriunde (v6) pe pv0 ALLOW Oriunde (v6)
Cum poate serverul să primească pachete pe portul 4500 (în conformitate cu logurile ipsec? /var/log/syslog) fără să deschid portul ăla? Ce îmi lipsește aici?
Nu am atins deloc tabelele IP direct.
Am verificat rulând un server http simplu pe portul 8000 (folosind python3 -m http.server) că nu pot accesa alte porturi nedeschise din afara serverului)
