Puncte:1

Rutarea numai a rețelei private în wireguard VPN

drapel in

Am câteva gazde în spatele unui router NAT pe care vreau să îl accesez printr-un VPN wireguard. Aș putea configura cu succes rețeaua privată, dar mai este ceva care mă deranjează.

Vreau ca fiecare colegi să:

  • accesați unul la altul (172.9.9.*) prin VPN (prin wg0)
  • accesați orice altă gazdă din afara VPN (prin eth0).

Iată o schemă a rețelei și a configurației curente:

âââââââ ââââââââââ ââ âââââââ
â S âââââ⤠Internet âââââ⤠A â
âââââââ âââââ¬âââââ ââ âââââââ
               â
               â
          ââââââ´ââââââ
          â NAT DHCP â
       âââ⤠Router ââââ
       â ââââââââââââ â
       â â
    ââââ´âââ ââââ´âââ
    â X â â B â
    âââââââ âââââââ
  • S este serverul VPN și este accesibil pe internet prin IP static;
  • X este un „server de calcul”, poate accesa internetul, dar se află în spatele unui NAT și IP-ul lui este dinamic și nu este cunoscut dinainte;
  • A este un „client la distanță” la care dorește să se conecteze X;
  • B este un „client local” la care dorește să se conecteze X și este în aceeași rețea locală.

eu vreau aia A și B se poate conecta la X prin S, dar toate aceste gazde ar trebui să folosească VPN-ul numai atunci când se contactează între ele și nu atunci când accesează internetul.

Deci, de exemplu, A poate trimite ping la google.com direct, dar va trimite ping X prin intermediul S.

După ce am căutat și citit documentații, încă nu îmi este clar dacă este posibil să fac asta fără a folosi iptables și dacă este posibil să faceți acest lucru folosind doar configurația wireguard.

Configurația actuală este următoarea:

## S wg0.conf

[Interfață]
PrivateKey = S-cheie-privată
Adresa = 172.9.9.1/24
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820

[Peer]
# A
PublicKey = A-cheie-publică
IP-uri permise = 172.9.9.100/32

[Peer]
#B
PublicKey = B-cheie-publică
AllowedIPs = 172.9.9.101/32

[Peer]
# X
PublicKey = X-cheie-publică
AllowedIPs = 172.9.9.10/32
# A wg0.conf

[Interfață]
Adresa = 172.9.9.100/24
PrivateKey = A-cheie-privată
DNS = 1.1.1.1

[Peer]
PublicKey = S-cheie-publică
Punct final = S-ip-address:51820
AllowedIPs = 0.0.0.0/0, ::/0

Bconfigurația lui este similară cu A, dar cu IP 172.9.9.101 și o cheie privată diferită.

# X wg0.conf

[Interfață]
Adresa = 172.9.9.10/24
PrivateKey = X-cheie-privată
DNS = 1.1.1.1

[Peer]
PublicKey = S-cheie-publică
Punct final = S-ip-address:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25 # Pentru a menține serverul accesibil

Această configurație funcționează și toate gazdele se pot accesa una pe cealaltă prin VPN, dar vreau ca doar traficul direcționat către gazde 172.9.9.* trece prin acest VPN. Celălalt trafic va fi direcționat de către gateway-ul implicit.

Ceea ce mă nedumerește este că, dacă schimb configurația A astfel încât

AllowedIPs = 172.9.9.0/24

atunci, pentru A, pachetele sunt direcționate conform intenției (de exemplu, I can curl ifconfig.me si ia AIP-ul public al lui), dar dacă fac același lucru pe X, nu va funcționa și pachetele nu merg 172.9.9.0/24 nu vor fi livrate.

EDIT#1

Am uitat să menționez că mi-ar plăcea și dacă, atunci când mă conectez la X, clienții locali precum B nu ar trimite pachete în afara rețelei locale, deci B -> Router -> X si nu B -> Router -> S -> Router -> X.

drapel mx
`AllowedIPs` este calea de urmat, așa cum a explicat clar Justin în răspunsul lor. Este posibil să nu puteți `curl ifconfig.me` când utilizați `AllowedIPs = 172.9.9.0/24` din cauza problemelor DNS. Verificați dacă puteți să `ping 8.8.8.8`: dacă puteți, atunci remediați rezoluția DNS.
Puncte:2
drapel cn

A stabilit IP-uri permise la adresele IP pe care doriți traseu către/prin egal.

Într-o configurație normală hub-and-spoke, pe hub-ul dvs. (S), ați configura IP-uri permise pentru fiecare peer ca și dvs., rutarea pachetelor către fiecare peer numai dacă utilizează adresa IP WireGuard a peer-ului ca adresă de destinație; iar pe spițele tale (A, B și X), ai configura IP-uri permise către CIDR-ul rețelei WireGuard (172.9.9.0/24), rutarea pachetelor către hub numai dacă folosesc adresele IP WireGuard ale altui peer ca adresă de destinație.

