Szia Windows 7 esetében nekem csak a 32bites rendszeren voltak ilyen problémáim. Windows 10 (64bit) nem tapasztalom. A megoldás nekem az lett, hogy a Windows 7 elé tettem egy OpenWRT-s eszközt, és a VPN címtartományára állítottam tűzfal szabályt, hogy Wireguard-on keresztül menjen.

A másik problémádnál: a DNS által feloldott IP cím milyen gyorsan frissül? Nálam csak addig állnak meg a dolgok, amíg a névfeloldás új beállításai szét nem terjednek. Ha ez sok idő nálad, akkor érdemes tailscale-re váltanod, hogy ne függj a változó IP címektől.

Még mindig tűzfal gondod van, milyen szabályok vannak benn?

64 bites Win7-ről van szó, több helyen is próbáltam. Külföldi fórumokon is keresgéltem, volt is erről szó, de akkor annyival elintézték, hogy ez a windows hibája. Win10 alatt is hasonló történik, csak nem olyan látványosan, de a registrybe szemetel... de ezek szerint nem sokan ismerik ezt a problémát.

Az IP változást elvileg könnyedén kellene tudni kezelnie a wireguardnak, hiszen ezzel is reklámozzák, hogy mobil eszközön sem szakadnak meg a kapcsolatok, akkor is ha minden változik. A gyakorlat viszont az, hogy ez csak addig működik jól, amíg legalább az egyik oldal fix IP című. Persze az is lehet, hogy csak a mikrotik implementációban van ez a bug. De elég sokan használnak scriptet a wg interfész újraindítására mikrotiken...

Persze a hibái ellenére is tök jó a wg, és talán egyszer kiforrja magát.

Nem, ez szándékosan van így és nem csak mikrotiken. A dolog akkor működik jól, ha van pl egy fix IP-s szervered és erre csatlakozol bárhol a világban a mobiloddal. Ekkor akár lépkedhetsz mobilon mobilnet és wifi közt, menni fog, mivel a mobillal a szerver IP-je felé küldessz csomagot, így az megérkezik oda, a wireguardot pedig nem érdekli a forrás IP, hogy honnan jött a csomag, hanem azt nézi, hogy vissza tudja fejteni a kulcsával, s ha igen, akkor válaszol rá a feladónak.

Viszont ha pl egy dinamikus IP szerverhez kapcsolódsz és van hozzá DDNS cím, akkor csak a kapcsolat felépítésekor fogja feloldani az IP-t és végig azon fog próbálkozni. UDP, szóval abszolút stateless a dolog, fogalma sincs, hogy a távoli IP-n már rég nem fut wireguard, lelkesen küldi oda a csomagokat.

Sokan emiatt valóban folyamatosan pingelik szkriptekkel a hosztokat, vagy wg-ben állítanak persistentkeepalive-t és azt nézik, hogy ez megtörténik-e gyakran stb.

Más megoldás nagyon nincs.

Kiforrni meg nem hiszem, hogy kiforrja magát, direkt ilyen egyszerű az egész és szerintem ez nem is baj. Én csak az L2-t hiányolom, de kétlem, hogy valaha is lesz. Már a multicast ötletét is elvetette Jason.

[ Szerkesztve ]

A wg nem kliens-szerver alapú, hanem egyenrangú a két oldal. Ez alapján elvileg bármelyik oldal IP címe változhat. Persze ha az egyik oldalon nincs megadva a másik oldal IP-je vagy domén neve, akkor az nem tudja kezdeményezni a kapcsolatot. Viszont nekem olyan kapcsolat is szokott megszakadni, ahol mindkét oldalon meg van adva a domén név, és persze ugyanúgy megjavul az újraindítástól. A működés filozófiájába nem illik bele ez a megszakadás, szerintem csak egy bug, vagy egy nem jól kidolgozott részlet.

Én is erre gondolok, de nem jövök rá hogy hogyan lehet megcsinálni a megfelelő tűzfal és routeing szabályokat. Jelenleg ennyi a tűzfal:

