1 (edytowany przez imkebe 2020-03-27 17:59:11)

Temat: Przepychanie/most przez VPN

Mam 3 routery w różnych lokalizacjach R1, R2, R3. Każdy z nich ma własny LAN o niezależnej adresacji. Są spięte via wireguard poprzez główny R1. Na R1 z racji najlepszego łącza + wydajności sprzętu stoją dodatkowe VPNy i inne usługi.
W każdej z lokalizacji ma być udostępniona dodatkowa sieć guest, dla zewnętrznych użytkowników, i jej cały ruch musi iść przez VPN. Ten VPN jest na R1, na innych nie ma pamięci i mocy. Chodzi o to, aby utworzyć niejako most, który przepycha po prostu z interfejsu WiFi podpiętego do guesta przez tunel wireguarda to interfejsu guesta r1, który ma już odpowiednio zrobione routingi itp.

Podobny case, mam na NAS, który jest w LAN i ma swoje wirtualne interfejsy ale chcę aby ruch specyficznych usług szedł transparentnie do VPN na R1 (niejako offloading + szyfrowanie).

Myślałem o 'relay' interfejsie ale to chyba działa tylko lokalnie na WiFi? To musi być proste ale się trochę zakopałem.

Architektura sieci https://ibb.co/WxSpRc5

Jakieś propozycje?

2

Odp: Przepychanie/most przez VPN

A tak po prostu bridge wifi z tun0 ci nie działa?

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3 (edytowany przez imkebe 2020-03-27 18:14:24)

Odp: Przepychanie/most przez VPN

Cezary napisał/a:

A tak po prostu bridge wifi z tun0 ci nie działa?

Ale ja chce niejako zenkapsulować w istniejącym tunelu wireguard most między urządzeniami a nie w ramach urządzenia. mosty w ramach urządzenia mam i działają. Tylko pytanie czym spiąć R1 z R2 i R3 tak aby na sieci guestowej było niejako to samo (czyli VPN z R1). Przy czym OpenVPN na TAP odpada - od razu mówię - za ciężki i mam już przecież most wgX.

4

Odp: Przepychanie/most przez VPN

No a co ja napisałem? I nie tun0 oczywiście smile Masz tunel zakończony na r2 i r3 więc na r2 zrób sobie w networku bridge wg0 i wifi, wszystko co się podłączy do wifi będzie biegło przez tunel vpn.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

5

Odp: Przepychanie/most przez VPN

Moim zdaniem autor tematu już przepycha z routera R2 za pomocą Wifi + wireguarda pakiety do głównego routera R1 ale nie wie jak pokierować ruch dalej, żeby te pakiety szły do jednego z tuneli VPNa a nie na domyślny gateway tego routera R1.

Czyli to co wchodzi z wg0 na R1 ma wejść do innego tunelu zestawionego na R1.
Tak to zrozumiałem...

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

6

Odp: Przepychanie/most przez VPN

1) Wireguard zapewnia łączność pomiędzy LAN R2  (192.168.3.x) - LAN R1  (192.168.2.x) - LAN3  (192.168.4.x) czyt. L3
2) Ja potrzebuję aby ruch z LAN się nie mieszał z tym GUESTowym coś w stylu innego VLAN ale nie musi być. Ważne aby z mostować interfejscy guest0 miedzy urządzeniami, tak aby ta siec guestowa była podawana z R1, do R2 i R3 (i miała inną niezależną adresację) czyt L2/L3 ?
3) wireguard obsługuje tylko ruch L3 z nazwanymi trasami

Mi to implikuje, że nie mogę wybrać po prostu mostu na wg0 bo (a) miesza mi ruch (b) i tak nie przejdzie mi DHCP (chyba, że jakimś prekaźnikiem)

Może się mylę? Teraz dogrzebałem się do GRE, ktoś coś próbował? Cholerstwo jednak jest dla kernela 4.14, a nie ma nowszych sourców (zbudowałem przed chchwila nowy obraz)

7

Odp: Przepychanie/most przez VPN

Gubię się powoli. Skoro robiłeś tunel nie nie rób połączenia/forwardingu pomiędzy tunelem a lane bo piszesz że ci się ruch miesza. Więc po co robisz ten ruch?

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

8

Odp: Przepychanie/most przez VPN

Cezary napisał/a:

Gubię się powoli. Skoro robiłeś tunel nie nie rób połączenia/forwardingu pomiędzy tunelem a lane bo piszesz że ci się ruch miesza. Więc po co robisz ten ruch?

Tamten istniejacy tunel wireguard ma zostac jak jest bo on mi zapewnia łączność pomiędzy LAN i jest spoko.
Mogę zrobić oddzielny tunel wireguarda dedykowany guestom tylko, że widzę problem z ustawieniem routingu

Chociaż teraz się zastanawiam czy nowa instancja wgX z mostem na guest Wifi dla tych urządzeń  adresacja i DHCP Forwardem by możę nie zadziałała?

Tylko jak ma wygladac config dla wg? poniżej przykład... powinienem do sekcji allow dodac jeszcze sieć 172.16.0.0/24 dla kazdego urządzenia - tylko to implikuje błędny routing, bo jak to ma byc adresacja 172.16.0.0/24 na urządzeniu R1 ma isć przez tunel, a po driej stronie tunelu to samo tylko odwrotnie.

R1
guest0 172.16.0.1 (dhcp server)
- client 172.16.0.4
- client 172.16.0.7
wg0 192.110.12.1
- allow 192.110.12.2/32, 192.110.12.3/32

R2
guest0 172.16.0.2 (dhcp forward)
- client 172.16.0.5
- client 172.16.0.7
wg0 192.110.12.2
- allow 192.110.12.1/32

R3
guest0 172.16.0.3 (dhcp forward)
- client 172.16.0.8
- client 172.16.0.6
wg0 192.110.12.3
- allow 192.110.12.1/32


Więc... pomyslalem, ze mozna albo uzyc istniejacego wg0 albo utworzyc nowy wg1 ale i tak w nim trzeba by puscic enkapsulowany ruch łączący inne interfejsy np. br10 dla kazdego z urządzeń (a te br10 zmostowane by zostąły do WiFi).

Pytanie jaki protokół/interfejs użyć do zmostowania tego tunelu (ale wg ma byc tylko nośnikiem - jakbys sesje SSH puszczał po OpenVPN).

Chyba, że można prosciej i za bardzo kombijuje?

9

Odp: Przepychanie/most przez VPN

Takie coś? https://openwrt.org/docs/guide-user/net … ing_in_gre

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

10

Odp: Przepychanie/most przez VPN

No na razie tylko na to wpadłem. Może ktoś ma lepsze pomysły? Ale tak jak napisałem - najnowsze buildy są a 4.19 a ten Gre pakiet ma zależności na 4.14 i nie sposób go użyć sad

11

Odp: Przepychanie/most przez VPN

Źle piszesz. Po prostu masz zainstalować moduły od siebie skoro sam kompilowałeś a nie z repo openwrt.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

12 (edytowany przez imkebe 2020-03-27 21:00:23)

Odp: Przepychanie/most przez VPN

Cezary napisał/a:

Źle piszesz. Po prostu masz zainstalować moduły od siebie skoro sam kompilowałeś a nie z repo openwrt.

Ale ja to zrobiłem...

root@openwrt:~# opkg install /tmp/gre_1-12_all.ipk 
Installing gre (1-12) to root...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for gre:
 *      kernel (= 4.14.172-1-0894164cab0effc42201a29fec8ce33f)
 * opkg_install_cmd: Cannot install package gre.
root@openwrt:~# uname -a
Linux kokos 4.19.108 #0 SMP Tue Mar 24 14:42:52 2020 armv7l GNU/Linux

13

Odp: Przepychanie/most przez VPN

Eh, że też trzeba to każdemu w kółko tłumaczyć.

Nie, nie zrobiłeś. Próbujesz zainstalować pakiet gre które zależy m.in od kmod-gre i kmod-grep6. I te pakiety (moduły) masz zainstalować od siebie z buildu który skompilowałeś.  Teraz próbują się zainstalować z repo openwrt. Rozumiesz różnicę?

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

14 (edytowany przez imkebe 2020-03-27 21:09:56)

Odp: Przepychanie/most przez VPN

DEL smile

15

Odp: Przepychanie/most przez VPN

A teraz zgadnij od czego zależy kmod-gre6? od kmod-iptunnel, kmod-ip6-tunnel. I je też masz zaistalować ręcznie.  Jak ci wyskoczy błąd to instaluj zależności a nie lecisz dalej.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

