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)