config defaults
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option synflood_protect '1'
config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    list network 'lan'
config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'
    list network 'wan'
    list network 'wg0'
config forwarding
    option src 'lan'
    option dest 'wan'
config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'
config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'
config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'
config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'
config rule
    option name 'Allow-MLD'
    option src 'wan'
    option proto 'icmp'
    option src_ip 'fe80::/10'
    list icmp_type '130/0'
    list icmp_type '131/0'
    list icmp_type '132/0'
    list icmp_type '143/0'
    option family 'ipv6'
    option target 'ACCEPT'
config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'
config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'
config rule
    option name 'Allow-IPSec-ESP'
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'
config rule
    option name 'Allow-ISAKMP'
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'
config redirect
    option dest 'lan'
    option target 'DNAT'
    option name 'SSH'
    list proto 'tcp'
    option src 'wan'
    option dest_ip '10.13.6.1'
    option src_dport '4173'
    option dest_port '4173'
config redirect
    option dest 'lan'
    option target 'DNAT'
    option name 'luci'
    list proto 'tcp'
    option src 'wan'
    option src_dport '80'
    option dest_port '80'
    option dest_ip '10.13.6.1'

Semmi extra, egy luci és egy ssh van nyitva. Ezeket Én vettem fel.

Nem értem rá a témával foglalkozni a munkahelyi dolgaim miatt. Most viszont én is megszenvedtem egy site-to-site vpn-nel. A tűzfal résszel minden rendben volt, de valamiért nem mentek át a csomagok a wireguard alagútján.
Kiindulás ez volt:
Nálam mikrotik hAP ac2 (RouterOS 7.5):
* wan: 192.168.0.2/27
* lan: 10.40.7.1/27
* wg: 172.16.222.150/24
AllowedIps = 172.16.222.0/24

Máshol archer C20i (openwrt-22.03):
* wan: 192.168.1.150/24
* lan: 10.3.40.1/27
* wg: 172.16.222.120/24
AllowedIps = 172.16.222.0/24

Felhőben virtualbox (Ubuntu 22.04.1):
* wg: 172.16.222.1/24
# A klienseknek megfelelően az AllowedIps.
AllowedIps = 172.16.222.150/32
AllowedIps = 172.16.222.120/32

Amit meg akartam oldani, hogy a 10.40.7.0/27 hálózatból el tudjam érni a 192.168.1.0/24 és 10.3.40.0/27 hálózatban lévő gépeket. A 172.16.222.0/24 hálózaton ment a ping minden irányba. A mikrotik-en felvettem az AllowedIps közé az a másik hálózat IP tartományát és ugyanezt visszafele is az archer-en. Valamint a route-okat az egyik hálózatból a másik wg interfész címére.
* mikrotik: AllowedIps = 172.16.222.0/24,192.168.1.0/24,10.3.40.0/27
* archer: AllowedIps = 172.16.222.0/24,10.40.7.0/27
A route szabályokat nem írom ki.

Ekkor még nem ment a ping. A traceroute pedig azt írta, hogy az első hop (172.16.222.1) még sikeres, viszont utána timeout.
...
Itt kellett visszaemlékezni az általam leírt sorokra: "...és csak olyan csomag fog a hálózati csatolón megjelenni az alagút túloldalán, amelynél a forrás IP és a titkosítási kulcs is megfelelő. Ezt hívják kriptokulcs alapú forgalom irányításnak."

Tehát hiányzott még egy-egy módosítás a virtualbox gépen:
AllowedIps = 172.16.222.150/32,10.40.7.0/27
AllowedIps = 172.16.222.120/32,10.3.40.0/27,192.168.1.0/24

Ezek után működött a ping a 10.40.7.0/27 hálózatból a 192.168.1.0/24 és 10.3.40.0/27 hálózatba. Valamint az archer-ről a 10.40.7.0/27-ba is ment a ping.
Összegezve:
Meg kell azt nézni, hogy a wireguard alagútba bejutó csomagok átjutnak-e és az AllowedIps hiány miatt nem dobódnak-e el. A traceroute segíteni fog.

Napi szinten használva, nekem eddig pozitiv. Egyszerübben belehetett állitani, mint az openvpn-t szerintem. Mobilról is egy kattintás és már otthoni dolgokat simán láthatom.

Esetleg egy kis segítségre lenne szükségem. Valahol elakadt a dolog.
Készítettem egy kb topológiát. [kép]
A routeren Padavan fw, B routeren DD-WRT fw fut.

Cél az lenne, hogy a B router becsatlakozzon az A router alá. Ehhez egy Rapsberry pi-n fut a wireguard server.
Szeretném, ha el tudnám érni a B routeren lévő eszközöket A routerről, és vissza is.

A B routerből szépen látom az A alattiakat, viszont visszafele már a B routert se tudom pingelni, nem hogy ami mögötte van.

wg0.conf (server config)
[Interface]
PrivateKey = ***************
Address = 10.6.0.1/24
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 4****
### begin client01 ###
[Peer]
PublicKey = **************************
PresharedKey = ***********************
AllowedIPs = 10.6.0.10/32
PersistentKeepalive=25
### end client01 ###

Garázs router CLIENT(peer) configja

[Interface]
PrivateKey = x*************
Address = 10.6.0.10/24
DNS = 8.8.8.8, 8.8.4.4
[Peer]
PublicKey = *******************h=
PresharedKey = *****************
Endpoint = ****************org:4****
AllowedIPs = 10.6.0.0/24,192.168.100.0/24
PersistentKeepalive=25

A poén az, hogy ugyan ezekkel a configokkal egy Open-wrt rendszer tökéletesen működik, oda vissza.
Ebből kifolyólag valamlyen firewall problémára gondolok, ugyanis OPENWRT alatt tudtam beállítani zone forwardot, de DD-wrt-n ezt nem találom.

A problémád ott van, hogy nincsenek meg a route szabályok a B hálózat felé.

B irányból a wireguard létrehozza a route szabályt linuxon, ami megy a raspberry pi-re. Ott van a NAT szabály, tehát minden ami 'B'-ből jön úgy fog látszódni, mintha a raspberry-ről jönne. A raspberry pedig tudni fogja, hogy amit az A oldalon kap választ, azt hová kell visszaküldenie (NAT tábla).

Az A oldal felől viszont senki nem tudja, hogy van egy másik hálózatod. Az 'A' router-en létre kellene hozni egy route szabályt, ami a raspberry-re mutat ha a B hálózatra megy a forgalom. A raspberry-n elég ha felveszed az AllowedIPs közé a másik hálózatot, és akkor már hozzá fogja adni a route szabályt is.

Ez már kb 95%, és csak az marad ki, hogy kell e a B oldalon is egy tűzfal szabály vagy nem. Illetve hogy a raspberry továbbítja e a forgalmat.

Köszi.

A routeren van static route beállítva a wireguard peerekhez.

A raspberry-n elég ha felveszed az AllowedIPs közé a másik hálózatot, és akkor már hozzá fogja adni a route szabályt is.

Ez alatt a server configban a peer alatti allowed ipt érted?

[ Szerkesztve ]

Az A (192.168.100.1) eszközön kell egy route szabály, ami a 192.168.101.0/24-et a 192.168.100.222-re irányítja. Most szerintem kimegy az internet felé, ezért nem látod.
A raspberry-n (ez neked akkor a szerver) pedig kell az allowed listába a 192.168.101.0/24. Raspberry esetén ez hozzáadja a route listához, ott már nem kell.

Köszönöm.
Kettő dolgot kellett még csinálnom. Most működik.
DD-wrt TUNNEL fül alatt, ahogy a wireguard peer config van, van egy FIREWALL INBOUND opció. Ezt ki kellett kapcsolnom, illetve átírtam a wg0.conf (server config) fájl ahogy te javasoltad.
[Interface]
PrivateKey = ***************
Address = 10.6.0.1/24
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 4****
### begin client01 ###
[Peer]
PublicKey = **************************
PresharedKey = ***********************
AllowedIPs = 10.6.0.10/32, 192.168.101.0/24
PersistentKeepalive=25
### end client01 ###
ÉS így már működik

[ Szerkesztve ]

Segítséget szeretnék kérni, bizonyára valami banális hibát vétek, de nem találom a megoldást.

Van egy win10-es wireguard szerver és egy androidos telefon ami a kliens.
Mindkettő tudja egymást pingelni, de a telefon nincs internet és nem is látja a lan hálózaton lévő többi eszközt, amikor a wireguard aktív.
A routeren természetesen nyitva van a 5555-ös port.

win10 Szerver config:
[Interface]
Address = 10.10.10.1/24
ListenPort = 5555
PrivateKey = SPWa0HdyGtjZip8p1W34NdCa9P1asOifCsO2J5pEXHs=
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = xSKTK7BISKmsQtVzqdUPlk1wTdQeVjEbm0OL4ntnhiA=
AllowedIPs = 10.10.10.2/32


Android kliens config:
[Interface]
Address = 10.10.10.2/24
ListenPort = 5555
PrivateKey = 8FIiTYuPQtFR3gCrtzE70TQx2a7I9rcloR+R//zg0lU=
[Peer]
PublicKey = UU58q/cMgtvfk/XDv3Pt+3VPiaN283L23Q+TbL9vuD4=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = default.ddns.net:5555

A cél az lenne, hogy mindegy hogy a telefon mobil neten vagy céges wifi-n van, minden adatforgalma a tunelen keresztül az otthoni interneten menjen ki a netre.

(a portok, a privát és a publikus kulcsok, természetesen csak a példa kevéért vannak itt.)

Üdv!

Ami hiányzik a setupodból, az a szerver oldali NAT. Windows 10-en tudtommal nincs iptables parancs, szóval a PostUp és PostDown parancsok sosem futnak le hiba nélkül. Win szerverre találtam egy ilyen leírást: [link]

Azt sajnos nem tudom, hogy ez win10-en is mehet-e.

@Mr Dimi, köszi a gyors választ, így akkor dobom a windows-os ötletet.

Viszont szeretném megkérdezni, hogy az a felállás működhet-e, hogy jelenleg van egy router és arra vezetékkel kötve egy win10-es asztali gép.

Ha kettő közé beiktatnék egy tplink routert amin openwpn-n van és arra a tplink routerre kerülne a wireguard, akkor azt távolról elérném és tudnék rá csatlakozni ?

Amiatt kérdezem, hogy ha a telefonommal wireguard használatával felcsatlakoznom az otthoni netre (felső példa esetében a tp linkre), akkor a telefon wireguard-on kapja a netet, mint egy biztonságos VPN.

Ez működhet ?

Persze, működhet. Gondolom openwrt-t akartál írni. Ha már eleve van egy router, akkor a tp-linken letiltanám a DHCP-t, hogy ne legyen dupla NAT. Aztán kapjon valami fix IP-t tp-link a másiktól, válassz egy tetszőleges UDP portot a wireguardnak, lődd be a tp-linken, esetlegesen egy dinamikus dns-t is, aztán a másik routeren legyen port forward. Nézd meg, hogy a szolgáltatód nem-e natol, ha nem, akkor csatlakozhatsz is a VPN-edhez pl mobilnetről. Ha megy, akkor minden rendben.

Igen OpenWRT-t akartam, de későn vettem észre és már nem tudtam szerkeszteni.

Köszönöm, hogy megerősítetted, hogy akkor ez működő koncepció lehet.

Válaszolva a #18831-re, akkor a legegyszerűbb, ha felteszed a luci-app-wireguard és a luci-proto-wireguard csomagokat (lehet az elsőnek függősége a második, és azt is magával rántja). Innen pedig létrehozod az új interfészt, és azt már be tudod állítani a logout írás alapján.

Más: Ha lesz egy kis időm, akkor elkészítem mikrotikre is az írást.

Köszönöm.

A leírás szerint be is configoltam, de valamiért a telefonon nincs internet és LAN-t sem látja.

A router tudja pingelni a telefont és fordítva is, de mintha ezentúl semmi kommunikáció nem lenne a kettő eszköz között.

Erre valakinek van ötlete, hogy mi lehet a gond ?

Akkor ott esélyesen routing probléma lesz, vagy a tűzfal fogja meg a forgalmat. Engedélyezett IP-k kliens oldalon mik? 0.0.0.0/0? Routeren van NAT beállítva rendesen? Tűzfalon nincs valami drop szabály, ami a wireguard interfacere is vonatkozik? Konfig nélkül nehéz megmondani, hol a hiba.

Szia, egy NAT szabály kell a VPN irányából a WAN irányba. Ezt nem tartalmazza a leírás, mert nem a teljes forgalom irányításáról szól, csak a tunnel felépítéséről.

Internet --> asus router --> tplink router (openwrt+wireguard)

Ebben az elrendezéseben az asus routeren nyitottam portot és forwaldoltam a tplink routerre ha erre gondoltál. Ennek hiányában a telefon nem is tudna össze kapcsolódni a tplink routeren a wireguard szerverrel.

Igen a telefonon 0.0.0.0/0 van

Szia!

Gondolom ezt a tplink routeren az openwrt-ben kell elvégeznem, erről tudsz kicsit többet írni, hogy mit és hol csináljak ?

Köszönöm.

most látom, hogy a system log-ban végén vagy egy ilyen sor:

Thu Aug  3 21:40:00 2023 cron.err crond[1506]: USER root pid 2644 cmd /usr/share/wginstaller/wg.sh cleanup_wginterfaces

A wireguard interfész beállításainál átváltasz a tűzfal beállításaira és létrehozol egy vpn tűzfalzónát, amibe az interfész forgalma fog tartozni.

Majd a tűzfal szabályoknál a maszkolást kell megcsinálni az alábbiak szerint, hogy a forgalmad a wireguard hálózatból úgy tűnjön, mintha az openwrt eszközről indulna. A 3. szabályt kell létrehoznod (nem a bekeretezettet).

Ha ez megvan, akkor a LAN hálózaton lévő eszközöket is tudod pingelni majd. A WAN oldalhoz pedig módosítsd az első szabályt.

Akkor valahol itt lesz a gond, mert nekem a wireguard, valamiért egyben van a wan portokal.

[ Szerkesztve ]

Dupla post, maitt ezt lehet törölni.

[ Szerkesztve ]

Beállítottam úgy ahogy nálad is láttam, de a telefonon továbbra sincs net. A pingelés mindkét irányba zavartalan.

Valamit elrontottam, vagy kihagytam ?

Ha már van ping, akkor félig már a jó úton vagy.
A WAN port-on most van internet? (tehát ha az openwrt eszközről pingeled a 8.8.8.8-at akkor van válasz rá?) Vagy csak a LAN van bedugva DHCP nélkül?
Mert ha a WAN port a kijárat, akkor a 3. szamályhoz a lan mellé még a wan-t is add hozzá. Ha nem az a kijárat, akkor még gondolkodnom kell.

Sziasztok!

Raspberry Pi-n hazsnálom a wireguard szervert. El is érem telefonról, lan-t látja is, de internet nincs rajta. Közvetlenül a raspberry-n van természetesen internet. Mire utalhat ez?

2 dolog:
* telefonon 0.0.0.0/0-val kell felvenned a raspberry pi peer-t
* Pi-n engedélyezni kell a forwarding-ot és kell egy nat-masquearade tűzfal szabály.

az első elvileg adott, viszonta 2-est tudnád esetleg részletezni? Nézegetem a különböző hivatalos leírásokat, de nem nagyon jön ez szóba...

[link] Ezt kell megcsinálni, csak a wlan0 interface helyett wg0 kell.

közben sikerült, köszi

mod: most nézem, hogy ponet ez alapján sikerült még este 11-kor megcsinálni

[ Szerkesztve ]

Esetleg leírod ide is a lépéseket, hogy te hogy csináltad? Hátha másnak is kellene. Bár lehet elég az általam mellékelt cikk.

gyakorlatilag 1 az egyben ezt csináltam meg, és jó lett