Na wydajność wpłw ma MTU pobaw się tym może? A za tym rozmiary pakietów i ich ilość, rodzaj transmisji. Jak to testujesz? iperf? tcp/udp wewnątrz tunelu?

Sprzęt na jakiej to działa ma kolosalne znaczenie. Czasami OpenVPN może działać lepiej bo np. masz sprzętowe wsparcie instrukcji AES i szyfrowanie nie stanowi problemu. A crypto wireguarda nie jest zazwyczaj przyspieszane ale w działaniu czysto softwareowym jest dużo szybsze niż takie AES256 - czyt. tak malina może nie unieść tego.

Ja na swoim QCA IPQ8064 na openwrt osiągałem na OpenVPN 130-170Mb/s dla AES256 przy dobrym tuningu (to jest bez wsparcia NSS core do sprzętowego offloadingu).

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)

DEL

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ć

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)

Wracając do rozwiązania. Musiałem zrobić hard restart. Następnie wgrałem nowy firmware.

A coś w stylu podmontowanie USB i przekierowanie polecenia sysupgrade na podmontowany zasób ?

Ale to nie jest tak, że jak inicjuje połączenie z zewnątrz to połączenie jest zwrotnie tą samą trasą? To pakiedy wchodzą przez WAN a wychodzą zawsze po VPN ?

Ja mam 1 server dla dostępów ad-hoc (na dwie konfiguracje TCP i UDP - czyli dwie konfiguracje), 2 server point-to-point, oraz 1 client NordVPN. Razem 5 urządzeń tun. Najważniejsze - każdy serwis ma swój interfejs tun i inne porty.