Deci, cu o configurație normală, ați accesa A de la B sau X cu adresa IP WireGuard a lui A 172.9.9.100, B din A sau X cu 172.9.9.101, iar X din A sau B cu 172.9.9.10.

Dar dacă doriți și să puteți accesa fiecare spiță prin adresa IP legată de NIC-ul fizic al spiței (de ex. eth0), ar trebui să ajustați IP-uri permise atât pe hub, cât și pe spițe pentru a include acele adrese IP.

De exemplu, dacă A eth0 adresa este 198.51.100.65, B este 192.168.0.66, iar lui X este 192.168.0.88, ai ajusta peer-urile din configurația WireGuard a hub-ului la aceasta:

## S wg0.conf
...

[Peer]
# A
PublicKey = A-cheie-publică
IP-uri permise = 172.9.9.100/32
IP-uri permise = 198.51.100.65/32

[Peer]
#B
PublicKey = B-cheie-publică
AllowedIPs = 172.9.9.101/32
IP-uri permise = 192.168.0.66/32

[Peer]
# X
PublicKey = X-cheie-publică
AllowedIPs = 172.9.9.10/32
IP-uri permise = 192.168.0.88/32

Și setați IP-uri permise în fiecare dintre configurațiile spiței la aceasta:

AllowedIPs = 172.9.9.0/24
IP-uri permise = 198.51.100.65/32
IP-uri permise = 192.168.0.66/32
IP-uri permise = 192.168.0.88/32

(Rețineți că puteți specifica, de asemenea, toate blocurile pe o singură linie, cum ar fi IP-uri permise = 172.9.9.0/24, 198.51.100.65/32, 192.168.0.66/32, 192.168.0.88/32 daca preferi.)


Cu configurația actuală, unde aveți AllowedIPs = 0.0.0.0/0 pe X, când alergi curl 198.51.100.65 de la X, ceea ce se întâmplă este că X direcționează pachetele destinate lui A (și orice altceva) prin tunelul său WireGuard către S, iar apoi S direcționează acele pachete necriptate prin Internet către A (mascarate cu adresa IP publică a lui S); ca răspuns, A trimite pachete necriptate prin Internet către S, pe care S le direcționează prin tunelul său WireGuard către X.

Dacă vrei să te asiguri că S nu o face niciodată rutați pachetele tunelizate prin rețeaua WireGuard către Internet, puteți ajusta regulile iptables pentru a preveni acest lucru; ceva de genul următor ar face probabil truc:

PostUp = iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT; iptables -A FORWARD -i wg0 -o eth0 -j DROP; iptables -A FORWARD -i eth0 -o wg0 -j DROP
ARDVL avatar
drapel in
Mulțumesc pentru această explicație detaliată! Este foarte clar, deși în ceea ce privește accesul folosind adresa IP `NIC`, încă nu-mi este clar: deoarece `X` și `B` sunt în spatele DHCP și IP-ul lor s-ar putea schimba (mai ales pentru `B`), nu știu asta în avans și setați IP-ul permis corespunzător.
ARDVL avatar
drapel in
De asemenea, am încercat deja să setez `AllowedIPs` la `172.9.9.0/24`, dar nu a funcționat. După cum s-a menționat într-un comentariu, a fost o problemă de DNS.
drapel cn
Pentru a utiliza adrese NIC atribuite de DHCP, fie trebuie să configurați serverul DHCP pentru a atribui adrese IP fixe X și B, fie să actualizați setările „AllowedIPs” ale celorlalți colegi de fiecare dată când o adresă diferită a fost atribuită lui X sau B. ( Dar, de asemenea, rețineți că puteți face un hibrid al acestui lucru, în care accesați A prin adresa sa NIC, dar X și B prin adresele lor WireGuard -- în acest caz, puteți pur și simplu omite adresele NIC ale lui X și B din setările dvs. `AllowedIPs` .)
Puncte:0
drapel in

Am avut o problemă cu DNS: utilizarea AllowedIPs = 172.9.9.0/24 mi-a permis să pun ping 8.8.8.8, dar nu google.com.

Am rezolvat includerea interfeței DNS în IP-urile permise, așa că obțin rezoluția DNS prin VPN, dar traficul nu este în VPN:

[Interfață]
...
DNS = 1.1.1.1

[Peer]
...
IP-uri permise = 172.9.9.0/24, 1.1.1.1/32

Asta nu răspunde la a doua întrebare pe care am avut-o: dacă se poate face X și B comunica direct fără a trece prin S. Celălalt răspuns ajută la înțelegerea asta.

EDITAȚI | ×

Se pare că funcționează și prin scăderea DNS câmp, deci ar trebui să folosească același server DNS pentru ambele interfețe.

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.