Puncte:1

Nu se poate stabili o conexiune VPN s2s între AWS EC2 și OVH Public Cloud folosind WireGuard

drapel gb

Nu pot stabili o conexiune VPN între instanța AWS EC2 și OVH Public Cloud. În /var/log/syslog nu există erori - doar câteva informații despre wg-rapid operațiuni precum adăugarea de rutare etc.

Instanță AWS EC2:

  • OS: Ubuntu 20.04.2 LTS

  • Adresă IP internă: ex. 10.0.22.22/16 ens4

  • Adresă IP publică: ex. 123.123.123.123/32 aws interfață publică

  • Port 12345/udp și 12345/tcp deschis via Grup de securitate

  • Configurare:
    /etc/wireguard/wg0.conf:

    [Interfață]
    Adresa = 10.10.0.1/24
    SaveConfig = false
    PrivateKey = <aws-private-key>
    ListenPort = 12345
    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE;  
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens4 -j MASQUERADE;
    
    [Peer]
    PublicKey = <ovh-public-key>
    IP-uri permise = 10.10.0.2/24, 192.168.10.0/16
    Punct final = 321.321.321.321:12345
    

Instanță OVH Public Cloud:

  • OS: Ubuntu 21.04

  • Adresă IP internă: ex. 192.168.10.100/16 enp0s2

  • Adresă IP publică: ex. 321.321.321.321/32 enp0s1

  • Port 12345/udp și 12345/tcp deschis via ufw

  • Configurare:
    /etc/wireguard/wg0.conf:

    [Interfață]
    Adresa = 10.10.0.2/24
    SaveConfig = false
    PrivateKey = <ovh-private-key>
    ListenPort = 12345
    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp0s1 -j MASQUERADE;  
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o enp0s1 -j MASQUERADE;
    
    [Peer]
    PublicKey = <aws-public-key>
    IP-uri permise = 10.10.0.1/24, 10.0.0.0/16
    Punct final = 123.123.123.123:12345
    

Ambele cazuri:

  • net.ipv4.ip_forward=1 în /etc/sysctl.conf
  • comanda: wg-quick up /etc/wireguard/wg0.conf
  • ambele rulează și au creat wg0 interfețe cu IP-uri de la wg0.conf

Rezumat:

  • răsuci la ascultarea aplicației pe portul deschis 80/tcp nu funcționează pe ambele părți.

Am pierdut ceva? Cum pot depana asta? Am citit mai multe articole, dar nu imi dau seama.

ACTUALIZAȚI:

Comunicarea funcționează după modificare /etc/wireguard/wg0.conf:
din AllowedIPs = 10.10.0.x/24, (...) la AllowedIPs = 10.10.0.x/32, (...)
așa cum a sugerat @Tom Yan.

Dar mă lupt cu rutarea. Iată cum arată cu ping-uri către alte servere care se află în aceleași rețele ca serverele VPN.

În AWS Am adăugat la tabelul de rutare regula:
192.168.10.0/16 prin intermediul Interfață AWS-VPN

În OVH-unva-instanță am alergat:
IP route add 10.0.0.0/16 prin 192.168.10.100 dev eno4

Rezumatul ping-ului:

OVH-VPN -> AWS-VPN OK
OVH-VPN -> AWS-some-instance timeout
OVH-o-o-instanță -> AWS-VPN OK
OVH-some-instance -> AWS-some-instance timeout

AWS-VPN -> OVH-VPN OK
AWS-VPN -> OVH-o anumită instanță OK
AWS-some-instance -> OVH-VPN timeout
AWS-some-instance -> OVH-some-instance timeout

În jurnale pot vedea doar informații:

$: dmesg -wH
[Jul20 13:40] wireguard: wg0: Primirea pachetului keepalive de la peer 5 (123.123.123.123:12345)

IPTables și rutare

AWS-VPN:

$: iptables-salvare
-P ACCEPT INTRARE
-P ACCEPTĂ ÎN ÎNTÂMPRE
-P ACCEPT IEȘIRE
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT

$: traseu ip
implicit prin 10.0.22.1 dev ens4 proto dhcp src 10.0.22.22 metric 100 
10.0.22.0/19 dev ens4 proto kernel scope link src 10.0.22.22 
10.0.22.1 dev ens4 proto dhcp scope link src 10.0.22.22 metric 100 
10.10.0.2 dev wg0 scope link 
192.168.10.0/16 dev wg0 scope link 

### Reguli AWS Console Panel pentru serverul AWS-VPN
TCP personalizat TCP 12345 321.321.321.321/32
UDP personalizat UDP 12345 321.321.321.321/32
Tot traficul Toate Toate 321.321.321.321/32
Tot traficul Toate Toate 10.0.0.0/16
Tot traficul Toate Toate 192.168.10.0/16
Tot traficul Toate Toate 10.10.0.2/32

OVH-VPN:

