Puncte:1

Wireguard folosește un client ca gateway al altuia

drapel cn

Am o configurație Wireguard VPN care arată, practic, așa:

P1 ---- S ---- P2 --- Internet

adrese IP: P1 = 10.200.1.5 S = 10,200,1,1 P2 = 10.200.1.3

Redirecționez tot traficul P1 către S specificând Ips permis = 0.0.0.0/0 în configurația clientului P1.

Acum vreau ca S să direcționeze acel trafic către P2. Am încercat următoarele pe S:

 regulă ip adăugați din 10.200.1.5 căutare 200
 IP route add default prin 10.200.1.3 dev wg0 tabelul 200
 sysctl -w net.ipv4.ip_forward=1

Cu toate acestea, când rulez tcpdump pe P2, nu pot vedea traficul care vine. De asemenea, P1 nu se confruntă cu nicio conexiune la internet.

Editare: testarea tabelului de rutare personalizat pe S via

ruta ip obține 8.8.8.8 de la 10.200.1.5 iif wg0

dă următorul răspuns

8.8.8.8 de la 10.200.1.5 prin 10.200.1.3 dev wg0 tabelul 200
    cache iif wg0

ceea ce pare în regulă, totuși

tcpdump -nn -i wg0

pe S arată inaccesibil ca mai jos

09:58:22.207251 IP 10.200.1.5.9134 > 8.8.8.8.53: 36555+ A? play.googleapis.com. (37)
09:58:22.207270 IP 10.200.1.1 > 10.200.1.5: gazda ICMP 8.8.8.8 inaccesibil, lungime 73
djdomi avatar
drapel za
de ce nu lași p1 să se conecteze direct?
drapel cn
p1 se află într-o rețea internă și nu poate accesa direct internetul
djdomi avatar
drapel za
rețeaua dvs. este neclară, vă rugăm să ne spuneți mai multe despre
drapel cn
Ceea ce ai până acum arată bine -- asigură-te că ai setat și `AllowedIPs = 0.0.0.0/0` în configurația lui S `[Peer]` pentru P2; și că includeți `10.200.1.5` în `AllowedIPs` din configurația `[Peer]` a lui P2 pentru S.
drapel cn
Când pun 0.0.0.0/0 în configurația lui P2 pe S, nu mai pot SSH în S, deoarece (cred) acesta atrage tot traficul și îl trimite la P2, nu?
Puncte:1
drapel cl
A.B

WireGuard este o interfață de nivel 3, așa cum se precizează prin 10.200.1.3 nu are niciun efect, deoarece ar fi folosit pentru protocolul de nivel de legătură (de obicei ARP) pentru a rezolva adresa de nivel 2 care nu există aici.

Asa de

IP route add default prin 10.200.1.3 dev wg0 tabelul 200

poate fi rescris:

ip route add default dev wg0 table 200

Acest lucru vă ajută să rețineți că această parte nu este partea care selectează un pachet pentru a merge la P1 sau la P2: și WireGuard are propria sa rutare internă: criptokey-routing, care se face prin setarea corectă IP-uri permise în configurația fiecărui peer. Există o limitare importantă: spre deosebire de rutarea standard, IP-uri permise nu acceptă nicio adresă suprapusă. Dacă se încearcă acest lucru (cum ar fi setarea pe serverul S AllowedIPs = 0.0.0.0/0 pentru Peer P2), acest lucru va șterge automat adresele aflate în conflict de pe (celelalte) persoane (cum ar fi ștergerea IP-uri permise = 10.200.1.5 de la Peer P1, deoarece 0.0.0.0/0 se suprapune cu orice altceva) și conectivitatea va avea de suferit (S nu cripto-rutează nimic către P1: nu mai are conectivitate).

Există două moduri de a rezolva acest lucru:

  • utilizați două interfețe WireGuard diferite

    Limitarea anterioară este pentru interfața WireGuard. Utilizarea unei a doua interfețe evită astfel de confruntări, dar va face rutarea mai complexă. Probabil că acum sunt necesare mai multe intrări în tabelul de rutare 200 și/sau tabelul principal: una pentru interfața din partea stângă și una (implicit) pentru interfața din partea dreaptă.

  • faceți o scădere setată a intervalelor aflate în conflict

    Ar putea exista instrumente capabile să calculeze diferența dintre setul 0.0.0.0/0 și setul 10.200.1.5, dar nu le cunosc. Mai există un instrument la îndemână numit mască de rețea (pagina principala: https://github.com/tlby/netmask) care va ajuta prin conversia intervalelor în cel mai mic set de măști de rețea:

    $ netmask 0.0.0.0:9.255.255.255 10.200.1.3 11.0.0.0:255.255.255.255
            0.0.0.0/5
            8.0.0.0/7
         10.200.1.3/32
           11.0.0.0/8
           12.0.0.0/6
           16.0.0.0/4
           32.0.0.0/3
           64.0.0.0/2
          128.0.0.0/1
    

    Acestea sunt valorile (pentru a se separa cu virgule) care ar trebui folosite pe serverul S pentru Peer P2 IP-uri permise deci rutarea cripto-cheii va direcționa orice acolo, cu excepția 10.0.0.0/8 din care doar 10.200.1.3 va fi definit pe partea lui P2, lăsând intact 10.200.1.5 deja definit pe partea lui P1: nu se mai suprapune. Pachetele trimise de P1 către Internet ar trebui să treacă acum la P2 pentru rutare ulterioară.

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.