16

Odp: Przepychanie/most przez VPN

Cezary napisał/a:

A teraz zgadnij od czego zależy kmod-gre6? od kmod-iptunnel, kmod-ip6-tunnel. I je też masz zaistalować ręcznie.  Jak ci wyskoczy błąd to instaluj zależności a nie lecisz dalej.

Już sprawdziłem... i zainstalowałem. Dzięki, weź z tego zrób jakiś przykład dot. zależności modułów i opkg/ipk.
A ja tutaj jutro opiszę co mi wyszło z tym GRE i zestawieniem mostu.

17

Odp: Przepychanie/most przez VPN

ciekawe czy by się dało osobnym tunelem wireguard przepchać protokół DHCP za pomocą pakietu isc-dhcp-relay-ipv4 zainstalowanym na routerach R2 i R3?
R2 i R3 byłyby tylko przekaźnikami DHCP dla swoich własnych sieci "Guest"
Miałbyś wtedy wszystkich klientów sieci "Guest" z dowolnego routera R1, R2, R3 w jednej klasie adresowej "Guest" z serwera R1.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

18 (edytowany przez imkebe 2020-03-30 23:14:07)

Odp: Przepychanie/most przez VPN

1. Czysty wireguard odpada nawet z DHCP Relay, ponieważ DHCP wymaga Multicast a WG jako protokół L3 nie ma takiej obsługi.
2. Analizowałem ponadto użycie IPIP ale z racji, że też działa na L3 odpadł.
3. Postawiłem tunel GRE w dedykowanym tunelu WG ale nie ma problemu aby poszło po już istniejącym. Nie testowałęm jeszcze jednak szczegółowo reguł firewalla w tym zakresie - tj. wszystko wrzuciłem w jedną strefę.
4. WG + GRE(TAP) adresuje mój case. Instrukcja i założenia.

Chcemy spiąć w jedną sieć na poziomie Ethernetu (L2) kilka odległych miejsc. Ma być komunikacja szyfrowana.
To można zrealizować z wykorzystaniem różnych rozwiązań m.in. IPSEC, OpenVPN (TUN/TAP) ale ja chciałem coś lekkiego bo maszyny na końcówkach nie są mocne. Wybór pada na Wireguarda, dodatkowo dlatego, że ma model point-multipoint - czyli spinamy na jednej konfiguracji wg kilka zdalnych lokalizacji.

Potrzebujemy jednak wewnątrz naszego VPN (wireguard) jakiegoś protokołu enkapsulacji dla warstwty 2 OSI. I tutaj przychodzi nam GRE. Nie ma niestety konfiga w LuCI ale konfig jest banalny.
Mamy 4 opcje protokołu (co wpływa na wydajność [narzut]) - gre, grev6, gretap, gretapv6 - https://openwrt.org/docs/guide-user/net … _protocols

/////// R1 ////////

config interface 'wg1'
        option proto 'wireguard'
        option private_key 'abcdef'
        option listen_port '51820'
        list addresses '192.168.50.1' // adres IP sieci wireguard R1

config wireguard_wg1
        option description 'peer-r2'
        option public_key 'xxxx'
        list allowed_ips '192.168.50.2/32' // zezwól na ruch z peera
        option route_allowed_ips '1'
        option endpoint_host 'r2.acme.com'
        option endpoint_port '51820'
        option persistent_keepalive '25'

config interface 'tun10'
        option proto 'gretap' // ja chce IPv4 na poziomie L2
        option peeraddr '192.168.50.2' // wykorzystujemy adres wireguard peera jako bramę do zdalnejkońcówki tunelu GRE
        option ipaddr '192.168.50.1' // wykorzystujemy adres lokalnego interfejscu wireguard do lokalnej końcówki tunelu GRE

config interface 'guest' // definicja dowolnego interfejsu
        option proto 'static' // statyczny (bo serwer)
        option type 'bridge' // u mnie jest akurat most dla WiFi
        option ifname '@tun10' //tutaj najwazniejsze - alias do końcowki tunelu GRE (nazwa interfejsu GRE)
        list ipaddr '192.168.5.1/24' // u mnie adresacja serwera DHCP na R1

/////// R2 ////////

config interface 'wg1'
        option proto 'wireguard'
        option private_key 'abcdef'
        option listen_port '51820'
        list addresses '192.168.50.2' // adres IP sieci wireguard R2

config wireguard_wg1
        option description 'peer-r1'
        option public_key 'xxxx'
        list allowed_ips '192.168.50.1/32' // zezwól na ruch z peera
        option route_allowed_ips '1'
        option endpoint_host 'r1.acme.com'
        option endpoint_port '51820'
        option persistent_keepalive '25'

config interface 'tun10'
        option proto 'gretap' // ja chce IPv4 na poziomie L2
        option peeraddr '192.168.50.1' // wykorzystujemy adres wireguard peera jako bramę do zdalnej końcówki tunelu GRE
        option ipaddr '192.168.50.2' // wykorzystujemy adres lokalnego interfejscu wireguard do lokalnej końcówki tunelu GRE

config interface 'guest' // definicja dowolnego interfejsu
        option proto 'dhcp' // pobieramy adresacje z serwera R1
        option type 'bridge' // u mnie jest akurat most dla WiFi
        option ifname '@tun10' //tutaj najwazniejsze - alias do końcowki tunelu GRE (nazwa interfejsu GRE)

Architektura sieci

192.168.5.0/24 - [ethX] - 192.168.5.1/32 - [wg1] - 192.168.50.1/32 - [tun10][gretap]  =====  [gretap][tun10] - 192.168.50.2/32 - [wg1] - 192.168.5.x/32 - [ethX] - 192.168.5.0/24

Taka konfiguracja pozwala na multicast, unicast itp. W zasadzie mamy sieć ethernet (nawet można VLAN-y upakować) rozpiętą na dwie lub więcej zdalnych lokalizacji. Wszystko zapakowane w tunel wireguarda.

Plusy :
- natywne protokoły, obsługa obecnie praktyczine każdego OS
- lekki, szybki ale solidny tunel VPN
- mozna w tym modelu uruchomić jakieś cieżkie usługi, które inaczej by nie poszły na słabym sprzęcie (poprzez nasze proxy [R1])

Minusy:
- wymaga pełnej konfiguracji na peerach
- narzut protokołu / mniejsza przepustowość (MTU)

19 (edytowany przez gonzales 2022-01-27 20:05:22)

Odp: Przepychanie/most przez VPN

Czy pakiet gre to "najprostsze" rozwiązanie na utworzenie sieci LAN z jedną adresacją połączoną poprzez wireguard?



Jeżeli dobrze zrozumiałem to tworzę nowy interfejs GRE wykorzystujący protokół gretap.
Czy adresacja tego interfejsu jest dowolna czy ma być tożsama z adresacją wireguard?
Raczej ma być inna i różna od LAN zarówno po stronie serwera i klienta wireguard.

I tutaj @imkebe utworzył kolejny interfejs o nazwie "guest", czy on jest niezbędny?
Chyba tak bo musimy podać nazwę interfejsu GRE.

Dodatkowo u @imkebe router R2 pobiera adresację z DHCP routera R1.
Jak należy to skonfigurować, jeżeli u mnie serwer wireguard jest za NAT-em?

20 (edytowany przez gonzales 2022-01-27 20:08:43)

Odp: Przepychanie/most przez VPN

Czyżby nikt oprócz @imkebe nie przerabiał tego GRE?

Proszę o wskazówki w temacie poprzedniego mojego posta.

21

Odp: Przepychanie/most przez VPN

na kilka Twoich pytań masz już odpowiedź w poście @imkebe:

gonzales napisał/a:

"Czy adresacja tego interfejsu jest dowolna czy ma być tożsama z adresacją wireguard?
Raczej ma być inna i różna od LAN zarówno po stronie serwera i klienta wireguard."

config interface 'wg1'
        option proto 'wireguard'
        ...
        list addresses '192.168.50.2' // adres IP sieci wireguard R2
...

config interface 'tun10'
        option proto 'gretap' // ja chce IPv4 na poziomie L2
        option peeraddr '192.168.50.1' // wykorzystujemy adres wireguard peera jako bramę do zdalnej końcówki tunelu GRE
        option ipaddr '192.168.50.2' // wykorzystujemy adres lokalnego interfejscu wireguard do lokalnej końcówki tunelu GRE

