Puncte:0

WireGuard combinând Hub și Spoke cu Point to Site

drapel us

Vreau o topologie Point to Site, dar deoarece gazdele „client” și „server” sunt ambele în propriile lor rețele NAT, trebuie să mă bazez pe o a treia gazdă într-o topologie Hub și Spoke.

vizualizare

Gazdă A (centrală)

[Interfață]
PrivateKey = 
Adresa = 10.201.50.1/32
ListenPort = 51820

PreUp = sysctl -w net.ipv4.ip_forward=1

[Peer]
PublicKey = 
IP-uri permise = 10.201.50.2/32

[Peer]
PublicKey = 
IP-uri permise = 10.201.50.3/32

Gazda B (server)

[Interfață]
PrivateKey = 
Adresa = 10.201.50.2/32

PreUp = sysctl -w net.ipv4.ip_forward=1
PreUp = iptables -t mangle -A PREROUTING -i %i -j MARK --set-mark 0x40
PreUp = iptables -t nat -A POSTRUTING ! -o %i -m mark --mark 0x40 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i %i -j MARK --set-mark 0x40
PostDown = iptables -t nat -A POSTROUTING ! -o %i -m mark --mark 0x40 -j MASQUERADE

[Peer]
PublicKey = 
Punct final = 198.230.220.45:51820
IP-uri permise = 10.201.50.0/24
PersistentKeepalive = 15

Gazdă C (client)

[Interfață]
PrivateKey = 
Adresa = 10.201.50.3/32

[Peer]
PublicKey = 
Punct final = 198.230.220.45:51820
IP-uri permise = 10.201.50.0/24, 10.0.0.0/24

Ambii colegi se conectează bine la hub.

interfață: wg0
  cheie publica: 
  cheie privată: (ascunsă)
  port de ascultare: 51820

egal: 
  punct final: :63882
  ips permise: 10.201.50.3/32
  ultima strângere de mână: acum 35 de secunde
  transfer: 213,07 KiB primit, 15,93 KiB trimis

egal: 
  punct final: :33868
  ips permise: 10.201.50.2/32
  ultima strângere de mână: acum 1 minut, 6 secunde
  transfer: 7,19 KiB primite, 5,12 KiB trimise

Pot da ping Host B de la Host C bine, ceea ce este bine, dar orice altă conexiune eșuează. De exemplu, nu pot accesa Host B, doar se blochează. Nu pot curla un server web care rulează pe Host B pe portul 80, de asemenea, se blochează. Din câte știu eu, niciun firewall nu rulează pe Host B. Celelalte gazde din rețeaua Host B nu sunt deloc accesibile.

Apreciez ajutorul tau. Noroc

Puncte:0
drapel cn

Cheia în această situație este să vă asigurați IP-uri permise pe fiecare peer este configurat pentru a permite adresele IP de destinație ale pachetelor pe care doriți să le faceți Trimite catre (sau trimite prin) egalul.

Deci, dacă blocul CIDR pentru site-ul local pe care doriți să îl accesați de la gazda C prin gazda A la gazda B este 10.0.0.0/24, asigurați-vă că IP-uri permise setarea pe Gazda C pentru Gazda A include 10.0.0.0/24 (cum ai si tu):

# Configurație gazdă C pentru peer gazdă A
IP-uri permise = 10.201.50.0/24, 10.0.0.0/24

Și, de asemenea, că IP-uri permise setarea pe Gazda A pentru Gazda B include 10.0.0.0/24 (pe care iti lipseste):

# Configurație gazdă A pentru peer gazdă B
IP-uri permise = 10.201.50.2/32, 10.0.0.0/24

Dar din descrierea dvs. despre funcționarea ping și SSH/HTTP nu, este posibil să aveți și o problemă MTU (pachete fragmentate/respinse deoarece au fost dimensionate puțin prea mari pentru un anumit hop pe parcurs). Încercați să adăugați această setare la [Interfață] secțiunea fiecărei configurații WireGuard:

MTU = 1280

Și nu aveți nevoie de masquerading pe Gazda A (doar pe Gazda B, așa cum ați făcut).


Cu toate acestea, dacă doriți să rutați toate trafic (0.0.0.0/0) de la gazda C la gazda A la gazda B, schimbați configurația WireGuard pentru gazdă A la aceasta:

[Interfață]
PrivateKey =...
Adresa = 10.201.50.1/24
ListenPort = 51820
Tabel = 123

PreUp = sysctl -w net.ipv4.ip_forward=1
PreUp = regulă ip add iif %i tabelul 123 prioritate 456
PostDown = ip rule del iif %i tabelul 123 prioritate 456

# către gazda B
[Peer]
PublicKey =...
AllowedIPs = 0.0.0.0/0

# către gazda C
[Peer]
PublicKey =...
IP-uri permise = 10.201.50.3/32

Aceasta va folosi un tabel de rutare personalizat (123) pentru acel trafic, pentru a evita să vă încurcați cu tabelul principal de rutare al gazdei A.

(Și modificați configurația Host C pentru a utiliza AllowedIPs = 0.0.0.0/0 de asemenea, dar fără alte modificări ale configurației sale.)

drapel us
Mulțumesc foarte mult pentru indicator, mă pot conecta la subrețeaua B acum. Nu știu dacă știți, dar tutorialele dvs. Wireguard sunt extrem de utile pentru comunitatea Wireguard, nu există nimic asemănător în altă parte. Oamenii se leagă de ei peste tot. M-a ajutat foarte mult. De asemenea, conexiunea dintre gazde nu funcționa, deoarece gazda de salt avea o configurare destul de strictă a regulilor iptables, am rezolvat asta acum.
drapel us
Am o altă întrebare dacă nu te superi. Cum aș proceda pentru a direcționa tot traficul de la gazda C la gazda B fără a direcționa tot traficul de la hub prin ea? Asta s-ar întâmpla dacă tocmai aș adăuga 0.0.0.0/0 la AllowedIP-urile din configurația peer B de pe hub.

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.