WireGuard a funkce AllowedIPs

[holantomas]

Hojte, muze mi nekdo polopate vysvetlit k cemu presne slouzi Allowed IPs atribut v konfiguraci peera? Manualy rikaji ze to ma dve funkce:

1 - Omezeni prichozi komunikace na dane rozsahy,
2 - routovani odchozi komunikace pro urcene rozsahy.

Nechtel jsem to nechat otevrene (0.0.0.0/0) ale jen dany rozsah. Chci si tedy pomoci wireguard vytvorit opravdu VPN nikoliv to co dnes nesmyslne oznacuji jako VPN a pritom je to proxy.

Pokud nastavim na Mikrotiku 0.0.0.0/0 tak vse funguje. Pokud nastavim 10.8.0.0/24 coz je rozsah vsech zarizeni v teto VPN tak to prestane fungovat. Podobne je to v Ubuntu. 10.8.0.0/24 nefunguje akorat zde je zmena a to ze pri 0.0.0.0/0 se to zacne chovat prave jako proxy. Tedy veskera komunikace notebooku jede pres hlavni server (10.8.0.1/24) ale aspon to funguje.

Da se to nejak obejit? Chci to vse omezit jen na podsit 10.8.0.0/24, ale zaroven chci aby pres to sla jen komunikace v ramci teto podsite a nikoliv vse. Teprve si s tim zacinam hrat. Na serveru pouzivam docker image weejewel/wg-easy.

[Reklama]

[drobek1]

Neuvádíš konfiguraci => dá se špatně radit co máš špatně..
Nicméně by ses mohl podívat např. na tento návod, snad ti pomůže.

[Martin Poljak]

Hojte, muze mi nekdo polopate vysvetlit k cemu presne slouzi Allowed IPs atribut v konfiguraci peera? Manualy rikaji ze to ma dve funkce:

1 - Omezeni prichozi komunikace na dane rozsahy,
2 - routovani odchozi komunikace pro urcene rozsahy.

Co na tom chcete přesně vysvětlovat? Prostě z toho, co není allowed vám nic nepřijde ani na to WIreguard nevytvoří odchozí routování. To je celé.

Pokud nastavim na Mikrotiku 0.0.0.0/0 tak vse funguje. Pokud nastavim 10.8.0.0/24 coz je rozsah vsech zarizeni v teto VPN tak to prestane fungovat. [...] Chci to vse omezit jen na podsit 10.8.0.0/24, ale zaroven chci aby pres to sla jen komunikace v ramci teto podsite a nikoliv vse. Teprve si s tim zacinam hrat.

To je dost zvláštní. Fungovat by to právě takhle mělo.

[stevo54785]

Skús
ip route
Možno tam nemáš správnu routu

[Karlosek]

Nemáš tam maškarádu? Pak bys musel do AllowedIPs dát i IP peera. Možná bys ji tam měl dát i tak, to si nejsem jistý.

[Reklama]

[holantomas]

Nemáš tam maškarádu? Pak bys musel do AllowedIPs dát i IP peera. Možná bys ji tam měl dát i tak, to si nejsem jistý.

Jakoze maskaradu na interface Wireguardu? A IP jakeho peera? Vlastni, protejsek? A jakou? Podsit wireguardu nebo realnou lokalni nebo verejnou?

Skús
ip route
Možno tam nemáš správnu routu

To je mozne, IP tables jdou trochu mimo me, vzdycky najdu cestu jak se jim vyhnout(napr. ufw, atd.) Ale podle navodu apod. by to na PC melo byt vse spravne, hlavne ta routujici na 0.0.0.0/0

Co na tom chcete přesně vysvětlovat? Prostě z toho, co není allowed vám nic nepřijde ani na to WIreguard nevytvoří odchozí routování. To je celé.

Vsak to take pisi, "preklad" tech dvou bodu z EN manualu je muj, ale chtel jsem si byt jisty zda to chapu spravne a jestli tam neni schovaneho jeste neco - trochu u te sitariny bojuji s terminologii (myslet znamena h**** vedet)

To je dost zvláštní. Fungovat by to právě takhle mělo.

Prave. Tak jak chapu Allowed IPs tak by melo fungovat jen to ze proste vsem peerum strelim Allowed IPs 10.8.0.0/24 a to by melo routovat odchozi komunikaci v tomto rozsahu pres wireguard interface a zbytek normalne.

Nicméně by ses mohl podívat např. na tento návod, snad ti pomůže.

Bohuzel, toto je na me az zbytecne mnoho teorie, ale treba najdu nejaky cas to cele projit.

Neuvádíš konfiguraci => dá se špatně radit co máš špatně..

Konfigurace notebook(i Mikrotiky, rozdil je jen v ip pro interface):

Kód: [Vybrat]

[Interface]
PrivateKey = XXXXX
Address = 10.8.0.2/24
DNS = 1.1.1.1


[Peer]
PublicKey = XXXXX
PresharedKey = XXXXX
AllowedIPs = 10.8.0.0/24
Endpoint = xxxxx.cz:51820

Konfigurace server - je automaticky generovana, ale neprijde mi tam nic spatne:

Kód: [Vybrat]

[Interface]
PrivateKey = XXXXXXXX
Address = 10.8.0.1/24
ListenPort = 51820
PreUp =
PostUp =  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE; iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT; iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT>
PreDown =
PostDown =


# Client: 1 - jine PC
[Peer]
PublicKey = XXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.8.0.3/32

# Client: 2 - Notebook
[Peer]
PublicKey = XXXXXXX
PresharedKey = XXXXXXX
AllowedIPs = 10.8.0.2/32


[Karlosek]

Asi bych to vzal od začátku. Na klientovi

Kód: [Vybrat]

ping 10.8.0.1
traceroute 10.8.0.1
na serveru je povolený forward v /proc/sys/net/ipv4/ip_forward ?
pak na serveru

Kód: [Vybrat]

tcpdump -i wg0 icmp a pingat z klienta

[farbydos2]

Jen jsem letmo přeletěl konfigurační soubory a zdá se mi, že na tzv. "serveru" máte (správně) masku /32, kdežto na klientech /24. Doporučil bych ji ve vašm případě také změnit na /32.

Jednotliví "klienti" pak komunikují skrze "server". Uvozovky píši naschvál, protože WG je by design řešen symetricky a zná jen pojem peer.  VPN "server" tak vznikne především nesymetrickou konfigurací routovacích tabulek jednotlivých peerů. Ať má server adresu WG rozhraní 10.8.0.1/24 a ať jsou tu dva klienti peer1 10.8.0.2/32 a peer2 10.8.0.3/32.

Pokud bude mít peer1 v AllowedIPs: 10.8.0.0/24, nastaví se na peer1 při startu WG rozhraní směrování: 10.8.0.0/24 přes příslušné WG rozhraní. Jde o volbu. Klidně můžete do routovací tabulky peer1 zasáhnout ručně a nasměrovat si přes WG rozhraní cokoliv dalšího. Nebo můžete nepoužít AllowedIPs a místo toho nastavit směrování v PostUp...

Pokud se podaří spustit point-to-point spojení peer1 a serveru, projde ping atp. Můžeme se posunout dál. Na serveru se musí povolit směrování paketů. Třeba pomocí sysctl -w net.ipv4.ip_forward=1 v PerUp, Pak bude možné posílat pakety mezi peer1 a peer2 tak, že server bude hrát roli prostředníka. Není potřeba nic NATovat. Pokud by měl peer1 přistoupit do části sítě, kam má přístup pouze server, třeba do rozsahu 192.66.66.0/24, musela by se do AllowedIPs peer1 přidat i tato část sítě a pak by musel server provoz NATovat.

Na mikrotiku budete asi muset nastavit v IP->Addresses na WG rozhraní 10.8.0.3/32 a adresu sítě 10.8.0.1. Pak v IP->Routes nastavit směrování 10.8.0.0/24 přes 10.8.0.1.

[Petr Krčmář]

Ještě je potřeba ověřit, že nedošlo ke kolizi IP rozsahů. Každé to zařízení má minimálně dvě síťová rozhraní: skutečnou okolní síť a rozhraní WireGuardu. V žádné z těch sítí se nesmí používat stejné rozsahy, aby bylo směrování jednoznačné. Otázka tedy zní: nemá ještě jiné síťové rozhraní (třeba síť kolem MikroTiku) také rozsah 10.8.0.0/24? Pak se rozbije směrování a router neví, kam poslat provoz pro tento rozsah.

Odpovídalo by to popsanému chování, ale my máme pořád málo informací o okolní síti. Většina problémů s VPN nesouvisí přímo s tunelováním provozu, ale s nesprávně nastaveným směrováním provozu.

S čímž souvisí i to, že příkaz ip nemá nic společného s IPtables. Příkazem ip se právě konfiguruje síťování v Linuxu, včetně směrovacích pravidel.

[holantomas]

Asi bych to vzal od začátku. Na klientovi

Kód: [Vybrat]

ping 10.8.0.1
traceroute 10.8.0.1
na serveru je povolený forward v /proc/sys/net/ipv4/ip_forward ?
pak na serveru

Kód: [Vybrat]

tcpdump -i wg0 icmp a pingat z klienta

No jasne sem blbec traceroute me vubec nenapadl. Mrknu na to. forward povoleny je.

Jen jsem letmo přeletěl konfigurační soubory a zdá se mi, že na tzv. "serveru" máte (správně) masku /32, kdežto na klientech /24. Doporučil bych ji ve vašm případě také změnit na /32.

Jednotliví "klienti" pak komunikují skrze "server". Uvozovky píši naschvál, protože WG je by design řešen symetricky a zná jen pojem peer.  VPN "server" tak vznikne především nesymetrickou konfigurací routovacích tabulek jednotlivých peerů. Ať má server adresu WG rozhraní 10.8.0.1/24 a ať jsou tu dva klienti peer1 10.8.0.2/32 a peer2 10.8.0.3/32.

Pokud bude mít peer1 v AllowedIPs: 10.8.0.0/24, nastaví se na peer1 při startu WG rozhraní směrování: 10.8.0.0/24 přes příslušné WG rozhraní. Jde o volbu. Klidně můžete do routovací tabulky peer1 zasáhnout ručně a nasměrovat si přes WG rozhraní cokoliv dalšího. Nebo můžete nepoužít AllowedIPs a místo toho nastavit směrování v PostUp...

Pokud se podaří spustit point-to-point spojení peer1 a serveru, projde ping atp. Můžeme se posunout dál. Na serveru se musí povolit směrování paketů. Třeba pomocí sysctl -w net.ipv4.ip_forward=1 v PerUp, Pak bude možné posílat pakety mezi peer1 a peer2 tak, že server bude hrát roli prostředníka. Není potřeba nic NATovat. Pokud by měl peer1 přistoupit do části sítě, kam má přístup pouze server, třeba do rozsahu 192.66.66.0/24, musela by se do AllowedIPs peer1 přidat i tato část sítě a pak by musel server provoz NATovat.

Na mikrotiku budete asi muset nastavit v IP->Addresses na WG rozhraní 10.8.0.3/32 a adresu sítě 10.8.0.1. Pak v IP->Routes nastavit směrování 10.8.0.0/24 přes 10.8.0.1.

Zakladni konfiguraci mi generuje server, myslel jsem ze to tak prave ma byt, preci jen kdyz nemam DHCP tak take nastavuji IPv4/24 resp. 255.255.255.0 tak mi to prislo logicke ze se do interface uvadi toto. Vyzkousim zmenit.

Ještě je potřeba ověřit, že nedošlo ke kolizi IP rozsahů. Každé to zařízení má minimálně dvě síťová rozhraní: skutečnou okolní síť a rozhraní WireGuardu. V žádné z těch sítí se nesmí používat stejné rozsahy, aby bylo směrování jednoznačné. Otázka tedy zní: nemá ještě jiné síťové rozhraní (třeba síť kolem MikroTiku) také rozsah 10.8.0.0/24? Pak se rozbije směrování a router neví, kam poslat provoz pro tento rozsah.

Tato podsit byla prave zvolena schvalne protoze se nikde jinde nepouziva(zadny peer takovou nema). Ale napada me, nemuze byt problem v tom ze Mikrotiky co slouzi jako vychozi brany site maji vetsinou stejnou podsit 10.0.0.0/24? Pripadne i 10.0.1.0/24 nebo 10.0.2.0/24.

[holantomas]

No to si delate srandu. Tak nakonec opravdu maska. Po zmene masky v address interfacu na "klientovi" z /24 na /32 se to zacalo chovat jak ma. Pri AllowedIPs 0.0.0.0/0 se to chova jako proxy a pri 10.8.0.0/24 jako VPN.

Diky moc vsem!

[Petr Krčmář]

Tohle je přesně ten případ, kdy problém vůbec nebyl ve VPN, ale ve směrování. Za domácí úkol se naučte používat příkaz

Kód: [Vybrat]

ip a prohlédněte si směrovací tabulky pomocí

Kód: [Vybrat]

ip route :-)

[holantomas]

Tohle je přesně ten případ, kdy problém vůbec nebyl ve VPN, ale ve směrování. Za domácí úkol se naučte používat příkaz

Kód: [Vybrat]

ip a prohlédněte si směrovací tabulky pomocí

Kód: [Vybrat]

ip route :-)

ip route jsem prave zkousel a tam se vse tvarilo(dle meho neodborneho nazoru) byt v poradku.

Linux pouzivam uz skoro 15 let a to jak osobnich strojich tak na serverech a nikdy jsem to nepotreboval, takze i kdyz to nastuduji tak to za mesic zapomenu Asi stejne jako ze od doby co pouzivam portainer tak pomalu zapominam zakladni docker prikazy Bohuzel jsem proste zaspal dobu a zacal ho pouzivat az v dobe kdy uz bylo vsechno jakztakz vyladene a na vsechno existovala udelatka nebo klikatka(ne fakt nepouzivam na serverech GUI) a takove veci sem fakt resit nemusel.