Przeanalizuj adresy do czego podpięty jest ten tunel GRE

dodatkowo jeżeli serwer WG masz za NAT-em to dalej zależy:
1. czy na tym serwerze WG wisi cała Twoja sieć LAN. Czy to jest również serwer DHCP dla hostów w LAN?
2. czy ten serwer WG będąc za NAT-em jest tylko zwykłym hostem w sieci LAN głównego routera, bo to bardziej komplikuje sytuację.

Serwer WG za NAT-em to odstępstwo od ogólnej normy, a więc należy zrobić ciut więcej rzeczy żeby to skonfigurować.
Tematów z rozwiązaniami na tym forum jest klika. Poszukaj.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

22 (edytowany przez gonzales 2022-01-28 12:12:20)

Odp: Przepychanie/most przez VPN

Sęk w tym, że serwer wireguard jest zwykłym hostem. Jak ustawiłem GRE na adresacji wg to niby jakieś pakiety przechodzą. Ale utworzyłem (czy sam się utworzył) jeszcze jakiś interfejs alias gretap4 i tutaj w związku z tym że jak to zauważyłeś jest to bardziej skomplikowane leżę. Na tym forum podpowiedzi nie znalazłem a robiąc na podstawie innych przykładów z neta sukcesu brak. Router bez openwrt jak router brzegowy i NAT mocno komplikuje mi życie. Nic to będę szukał tych przykładów o których piszesz.

A może prościej będzie zrobić tak. Skoro router z openwrt jest głupim AP to na nim uruchomić serwer DHCP i NAT a router główny jako AP? Tylko router główny obsługuje połączenie poprzez PPPoE. Jest coś takiego możliwe?

23

Odp: Przepychanie/most przez VPN

Skoro wireguard za NAT-em Ci działa, bo już to robiłeś w innym temacie smile
https://eko.one.pl/forum/viewtopic.php? … 30#p260730

To podpinasz się tym gretapem pod końcówki tunelu.
@imkebe zrobił interface "guest" z bridgem bo jak jest przez niego napisane, potrzebował również hostów po Wifi.
Zapewne w konfigu od wifi musiał utworzyć nowy SSID i pokazać mu, żeby działał na sieci "guest". Tak sądzę.
Aby działał routing to sieć "guest" zapewne ma inny adres sieci niż pozostałe LAN-y na poszczególnych routerach (klientach WG).

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

24 (edytowany przez gonzales 2022-01-28 12:50:14)

Odp: Przepychanie/most przez VPN

mar_w napisał/a:

Aby działał routing to sieć "guest" zapewne ma inny adres sieci niż pozostałe LAN-y na poszczególnych routerach (klientach WG).


No ale jezeli LAN-y na routerach mają inną adresację i na sieci guest utworzę jeszcze inna adresację to skąd hosty, które chcę aby były w jednej sieci pobiorą sobie IP. Serwery DHCP wtedy nie biorą udziału w adresowaniu hostów?

Powinienem zrobić bridge pomiędzy guest a LAN-ami? Pewnie nie bo LAN-y mają inną adresację.

25 (edytowany przez mar_w 2022-01-29 00:03:28)

Odp: Przepychanie/most przez VPN

Przecież @imkebe to wszystko opisał.
Sieci LAN na routerach to 192.168.(2,3,4).0/24 w zależności od routera.
Sieć WG to 192.168.50.0/24
Sieć Guest to 172.16.0.0/24 (tak sądzę bo wyżej podał same adresy bez maski)

Na R1 ma serwer DHCP dla LAN-R1 oraz SERWER DHCP dla Guest.
Na R2 ma serwer DHCP dla LAN-R2 i klienta DHCP dla Guest.
Na R3 ma serwer DHCP dla LAN-R3 i klienta DHCP dla Guest.

To widać. Czego nie rozumiesz?
Klienci Guesta dostaną adresy z serwera DHCP Guest z R1 bo tunel jest L2 (tap a nie tun).
Hosty w Guest to inne hosty niż te z LAN.
Miało nie być mieszania ruchu i nie ma.
Chcesz mieć wymianę między LAN-R2 i Guest lub LAN-R3 i Guest to trzeba zezwolić na forward między wyżej wymienionymi.
Czego nie rozumiesz?

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *