Hirdetés
- Random25: Windows 11 telepítés Pendriveról
- Luck Dragon: Asszociációs játék. :)
- vrob: Az utolsó DOS játékok 1996 - 1997-ben, egy korszak lezárul
- sziku69: Fűzzük össze a szavakat :)
- Lenry: Melléképületblog - 4. rész - Kocsibeálló
- sziku69: Szólánc.
- Elektromos rásegítésű kerékpárok
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Segway-Ninebot F3 E elektromos roller.
- Brogyi: CTEK akkumulátor töltő és másolatai
Új hozzászólás Aktív témák
-
stopperos
senior tag
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. -
Yerix
tag
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
-
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.
-
Yerix
tag
válasz
stopperos
#40
üzenetére
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 ?
-
stopperos
senior tag
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.
-
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.
-
Yerix
tag
@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 ?
-
sub
-
-
Yerix
tag
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/24ListenPort = 5555PrivateKey = SPWa0HdyGtjZip8p1W34NdCa9P1asOifCsO2J5pEXHs=PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEPostDown = 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/24ListenPort = 5555PrivateKey = 8FIiTYuPQtFR3gCrtzE70TQx2a7I9rcloR+R//zg0lU=[Peer]PublicKey = UU58q/cMgtvfk/XDv3Pt+3VPiaN283L23Q+TbL9vuD4=AllowedIPs = 0.0.0.0/0, ::/0Endpoint = default.ddns.net:5555A 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.) -
Shummo
senior tag
válasz
stopperos
#32
üzenetére
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/24PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEPostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADEListenPort = 4****### begin client01 ###[Peer]PublicKey = **************************PresharedKey = ***********************AllowedIPs = 10.6.0.10/32, 192.168.101.0/24PersistentKeepalive=25### end client01 ###
ÉS így már működik -
stopperos
senior tag
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. -
-
stopperos
senior tag
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.
-
Shummo
senior tag
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/24PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEPostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADEListenPort = 4****### begin client01 ###[Peer]PublicKey = **************************PresharedKey = ***********************AllowedIPs = 10.6.0.10/32PersistentKeepalive=25### end client01 ###Garázs router CLIENT(peer) configja
[Interface]PrivateKey = x*************Address = 10.6.0.10/24DNS = 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/24PersistentKeepalive=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. -
stopperos
senior tag
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/24AllowedIps = 172.16.222.0/24Máshol archer C20i (openwrt-22.03):
* wan: 192.168.1.150/24* lan: 10.3.40.1/27* wg: 172.16.222.120/24AllowedIps = 172.16.222.0/24Felhőben virtualbox (Ubuntu 22.04.1):
* wg: 172.16.222.1/24
# A klienseknek megfelelően az AllowedIps.AllowedIps = 172.16.222.150/32AllowedIps = 172.16.222.120/32Amit 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/27AllowedIps = 172.16.222.120/32,10.3.40.0/27,192.168.1.0/24Ezek 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. -
yodee_
őstag
válasz
stopperos
#22
üzenetére
É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 defaultsoption input 'ACCEPT'option output 'ACCEPT'option forward 'REJECT'option synflood_protect '1'config zoneoption name 'lan'option input 'ACCEPT'option output 'ACCEPT'option forward 'ACCEPT'list network 'lan'config zoneoption 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 forwardingoption src 'lan'option dest 'wan'config ruleoption name 'Allow-DHCP-Renew'option src 'wan'option proto 'udp'option dest_port '68'option target 'ACCEPT'option family 'ipv4'config ruleoption name 'Allow-Ping'option src 'wan'option proto 'icmp'option icmp_type 'echo-request'option family 'ipv4'option target 'ACCEPT'config ruleoption name 'Allow-IGMP'option src 'wan'option proto 'igmp'option family 'ipv4'option target 'ACCEPT'config ruleoption name 'Allow-DHCPv6'option src 'wan'option proto 'udp'option dest_port '546'option family 'ipv6'option target 'ACCEPT'config ruleoption 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 ruleoption 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 ruleoption 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 ruleoption name 'Allow-IPSec-ESP'option src 'wan'option dest 'lan'option proto 'esp'option target 'ACCEPT'config ruleoption name 'Allow-ISAKMP'option src 'wan'option dest 'lan'option dest_port '500'option proto 'udp'option target 'ACCEPT'config redirectoption 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 redirectoption 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.
-
ekkold
őstag
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.
-
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.
-
ekkold
őstag
válasz
stopperos
#21
üzenetére
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. -
stopperos
senior tag
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.
-
yodee_
őstag
válasz
stopperos
#12
üzenetére
Jelenleg addig szenvedtem el magam, hogy az openwrtre kötött eszközök elérik a mikrotik hálózatot és a mikrotiról elérem az openwrt-t. Viszont az openwrt eszközökön nincs internet elérés. Mi lehet a gond?
config interface 'wg0'option proto 'wireguard'option listen_port '13236'list addresses '10.13.250.2/30'option private_key '***************************'config wireguard_wg0option description 'WG-Yodee'option public_key '****************************'list allowed_ips '0.0.0.0/0'option route_allowed_ips '1'option endpoint_host 'host.dyndns.org'option endpoint_port '13236'A wireguard interface-t a WAN tűzfal zónába tettem.
-
ekkold
őstag
Mikrotik-mikrotik, és mikrotik - windows kliens között is használok wireguardot elég régóta.
Win7 esetében a wireguard minden indításkor új interfészt hoz létre (nem azt használja amit korábban létrehozott. Így egy idő után tele lesz a registry halott interfészekkel. Úgy tudom Win10 esetén is hasonló a helyzet, csak kevésbé látványos. Erre létezik valamilyen megoldás?
A másik amit tapasztaltam, hogy a dinamikus IP-hez rendelt hosztnevek esetében, amikor változik az IP, azt nem követi a Wireguard, azaz megszakad a kapcsolat, és csak a Wireguad kapcsolat ujraindítása után áll össze újból. Magyarul a kapcsolat megszakadásakor nem frissíti a hosztnevekhez tartozó IP-t. A mikrotiken ez megoldható, ha készítünk rá valamilyen szkriptet, de ez nem túl elegáns megoldás. Van erre valami jobb megoldás?
Esetleg elképzelhető, hogy ezek a hibák javítva lesznek, vagy már van is rá megoldás, csak én nem ismerem? -
PistiSan
addikt
válasz
stopperos
#12
üzenetére
Véletlen válaszra mentem, új hozzászólást akartam. :(
Tailscale-el kapcsolatban, ha már említetted a cikkben, felmerült bennem, hogy más helyi hálózaton lévő eszközt el lehet e érni valahogy.
Rákeresve van leírás a tailscale oldalán, a 3 lépés végrehajtása után, sima local ip címen elérem az összes eszközömet, nagyon durva. A 20 eszközös limitből így csak 1-et használ el. Egyenlőre a szolgáltató megbízhatósága a kérdés számomra, bár ha google fiókkal lépsz be, akkor adott a 2 lépcsős azonosítás. Kicsit félek, hogy rajtuk keresztül, ha meghackelik őket, bejöhet akármi is, bár ha saját magad hostolod a szervert a WireGuard-nak, azt is megnyomhatják. -
stopperos
senior tag
Köszönöm a korrekciót, én nem foglalkozom telefon root-tal, és emiatt nem is mélyedtem el ebben a témában. De ez megér egy frissítést.
#6 sztanozs: Én azt a gyümölcsös világot csak külső szemlélőként figyelem meg. Nem tudom, hogy milyen állapotok vannak és miért kell fizetni.
![;]](//cdn.rios.hu/dl/s/v1.gif)
#10 agent_k: Nem ígérek semmit, de tervben van pár nemmindennapi alkalmazás. Ha elég téma összegyűlik (pl ilyen a dns forgalom is) akkor írok egy folytatást. De ez nem 1 éven belül lesz.
-
stopperos
senior tag
Szia,
A hálózatok összekapcsolása résszel még csak kísérletezek, mert eddig még ilyen kérés nem futott be, hogy meg kellett volna oldanom. Így nem fogok tudni rá válaszolni teljesen. Viszont van pár gondolatom:
1) A 0.0.0.0/0 azt jelenti, hogy egy route jön létre minden forgalomra, ami az openwrt eszközre érkezik és a wireguard interfész felé küldi. Én azt próbálnám meg első körben, hogy csak a wireguard hálózatot veszem fel ide. "AllowedIps" Ez segítené a tesztelést.
1.1) Majd egy az openwrt routerre csatlakoztatott eszközről megpróbálnám pingelni a mikrotik szerver wg ip címét. Ha sikerül akkor az openwrt-n rendben van a routing, ha nem akkor a tűzfalnál kell a forwarding-ot (továbbítást) és masquerade (álcázás) szabályokat létrehozni a zónák között.
1.2) A leírásban az álcázós részt megtaláltam, de a továbbítást nem. Menj rá a lan=>wan sorban a szerkesztésre és az alján a forwarding engedélyezett hálózatoknál a wan mellé vedd fel a vpn hálózatod.
2) Ha 0.0.0.0/0 -van akkor tudod-e pingelni a mikrotik wg IP címét akár kliensről akár az openwrt-ről. Valamint a WAN port IP címét és a google 8.8.8.8-asát kellene megnézni ugyanígy. -
yodee_
őstag
Sziasztok!
Hetek óta próbálok egy openwrt routert beállítani, hogy normálisan csatlakozzon a mikrotik szerveremre. Eljutok odáig hogy a kapcsolat létrejön, de amint feláll a wg kapcsolat a két router között az openwrt routerre kötött eszközök nem érik el az internetet, és azokról a gépekről nem érem el az openwrt routert sem. Nagyon érdekes a felállás. A peer-nél az allowed addresses résznél mindenképp kell a 0.0.0.0/0 és a ::/0, vagy tölthetem úgy is ki ahogy mikrotiknél? Tehát engedélyezem a wg interface tartományt, és a távoli router tartományát? Tűzfal vagy valami egyéb beállítás esetleg?
Köszönöm
-
agent_k
őstag
Nagyon jó írás. Kedvcsinálónál több, szájbarágósnál kevesebb. Szakmabeli vagyok, de az openvpn-nel tett próbálkozásaim mindig egy kicsit olyan "meh" szájízt hagytak maguk után. 15 év után már az egyszerűséget keresem és a wireguard ezt tudja. Pihole-al együtt használva úgy, hogy csak a dns lekérdezéseket kergetem át a vpn-en, sebességcsökkenés nélkül tudok reklámot is blokkolni mobileszközökön.
-
-
Fantasztikus cikk!
Ritkán van hasonló a PH!-n.Én is ezer éve használom ahol csak lehet, mert gyors és nem igényel robosztus konfigot, illetve valóban nem válaszol akármilyen kérésre, így nem szúrják ki a botok, hogy hol fut a VPN-em és nem foglalkozik az otthoni router üres CPU idejében brute force-szal.
Ugyanakkor számomra a legnagyobb előnye számomra egyben a hátránya is. A megszokott kliens-szerver architektúrával szemben semmiféle megbízható mód nincs arra, hogy az egyik fél tudja, a másik gép éppen elérhető-e. Emiatt teljesen jó arra, hogy úton-útfélen belépjek az otthoni netre, de folyamatos kiépített kapcsolatot nem tudok változó otthoni IP-n kialakítani. Maximum úgy, ha van egy statikus IP címmel rendelkező VPS-em, erre kapcsolódik az otthoni router és a nálam lévő eszköz is. Egyéb esetben, még dinamikus DNS szolgáltatással is kénytelen lennék folyamatosan pingelni a hosztot, hogy tudjam, mikor érdemes újra-csatlakozással próbálkozni.
Illetve a L2 támogatást sajnálom, jó lenne a DLNA megosztás és egyéb ármányok miatt. Van példa arra, hogy valaki a wireguard alapján összehozta, Zerotier a neve (tailscalet nem ismerem), de sajnos ez is commercial termék és nem valami népszerű.
Kis korrekció viszont. Írod, hogy:
Androidra a Play Store-ból elérhető, de ez userspace-ben fut. Csak törekvés van arra, hogy ott is kernelszintű támogatást kapjon.
Már jó ideje elérhető root és megfelelő kerneles támogatás segítségével Android alatt is a dolog, automatikusan fel is ismeri az app. Jó ideje így használom, remekül megy:
Illetve ugye egy ideje már az összes Android kernel tartalmazza: [link] Csak érdekes mód API-t nem írtak hozzá, ezért kell még a mai napig is rootolni a használathoz.
De a userspace teljesítménye sem rossz szerintem hordozható eszközökre.
-
stopperos
senior tag
Szia, köszönöm. Az openwrt témából is körvonalazódik egy cikk, csak előtte meg kellene futtatni még a helyi nagyobb openwrt-sekkel, hogy szakmailag rendben van-e. Bár ez off téma ide, de ha régi tp-link-re való openwrt kellene valamivel, akkor tudok neked fordítani a sajátom alapján. De erről mindenképpen lesz írás, mert az elmúlt egy hónapban pár hétvégém ráment a témára.
#3 xabolcs Egy space benne maradt, javítottam a cikkben. De helyesen.
#4 DarkByte Az android kliens nekem is fenn van, userspace-ben fut. Nem mintha ez gond lenne. Igen, régen volt. De még mindig Szegeden vagyok, csak már nem egyetemi körökben.
-
DarkByte
addikt
Köszi!
Ezt elrakom későbbre, tervben van hogy beüzemelem a MikroTik router-emmel majd. Elvileg Android-ra is van korrekt kliense, hogy az itthoni dolgokat elérjem útközben.
Munkában már aktívan használjuk egy ideje, tetszik hogy milyen lightweight és fürge az egész.Meg se ismertelek elsőre a videón, még 2014 körül üzleteltünk valamit az egyetem alatt, nem is mostanában volt, az is igaz.
-
xabolcs
őstag
Amiről így nyilatkozott, az a Jason A. Donenfeld által létrehozott és fejlesztett WireGuard nevű biztonságos hálózati alagút (vagyis VPN).
A fenti, elso oldalrol kiemelt szovegben levo link mire szeretne mutatni a net-next repo mostani HEAD-je (8720bd951b8e "Merge branch 'net-dsa-microchip-common-spi-probe-for-the-ksz-series-switches-part-1'") helyett?
Koszi az irast, nagyon jo kedvcsinalo!
-
adika4444
addikt
Kiváló cikk, egy kiváló VPN megoldásról. Napi szinten használom kb. 2020 óta, és ha nem kell az l2 funkcionalitás (Openvpn tap), akkor számomra egyeduralkodó. Amióta pedig MikroTik RouterOS7 stabil, azóta a VPS-eimet is így érem el, a tunnel a routeren van kiépítve.
-
PistiSan
addikt
Szia, köszi az írást érdekes volt, a végén azokra is gondoltál, akik nem feltélnelül rendelkeznek publikus ip-vel, szerverrel, és a tailscale mint használható ingyenes lehetőség remek ajánlás.
Ami engem még érdekelne, írtad hogy saját openwrt-t is lehet fordítani, erről szívesen olvasnék magyar nyelven.
Nem akartam mókolni a router fw-t , h a wireguard ott fusson
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
lo Itt a megoldás, ha távolról szeretnénk elérni erőforrásainkat vagy gépeket szeretnénk titkosítva összekötni.
- HP Z840 workstation 1450W 2db XEON 2697 v4 36MAG,256GB DDR4, Quadro P6000 24GB/M6000 24GB/P5000 16GB
- Fujifilm GFX50S II Garis + GF 50mm F3.5 R LM WR + 3db akkumláltor + Urth Core nyakpánt
- 2025-ÖS Vadiúj Core Ultra 7 20 Magos 20x5.5Ghz RTX 5070 12GB GDDR7 32GB DDR5 1TB M.2 Gamer Pc 2ÉV
- ÚJ ! AMD Ryzen 7 9800X3D 16x4.7GHz Gamer PC 2025-Ös RX 7800XT 16GB 32GB DDR5 1TB SSD 850W 2ÉV GAr!
- Új AM5 RYZEN 5 8400F GAMER ERŐMŰ PC 32Gb DDR5 512GB NVME SSD NVIDIA RTX 3070TI 8Gb DDR6 2ÉV GAR!
- Lejárt a gyártói garancia? Mi tovább támogatjuk az IT infrádat!
- ALIENWARE Area-51 R6 Threadripper Edition 1920X
- ÚJ HP EliteBook 840 G8 - 14"FHD IPS - i5-1145G7 - 32GB - 512GB SSD - Win10 - 6 hónap Garancia
- Csere-Beszámítás! RTX Számítógép játékra! I9 13900K / RTX 4080 / 32GB RAM / 1 TB SSD
- Új Apple iPhone 16 Pro 256GB, Kártyafüggetlen, 3 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest