înregistrare Logare
Puncte:2
avatar Server

site2site wireguard cu docker: probleme de rutare

drapel fr
nick2k3

Disclaimer: repost de la stackoverflow: https://stackoverflow.com/questions/67917278/site2site-wireguard-with-docker-routing-problems

Încerc să am două containere, care rulează pe două RPI, să acționeze ca un VPN de la site la site între Rețeaua 1 și Rețeaua 2.

Cu configurarea de mai jos, pot da ping din interiorul recipientului rețeaua reciprocă:

  • din containerul docker 1 pot ping o adresă 192.168.1.1
  • din containerul docker 2 pot ping adresa 192.168.10.1

Dar dacă încerc să dau ping la 192.168.1.1 de la gazda System1 (192.168.10.100) am erori (vezi imaginea de mai jos pentru a vizualiza ce încerc să fac).

Înțeleg că trebuie să adaug o rută statică pe gazda system1 (192.168.10.100) pentru a direcționa traficul pentru 192.168.1.0/24 prin containerul wireguard (172.17.0.5), astfel că rulez:

$i p route add 192.168.1.0/24 prin 172.17.0.5
$ traseu ip
implicit prin 192.168.10.1 dev eth0 proto dhcp src 192.168.10.100 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev br-e19a4f1b7646 proto kernel scope link src 172.18.0.1 linkdown 
172.19.0.0/16 dev br-19684dacea29 proto kernel scope link src 172.19.0.1 
172.20.0.0/16 dev br-446863cf7cef proto kernel scope link src 172.20.0.1 
172.21.0.0/16 dev br-6800ed9b4dd6 proto kernel scope link src 172.21.0.1 linkdown 
172.22.0.0/16 dev br-8f8f439a7a28 proto kernel scope link src 172.22.0.1 linkdown 
192.168.1.0/24 prin 172.17.0.5 dev docker0 
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.100 
192.168.10.1 dev eth0 proto dhcp scope link src 192.168.10.100 metric 100

dar ping-ul la 192.168.1.1 încă nu reușește.

rulând tcpdump pe containerul 2, văd că unele pachete ajung într-adevăr la container:

root@936de7c0d7eb:/# tcpdump -n -i orice
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe orice tip de legătură LINUX_SLL (Linux cooked), dimensiunea capturii 262144 octeți
10:11:19.885845 IP [publicIPsystem1].56200 > 172.17.0.6.56100: UDP, lungime 128
10:11:30.440764 IP 172.17.0.6.56100 > [publicIPsystem1].56200: UDP, lungime 32
10:11:35.480625 ARP, Solicitați cine-are 172.17.0.1 spuneți 172.17.0.6, lungime 28
10:11:35.480755 ARP, Răspuns 172.17.0.1 este la 02:42:24:e5:ac:38, lungime 28

deci cred că nu este o problemă de rutare pe sistemul 1.

Poate cineva să-mi spună cum să diagnosticez asta în continuare?

EDITARE 1:
Am facut urmatorul test:

  1. rulați „tcpdump -ni any” pe containerul 2
  2. a trimis un ping de la Sistemul 1 (de la sistemul gazdă) 'ping -c 1 192.168.1.1 .
    Pe containerul 2, tcpdump înregistrează următoarele:
    tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
    ascultare pe orice tip de legătură LINUX_SLL (Linux cooked), dimensiunea capturii 262144 octeți
    15:04:47.495066 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, lungime 128
    15:04:58.120761 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP, lungime 32
  1. a trimis un ping din container (în interiorul containerului) 'ping -c 1 192.168.1.1 .
    Pe containerul 2, tcpdump înregistrează următoarele:
# tcpdump -ni orice
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe orice tip de legătură LINUX_SLL (Linux cooked), dimensiunea capturii 262144 octeți
15:05:48.120717 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, lungime 128
15:05:48.120871 IP 10.13.18.2 > 192.168.1.1: Solicitare ecou ICMP, id 747, secv 1, lungime 64
15:05:48.120963 IP 172.17.0.3 > 192.168.1.1: Solicitare ecou ICMP, id 747, seq 1, lungime 64
15:05:48.121955 IP 192.168.1.1 > 172.17.0.3: răspuns ecou ICMP, id 747, secv 1, lungime 64
15:05:48.122054 IP 192.168.1.1 > 10.13.18.2: răspuns ecou ICMP, id 747, secv 1, lungime 64
15:05:48.122246 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP, lungime 128
15:05:53.160617 ARP, Solicitați cine-are 172.17.0.1 spuneți 172.17.0.3, lungime 28
15:05:53.160636 ARP, Solicitați cine-are 172.17.0.3 spuneți 172.17.0.1, lungime 28
15:05:53.160745 ARP, Răspuns 172.17.0.3 este la 02:42:ac:11:00:03, lungime 28
15:05:53.160738 ARP, Răspuns 172.17.0.1 este la 02:42:24:e5:ac:38, lungime 28
15:05:58.672032 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, lungime 32

deci, se pare că pachetele sunt tratate diferit față de containerul 2, în funcție de ceva care îmi lipsește în prezent.. ar putea fi o problemă cu iptables?

introduceți descrierea imaginii aici

Site 1 Site 2
Interval IP de rețea 1 192.168.10.0/24 192.168.1.0/24
adresa sistemului gazdă 192.168.10.100 192.168.1.100
bridge docker0 interval 172.17.0.0/16 172.17.0.0/16
adresa containerului 172.17.0.5 172.17.0.6

Sistemul 1 - wg0.conf

[Interfață]
Adresa = 10.13.18.2
PrivateKey = *privatekey*
ListenPort = 56200
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = *publickey*
Punct final = *system2address*:56100
IP-uri permise = 10.13.18.1/32, 192.168.1.0/24

Sistemul 2 - wg0.conf

[Interfață]
Adresa = 10.13.18.1
ListenPort = 56100
PrivateKey = *privatekey*
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# peer_casaleuven
PublicKey = *publickey*
IP-uri permise = 10.13.18.2/32, 192.168.10.0/24
Punct final = *system1address*:56200
1722
1 + 7
jabbson avatar
drapel sb
jabbson
Când dați ping la 192.168.1.1 din sistemul 1 - vedeți pachete care sosesc la containerul 1 și părăsesc din el și le puteți corela cu pachetele de intrare pe care le vedeți pe containerul 2 (pentru că ceea ce vedeți poate fi doar keepalives sau ceva de genul acesta)? WireGuard are jurnalele pe care le puteți consulta? Cum arată tabelul de rutare de pe containerul 1?
0
Răspunde
drapel fr
nick2k3
da, am încercat să rulez „tcpdump -ni any” pe ambele containere în același timp, am așteptat câteva secunde pentru a verifica dacă nu au fost înregistrate alte pachete. Apoi rulez „ping -c 1 192.168.1.1” pentru a trimite doar un ping din sistemul 1 și văd pachetele care trec în ambele tcpdumps.
0
Răspunde
drapel fr
nick2k3
a adăugat un alt test în secțiunea Editare 1
0
Răspunde
A.B avatar
drapel cl
A.B
notă: sper că „eth0” al containerului nu are legătură, deoarece nu ar trebui să existe NAT nicăieri. Deci nu înțeleg de ce există această regulă: `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` în `PostUp`
0
Răspunde
drapel fr
nick2k3
regula iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE a fost pusă implicit de linuxserver/wireguard în configurația inițială. Dacă le elimin atât din PostUp, cât și din PostDown în ambele containere, atunci nu mai pot da ping la nimic.
0
Răspunde
A.B avatar
drapel cl
A.B
Bine. Oricum, asta nu schimbă nimic cu răspunsul pe care l-am scris mai jos. L-ai incercat?
0
Răspunde
drapel fr
nick2k3
Da, am incercat si merge!!! Mulțumesc mult! Mă întreb totuși de ce această ruloă este atât de fundamentală pentru a o face să funcționeze. Dacă rulez iptables --list, nu văd niciun tabel NAT..
0
Răspunde
Puncte:1
A.B avatar Server
drapel cl
A.B

Aceasta pare o problemă de rutare.

192.168.1.0/24 prin 172.17.0.5 dev docker0

Această rută nu a fost indicată cu o adresă sursă preferată. Deci, în mod firesc, gazda va alege adresa cea mai apropiată: 172.17.0.1, deoarece este adresa principală de pe docker0. 172.17.0.1 nu se află în lista de IP-uri permise a lui WireGuard (și nici nu ar trebui să o facă), așa că va fi respins de WireGuard. Dacă nu a fost respins, ar exista oricum o problemă de rutare în peer din cauza celor două LAN-uri separate care folosesc același bloc de adrese IP.

Incearca asta

  • Sistemul 1

    ruta ip înlocuiește 192.168.1.0/24 prin 172.17.0.5 dev docker0 src 192.168.10.100

  • Sistemul 2

    ruta ip înlocuiește 192.168.10.0/24 prin 172.17.0.6 dev docker0 src 192.168.1.100

Rețineți că înainte de această ajustare, aceasta nu ar fi trebuit să afecteze restul rețelelor LAN, ci doar cele două sisteme gazdă Docker.

0 + 1
A.B avatar
drapel cl
A.B
Re explic ce am scris în răspuns: adresa sursă selectată a fost greșită. Această rută are src sugerat să folosească adresa sursă corectă din LAN
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.