$: iptables-salvare
*filtru
:INPUT ACCEPT [26612:55893110]
: FORWARD ACCEPT [0:0]
: ACCEPT IEȘIRE [34036:3715836]
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
COMMIT
*nat
:ACCEPTAREA PRE-ROUTARE [0:0]
:INPUT ACCEPT [0:0]
: ACCEPT IEȘIRE [0:0]
: POSTROUTING ACCEPT [69:5450]
-A POSTROUTING -o enp0s1 -j MASQUERADE
COMMIT

$: traseu ip
implicit prin 321.321.321.1 dev enp0s1 proto dhcp src 321.321.321.321 metric 100 
10.0.0.0/16 dev wg0 scope link 
321.321.321.1 dev enp0s2 proto dhcp scope link src 321.321.321.321 metric 100 
169.254.169.254 prin 192.168.10.2 dev enp0s2 proto dhcp src 192.168.10.100 metric 100 
10.10.0.1 dev wg0 scope link 
192.168.10.0/16 dev enp0s2 proto kernel scope link src 192.168.10.100

$: firewall-cmd --list-all-zones
# Am eliminat liniile goale
intern (activ)
  target: implicit
  icmp-block-inversion: nu
  interfete: 
  surse: 10.0.0.0/16 10.10.0.1/32 123.123.123.123/32
  servicii: dhcpv6-client mdns ssh
  porturi: 12345/tcp 12345/udp
public (activ)
  target: implicit
  icmp-block-inversion: nu
  interfete: 
  surse: 123.123.123.123/32
  servicii: dhcpv6-client ssh
  porturi: 12345/tcp 12345/udp

Ce altceva ar trebui să fac ca să funcționeze?

Tim avatar
drapel gp
Tim
Aș începe prin a deschide firewall pentru a permite IMCP să verifice conectivitatea la rețea. Apoi s-ar putea telnet la porturile de pe fiecare mașină locală pentru a verifica wireguard este ascultat, apoi telnet la porturile de la mașina de la distanță.
Tom Yan avatar
drapel in
Vă rugăm să nu utilizați `/24` în `AllowedIPs=` decât dacă adresa este de fapt un ID de subrețea. (Deci ar trebui să fie `10.10.0.1/32` / `10.10.0.2/32` sau chiar doar `10.10.0.1` / `10.10.0.2`. De fapt, dacă nu veți permite doar `10.10.0.0` /24` pe ambele părți, probabil că nu este necesar să folosiți `/24` în `Address=`.)
Tom Yan avatar
drapel in
De asemenea, `wg` vă spune când / dacă ați primit o strângere de mână din cealaltă parte.
maar avatar
drapel gb
@TomYan Mulțumesc! Funcționează după ce am schimbat „AllowedIPs” așa cum ați sugerat. Dar am câteva probleme de rutare.. Am editat postarea principală. Apreciez ajutorul tău!
Tom Yan avatar
drapel in
Ați putea adăuga rezultatul `iptables-save` a ambelor gazde?
maar avatar
drapel gb
@TomYan Sigur, am actualizat conținutul întrebării cu ieșirea „iptables-save”.
Tom Yan avatar
drapel in
De ce nu dați rezultat *real* pentru `AWS-VPN`?
Tom Yan avatar
drapel in
De asemenea, oricare/amândoi sunt gateway-ul implicit pentru unele instanțe? Pentru ca `AWS-some-instance -> OVH-VPN` / `OVH-some-instance -> AWS-VPN` să funcționeze / să fi funcționat, ar trebui să existe o rută pe unele-instanțe care acoperă `10.10.0.1 ` și, respectiv, `10.10.0.2` (din moment ce nu `MASQUERADE` pentru ceea ce iese din interfața VPN de nicio parte). De asemenea, ați menționat că adăugați ruta `192.168.10.0/16 prin [sic.] AWS-VPN-interface`, ați vrut să spuneți că wg-quick nu a adăugat-o automat pentru dvs.? De ce adăugarea traseului (manual) pe care ați menționat-o nu este „echilibrata”?
maar avatar
drapel gb
@TomYan Ruta `192.168.10.0/16 prin [sic.] AWS-VPN-interface` am adăugat în AWS Console Panel, este o rută pentru alte instanțe (întreaga rețea). De asemenea, pe serverul AWS-VPN am doar interfață privată (`ens4`) și există NAT de destinație către IP public prin firewall-ul AWS încorporat în afara instanței AWS-VPN. Pe OVH-VPN am două interfețe - interfață publică (`enp0s1`) și privată (`enp0s2`) și ca firewall folosesc `firewalld` (în OVH-VPN).
maar avatar
drapel gb
Deci, dacă înțeleg corect din partea AWS, ar trebui să adaug ruta `192.168.10.0/16 prin 10.10.0.1`? Și pe OVH-VPN `10.10.0.2/16 prin 10.10.0.2`? Când încerc să fac asta pe celălalt server OVH, am o eroare: `Eroare: Nexthop are gateway invalid.`
maar avatar
drapel gb
@TomYan Am adăugat și ieșirea comenzii rutei IP de la ambele.
Tom Yan avatar
drapel in
Să [continuăm această discuție în chat](https://chat.stackexchange.com/rooms/127745/discussion-between-tom-yan-and-maar).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.