- Egyedi rögzítőt kínál pár hűtőjéhez a Noctua
- Billentyűzet gondom van
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Azonnali VGA-s kérdések órája
- Gaming notebook topik
- VR topik (Oculus Rift, stb.)
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Milyen monitort vegyek?
- Videós, mozgóképes topik
-
PROHARDVER!
OpenWrt topic
Új hozzászólás Aktív témák
-
Headless
őstag
válasz
Doky1988
#21000
üzenetére
egyrészt root-ként vagy belépve, látszódik, mivel # van a host név után.
sudo parancsod nincs a routeren, de rootként nem is kell magasabb jog.
a parancsaid azért nem mennek mert nem létező fájlokat próbálsz létrehozni ami a sys device-on nem így működik. meg kéne a találnod a konkrét led neveket.
#led nevekls /sys/class/leds/*/brightness#minden off
echo 0 >/sys/class/leds/*/brightness#minden onecho 1 >/sys/class/leds/*/brightness
de szerintem ezekkel kapcsolva a fényerőket a triggerek megváltoztathatják még. Így nem lesz végtelenségig sötét szerintem. -
mexel
veterán
Pontosabban a wifi megy. Csatlakozni a digihez nem akar, csak ha a digis routert is újraindítom.
más kérdés: a gépneveket meg lehet változtatni a mac címhez rendelve úgy hogy nem kapnak fix IP-t? Csak mert van pár okoseszköz amiknek nincs neve, csak wlan0-nak látja a router, és ha több is csatlakozik egy kérdőjellel jelöli őket. Szeretném tudni melyik melyik éppen. Mac alapján ha átnevezem az aktív dhcp bérleteknél úgy hogy nem kapnak fix IP-rt ez megoldás?
-
mexel
veterán
válasz
vargalex
#21015
üzenetére
Nem, az ugyanúgy van. Ráadásul egy újraindításnál nem csatlakozik a digihez ppoe-n. Kb 10 x kell indítani.
Ezek kellenek még vajon?
LCP echo failure threshold: 80
LCP echo interval: 20Most csatlakozott, de egyszerűen nem oszt ki IP-t a wifin. most a gépnevek sem látszanak sehol. Alapból semmit nem állítottam el, minden indításkor random mást csinál. Most gyorsan tápot cseréltem a routeren
-
mexel
veterán
Valami nem kerek nálam. Eddig minden jól ment, most megváltoztattam 20-ról 25-re a dhcp limitet és azóta nincs internet a wifiken. A vezetéken rálógatott pc-n van net, a wifiken semmi. csatlakoznak az eszközök, kapnak IP-t csak netet nbem. Ez mitől lehet?
kezdem már unni hogy pár hete a wifivel szívok.Szerk: illetve már ip-t sem oszt.
Lehet hogy a router halt meg?
-
mexel
veterán
Még egy kérdés:
Azt vettem észre hog újraindításkor nem aka csatlakozni a digihez.
Valaki ezt kérdezte régebben, idézem:
"Digi esetén ax3200-nál továbbra is ajánlottak ezek a pppoe beállítások ?
LCP echo failure threshold: 80
LCP echo interval: 20"beállítottam, most csatlakozott. Ez véletlen vagy valóban kell még?
-
mexel
veterán
válasz
vargalex
#21009
üzenetére
Á valóban, ezt elnéztem
Köszönöm! 
Hogyan tudom és inkább mire frissíteni ilyen régi vasnál, wdr3600-nál amiben elérhető az offload?
Lesz értelme?Mi az az olcsó wifis router amin már jól fut olyan openwrt ami tudja ezt és nem fekszik meg akár 30 wifi kiszolgálásától sem? ( tudom ez nem ennek a topiknak a témája, de szeretnék openwrt-t használni - akár olyan eszközzel ami kezel pl 2 db 1tb-os ssd-t is akár torrenttel)
Szerk: közben ahogy olvasgatom ezen a régi 3600-ason nem nagyon tud senki 400Mbps-nél nagyobb sebességet elérni semmilyen openwrt-vel, így valószínűleg marad ez.
A wifi stabilitás most fontosabb mint a madzagos sávszél, azt úgysem nagyon használom.
Legalábbi remélem stabilabb lesz a wifi mint a gyári fw-vel, az már használhatatlan volt -
vargalex
Topikgazda
Szia!
Tehát akkor a felületen korlátnak 20-at adtál meg? Mert ott ugye OpenWrt esetén nem az utolsó IP címet adod meg, hanem a limitet.
A címkézésnek akkor van értelme, ha egy port több VLAN-ban is benne van. Jellemzően ilyen a CPU. Ekkor minden csomag el lesz látva egy címkével, ami azonosítja, hogy éppen melyik VLAN-hoz tartozik. Lényegében így fogja tudni a rendszer, hogy melyik irányból esett be/merre kell tovább küldeni.
-
vargalex
Topikgazda
Szia!
Abban a buildben még nincs sw offload, így a CPU ennyit bír (igaz, akkor még nem is igen volt igény többre). Meg lehet próbálni egy frissebb OpenWrt-t, ahol már elérhető az offload. Persze az kérdés, hogy mennyit fog tudni. Ugye gyári firmware alatt van HW NAT, ami OpenWrt esetén Mediatek, illetve Ramips/mt7621 vonalon érhető el.
-
Joe123
senior tag
Csak egy kis info, hátha később segít másnak, ha rátalál. Vettem egy Cudy WR3000S-t, amin openwrt alól lehet a LED-eket vezérelni. Azonban jelenleg (24.10.1) nem mindet. A LAN1-LAN4 LED-eket nem lehet elérni, én meg az összeset le akartam kapcsolni. A megoldás, hogy fel kell tenni az mdio-tools csomagot és a System / Startup / Local startupnál az exit 0 sor elé be kell szúrni ezt:
mdio mt7530-0 0:0x1f raw 0x21 0x0008
A többi LED vezérelhető a System / LED config alól.
-
mexel
veterán
lenne még egy kérdésem. DHCP-nél megadtam hogy a kezdő IP 100 az utolsó 120 legyen, de mégis kioszt 161, 175 stb IP-ket.
Ezt a LAN DHCP kiszolgáló résznél adom meg.
Kellene még valamit állítanom?Még egy kérdés:
A hálózaton belül a kapcsolóknál a címkézés mit jelent pontosan? -
Doky1988
senior tag
/ Előző kommentem törölje már légyszi moderátor, vagy admin, nem tudom átírni. Meg ezt a sort légyszi ha az előző kommentem törölte. /
LED-ek kikapcsolása AX3600 (OpenWRT)
ledoff-openwrt-ax3600.sh:
# Vilagito LEDek kikapcsolasa AX3600 (OpenWRT)# Kek LEDek /Elol/ (AioT, Network, System)echo "0" > /sys/class/leds/blue:aiot/brightnessecho "0" > /sys/class/leds/blue:network/brightnessecho "0" > /sys/class/leds/blue:system/brightness# Zold LEDek /Hatul/ (WAN, LAN1, LAN2, LAN3)echo "0" > /sys/class/leds/90000.mdio-1:01:green:wan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:02:green:lan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:03:green:lan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:04:green:lan/brightnessvagy ha valakinek kell fájlba, ami tuti müxik, kiraktam webemre: [Letöltés]
Letöltött fájlt, másold fel a router root könyvtárába (SCP, vagy lewgeteled), majd chmod +x ledoff-openwrt-ax3600.sh aztán LuCi -ba Rendszer/Ütemzett feladatok -nál add hozzá:
00 20 * * * /root/ledoff-openwrt-ax3600.sh00 8 * * * /etc/init.d/led startMajd Mentés, és készen is van. crontab rész: este 20:00-kor kikapcsolja a LED-et, reggel 8:00-kor meg vissza.
A megoldás természetesen TESZTELVE lett!
-
mexel
veterán
Sziasztok! Régi TP-Link WDR3600 routerem nagyon dobálta a wifit ezért feltettem az Openwrt-t ( OpenWrt - vargalex build ver. 1.1.7)
Be is állítgattam az alapokat emi nekem kellene, de emlékeim szerint régen ezt már raktam fel de azért szedtem le mert nem tudta kipörgetni a gigás netet.
most ismét sajnos azt látom hogy csak 250Mbps fel és 250Mbps le stabilan a net.
nem lehet állítani valamit rajta? Olyan mintha lekorlátozná. -
Doky1988
senior tag
válasz
vargalex
#20998
üzenetére
Mégse jó
Úgyse, hogy eléírtam, hogy sudoDe ha kézzel beírom egyessével a parancsot akkor meg müxik.
root@AX3600:~# ./ledoff.sh
: Permission denied: can't create /sys/class/leds/blue:aiot/brightness
: Permission denied: can't create /sys/class/leds/blue:network/brightness
: Permission denied: can't create /sys/class/leds/blue:system/brightness
./ledoff.sh: line 4: can't create /sys/class/leds/90000.mdio-1:01:green:wan/brig: Permission denied
./ledoff.sh: line 5: can't create /sys/class/leds/90000.mdio-1:02:green:lan/brig: Permission denied
./ledoff.sh: line 6: can't create /sys/class/leds/90000.mdio-1:03:green:lan/brig: Permission denied
./ledoff.sh: line 7: sudo: not found -
Doky1988
senior tag
válasz
vargalex
#20998
üzenetére
root@AX3600:~# /etc/init.d/led restart
setting up led WAN-PORT-LINK
setting up led LAN1-PORT-LINK
setting up led LAN2-PORT-LINK
setting up led LAN3-PORT-LINK
setting up led System
setting up led AioT
sh: write error: Invalid argument
setting up led Internetsh: write error: Invalid argument <- Ez a sor mi lenne?
Kipróbáltam, visszaállítja a LED-eket (LANt is!) viszont az a sor amit írtam nemtudom mi.
Akkor ledoff.sh:
; Vilagito LED-ek kikapcsolasa AX3600 (OpenWRT); Kek Ledek /Elol/ (AioT, Network, System)echo "0" > /sys/class/leds/blue:aiot/brightnessecho "0" > /sys/class/leds/blue:network/brightnessecho "0" > /sys/class/leds/blue:system/brightness; Zold ledek /Hatul/ (WAN, LAN1, LAN2, LAN3)echo "0" > /sys/class/leds/90000.mdio-1:01:green:wan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:02:green:lan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:03:green:lan/brightnessecho "0" > /sys/class/leds/90000.mdio-1:04:green:lan/brightness -
vargalex
Topikgazda
válasz
Doky1988
#20997
üzenetére
A példa scriptben ott van. Legegyszerűbb, ha a kikapcsolás előtt megnézed a pseudo file-okban található értékeket és azokat állítod vissza. De valószínűleg a default beállítást megteszi a
/etc/initd.d/led restarthívás is. Mondjuk szerintem ez a LAN ledeket nem fogja állítani.
-
Doky1988
senior tag
válasz
Doky1988
#20995
üzenetére
ledoff.sh -nak:
; Vilagito LED-ek kikapcsolasa AX3600 (OpenWRT)
; Kek Ledek /Elol/ (AioT, Network, System)
echo "0" > /sys/class/leds/blue:aiot/brightness
echo "0" > /sys/class/leds/blue:network/brightness
echo "0" > /sys/class/leds/blue:system/brightness; Zold ledek /Hatul/ (WAN, LAN1, LAN2, LAN3)
echo "0" > /sys/class/leds/90000.mdio-1:01:green:wan/brightness
echo "0" > /sys/class/leds/90000.mdio-1:02:green:lan/brightness
echo "0" > /sys/class/leds/90000.mdio-1:03:green:lan/brightness
echo "0" > /sys/class/leds/90000.mdio-1:04:green:lan/brightness-------------------------------------------------------------------------------------------------------------
ledon.sh -t nem vagom hogy kell a netdevet meg ezeket megadni, abba segits mar legyszi xabolcs.
-
Doky1988
senior tag
válasz
xabolcs
#20993
üzenetére
No, szóval router LEDek kikapcsolása az készen van.
Bekapcsolásra kellene segítség, szal backup configból kivettem pl az Internet LED bekapcsolva részét:
config led
option name 'Internet'
option sysfs 'blue:network'
option trigger 'netdev'
option dev 'wan'
list mode 'link'
list mode 'tx'
list mode 'rx'Kérdés az, hogy ezt így parancssorosan hogy kapcsoljam be, hogy így legyen?
echo "netdev" > /sys/class/leds/blue:network/trigger ???
és itt hogy adjam meg a link tx rx -et? ez nem világos -
xabolcs
őstag
-
-
válasz
xabolcs
#20987
üzenetére
Próbáltam a DMZ-s megoldást, az se ment.
Mostanra amúgy a fő routeren sikerült megoldani a DHCP-t is egy VLAN-ba, így asszem ez lesz a vége, amit a 20986-ban írtam.
Most szépen megy az, hogy egy kliens a külön VLAN-ban kap IP-t, kilát netre, LAN-t nem éri el (kivéve a routert sajnos, de azon tiltottam a SSH-t a DMZ felől), és LAN-ról minden porton elérhető. Port forwardokat kell még csinálni, amik arra az egy gépre kellenek. -
xabolcs
őstag
Miert szeretnel ennyire VLAN-ozni? Nincs folosleges szabad portod, amit DMZ-be le tudnal valasztani?
A korabban hivatkozott DSA Mini-Tutorial-t atnezted mar? Vannak benne cifra dolgok.
Egyebkent ha lenne szabad, DMZ-sitheto port a fo routereden, meg egy switched (switch-kent hadznalt routered), akkor messzirol is lathato lenne, hogy mi a LAN, mi a DMZ.
Van folos, 5 portos gigabit switchem, ne ezen muljon!
-
válasz
vargalex
#20985
üzenetére
Az pont elég baj lenne
Eddig az tűnik jónak, hogy az elsődlegesen kell egy leválasztott port, arra megy a másodlagos router, és akkor meg lehet oldani azt, hogy a net felé ki tudjon menni, LAN-ra ne.De a furcsa még mindig az, hogy miért nem működik a DHCP egy VLAN-ra beállítva a VLAN-on belül
Mindenesetre köszi a segítség
-
vargalex
Topikgazda
Igen, az jutott eszembe nekem is, hogy mivel ez egy másodlagos router, látni fogja az elsődleges router LN-ját. Persze szerintem azt a másodlagos routeren levő fűzfallal meg lehet oldani, hogy ebből a zónából az elsődleges router tartományából csak magát a routert érje el.
-
Ja, közben leesett. Ezen a második routeren nincs "WAN" zóna, szóval ha el is tudom szigetelni a LAN-tól valamelyik portot, gondolom nem tudom megoldani, hogy a net felé kilásson a LAN érintése nélkül
Mindenképpen az kéne, hogy ez a router a másik mögött lóg a WAN portjával, és a fő routeren van leválasztva neki egy port...Ja, amúgy kérdezted a platformot @vargalex, Tp-Link C7 a fő, és 1043v1 a másodlagos cucc.
-
válasz
vargalex
#20982
üzenetére
Ja, sry
Tehát annyi történik, hogy ez a router félig-meddig switch, de ha kell, beállíthatom elsődlegesnek is, azért sem lett a WAN kiütve. A +3 port elég volt, de aztán tudtam szerezni olcsón egy 8 portos gigás switchet, és azóta azon lóg minden, az elsődleges routeren jön be a hálózat, az a DHCP és DNS is, és abba van dugva ez a cucc is, amin most tűzfalazni akarok. Ezen büntetlenül lehet konfigolni. Illetve ezen is van egy wifi, az is menne majd a "DMZ"-be, arra csatlakoznának az outdated, stb. eszközök. Nem tökéletes, de még mindig jobb, mint ha egy háló van csak.A WAN egyáltalán nem lesz használatban ezen a routeren. A cél most annyi, hogy csináljak egy leválasztott VLAN-t, amiben első körben egy port van, és az azon lógó eszközre a forgalmat lehessen szabályokkal korlátozni. (Tehát az a gép kilásson netre, ne lássa a LAN-t, de a LAN-ról elérhető legyen.) Ezen a VLAN-on belüllehetne egy DHCP, saját IP tartománnyal (amit ugye az interface-re lehet is konfigilni), az nem gond, sőt.
Parasztabb megoldás lenne, ha ez a router a WAN-on kapna linket az elsődlegesről, csak akkor azokat a portokat, amik a letöltőgépre be vannak küldve, oda is forwardolni kéne + valahogyan megoldani, hogy az elsődleges router DNS-ében a másik hálón belül levő gép meglegyen, tehát a "ssh gépnév" parancs működjön pl. Nyiván ha nem menne, akkor erőteljes női panaszokkal nézek szembe.
-
vargalex
Topikgazda
Bocs, de nem mondtad, hogy valójában az eth0.2 nincs használatban. Azt hittem a PPPoE config-ot csak azért hide-oltad, hogy meg tudd osztani. De egyébként miért nem csináltál belőle egy 5 portos switch-et? Törölhetted volna a wan interface-okat, az eth0.2-t, sőt az egész switch is mehetett volna vlan nélkül.
De akkor most, ha a WAN portra csatlakoztatsz valamit, továbbra sem kap IP címet? A dhcp config-odat még nem osztottad meg. -
válasz
vargalex
#20980
üzenetére
Akkor a 2-es számú VLAn-t néztem be, de korábban, amikor másképp hívták, és az volt hozzáadva sem ment. Akkor most 103-as VLAN.
Az is kérdés, hogy a bridge device-n csak a VLAN-t kell felvenni, vagy a switchet is...? Sehol nem derül ki.Firewall konfig nem változott.
Az is érdekes lehet, hogy ez a router nem a WAN-jén van kikötve a nagyvilág felé, hanem managelhető switchnek használtam, az egyik LAN-on kapcsolódik a fő routeremhez. De mondjuk ettől még egy leválasztott VLAN-tkéne tudnom alkotni rajta.Akkor network :
root@OpenWrt:~# cat /etc/config/networkconfig interface 'loopback'option proto 'static'option ipaddr '127.0.0.1'option netmask '255.0.0.0'option device 'lo'config globals 'globals'option ula_prefix 'fdb6:fca4:79ff::/48'option packet_steering '1'config interface 'lan'option proto 'static'option netmask '255.255.255.0'option ip6assign '60'option device 'br-lan'option ipaddr '192.168.1.2'config interface 'wan'option proto 'pppoe'option username ' 'option password ' 'option ipv6 'auto'option device 'eth0.2'config interface 'wan6'option proto 'dhcpv6'option device 'eth0.2'config switchoption name 'switch0'option reset '1'option enable_vlan '1'option enable_vlan4k '1'config switch_vlanoption device 'switch0'option vlan '1'option ports '0 1 2 3 5t'config switch_vlanoption device 'switch0'option ports '4 5t'option vlan '103'config deviceoption name 'br-lan'option type 'bridge'list ports 'eth0.1'Firewall konfig közben nem változott.
config interface 'brdmz'option proto 'static'option device 'brdmz'option ipaddr '192.16.3.1'option netmask '255.255.255.0'option gateway '192.168.1.1'config deviceoption name 'brdmz'option type 'bridge'list ports 'eth0.103'root@OpenWrt:~# -
vargalex
Topikgazda
Nem értem a Network config-odat. Nem csináltál új VLAN-t. Az eth0.2 device a WAN interface eszköze. Az eth0.1 VLAN-ból kellene kivenned egy portot, ugyan úgy TAG-eltként hozzá kell adni a CPU portot is és ezt az úgy eth0.3 device-t tudod odaadni a brdmz interface-odnak.
Egyébként ez milyen platform? Csak, mert van switch config-od is.
-
Ezek a konfigok. Most addig maceráltam, amíg legalábbis van egy bridge, annak van egy IP-je és egy MAC-e, van rá egy DHCP szerver, és legalábbis a routerről tudom pingni. De az ebbe a portba dugott gép nem kap IP-t.
root@OpenWrt:~# cat /etc/config/networkconfig interface 'loopback'option proto 'static'option ipaddr '127.0.0.1'option netmask '255.0.0.0'option device 'lo'config globals 'globals'option ula_prefix 'fdb6:fca4:79ff::/48'option packet_steering '1'config interface 'lan'option proto 'static'option netmask '255.255.255.0'option ip6assign '60'option device 'br-lan'option ipaddr '192.168.1.2'config interface 'wan'option proto 'pppoe'option username ' 'option password ' 'option ipv6 'auto'option device 'eth0.2'config interface 'wan6'option proto 'dhcpv6'option device 'eth0.2'config switchoption name 'switch0'option reset '1'option enable_vlan '1'option enable_vlan4k '1'config switch_vlanoption device 'switch0'option vlan '1'option ports '0 1 2 3 5t'config switch_vlanoption device 'switch0'option vlan '2'option ports '4 5t'config deviceoption name 'br-lan'option type 'bridge'list ports 'eth0.1'config interface 'brdmz'option proto 'static'option device 'eth0.2'option ipaddr '192.168.3.1'option netmask '255.255.255.0'option gateway '192.168.1.1'list dns '1.1.1.1'list dns '8.8.8.8'root@OpenWrt:~#root@OpenWrt:~# cat /etc/config/firewallconfig defaultsoption input 'ACCEPT'option output 'ACCEPT'option forward 'REJECT'option synflood_protect '1'option drop_invalid '1'option flow_offloading '1'option flow_offloading_hw '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 'wan6'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 src_ip 'fc00::/6'option dest_ip 'fc00::/6'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 includeoption path '/etc/firewall.user'config zoneoption name 'dmz'option input 'ACCEPT'option output 'ACCEPT'option forward 'REJECT'list network 'brdmz'root@OpenWrt:~# -
válasz
xabolcs
#20974
üzenetére
Köszi!
Én is az alapján, de abban jelenleg nincs bridge... lehet változott amióta te csináltad
Kipróbálom ma, köszi -
xabolcs
őstag
Ahogy mondtam, en egy kulon portot tettem DMZ-be.
A "DMZ configuration using VLANs" leirast vettem alapul./etc/config/network: vettem fel egy bridge-et es abba tettem bele az egy szem portot.
config device
option type 'bridge'
option name 'br-dmz'
list ports 'lan2'
config interface 'dmz'
option proto 'static'
option device 'br-dmz'
option ipaddr '192.168.x.y'
option netmask '255.255.255.0'
list dns '1.1.1.1'
list dns '8.8.8.8'A DSA Mini-Tutorial-ban mindenfele VLAN-ozas le van irva ... szerintem ossze tudod illeszteni a DMZ-s leirassal!
-
-
attila.86
tag
Ha a leválasztott hálózatnak nincs input engedélyezve (és ez így van jól), akkor nincs dhcp, sem router-es dns, ezeket külön engedélyezni kell, mint tűzfal-szabályok. Mondjuk ezek nélkül is mennie kéne egy 1.1.1.1 pingnek mondjuk, ha kézzel állítottál ip-t és gateway-t, és ebből a hálóból engedélyezve van forgalom a wan felé.
-
Most ott tartok, hogy tudtam VLAN-t létrehozni, azt betenni tűzfalzónába, saját DHCP-vel. Viszont akármit csinálok, nincs DHCP a VLAN-on belül, semmi nem kap IP-t, így aztán nem tudom, hogy mi akad el
Próbáltam hogy DHCP-re csinálok tűzfalszabályt, de nem érdekli, nincs DHCP. Statikus IP-t megadva se se ki, se be semmi. Amúgy DHCP működik az eszközön, a normál LAN-ra ad ki IP-t.
Ami még furcsa, hogy az interface létrehozás felületen nem lehet bridge-t választani. De azt sem tudom, hogy azt hogy kéne bekonfigurálni a /etc/config/networks-ben? -
válasz
xabolcs
#20969
üzenetére
Igen, az a bajom, hogy nem akartam direktben a routerbe dugdozni semmit. A switchen van 8 port, majdnem tele is van
Nem is hülyeség amúgy a DMZ. Van egy plusz router is, arra bedugom ezt az 1 gépet (asszony letöltője, nem hajlandó frissíteni, 12-es Ubuntu
), a gázabb, outdated eszközök úgyis erre csatlakoznak wifin, és akkor mindenki egy helyen van, az egészet be lehet vágni DMZ-be... ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
vargalex
Topikgazda
Ez azért van, mert az egy bridge-ben lévő interface-ok közötti forgalom nem megy át a tűzfalon. Azaz csak úgy tudod ezt megtenni, ha külön subnetbe (azaz külön hálózatba) szervezed ezen eszközöket. És akkor már lehet tűzfal a LAN és a LAN2 network-ok között, ahol nem engeded az átjárást.
-
Hello,
Hogyan lehet olyat, hogy bizonyos eszközök ne érjék el a LAN-t, csak a netet?
Találtam ilyesmit, hogy nyilván felveszünk egy tűzfalszabályt, hogy source LAN, IP az eszközé, destination LAN... és nem működik
config rule
option name 'lan block'
option src '*'
list src_ip '192.168.1.154'
option dest 'lan'
option target 'REJECT'
list src_mac 'F0:DE:F1:16:13:21'Az lehet-e a gond, hogy a router után egy switch van, és azon lógnak az eszközök? Nevezetesen el se jut a tűzfalig a forgalom?
Köszi minden ötletet
-
vargalex
Topikgazda
-
Joe123
senior tag
válasz
vargalex
#20961
üzenetére
Köszi az infot. Ezt openwrt alatt tudta már akkor?
Közben addig jutottam, hogy ha kikapcsolom a fő routeren a packet steeringet, akkor sokkal egyenletesebb a terhelés eloszlása a szálak között speedtest futtatása alatt.
A kliens routeren viszont akárhogy állítom, ott az egyik szál mindig felmegy közel 100-ra, sőt van amikor el is éri, úgyhogy jelenleg az lesz a szűk keresztmetszet.
irqbalance-t próbálgattam mindkettőn, azzal nem vettem észre semmi változást.
Ma 350-380-akat mértem jellemzően (az mondjuk már úgy kb. elmegy), azt nem tudom a kliensen hogy lehetne elérni, hogy ne egy CPU szálat terheljen le ennyire, hanem egyenletesebben ossza el úgy, mint a fő routernél.
-
xabolcs
őstag
válasz
Joe123
#20957
üzenetére
Most nincs kedvem a fo routeremet kicserelni, de relevans lenne szamodra, ha kliens modban tesztelnek egy ramips/mt7621-es D-Link DIR-860L-et? Abban egy picivel regebbi WiFi van: MediaTek MT7612E, MediaTek MT7602E
Egy Dynalink DL-WRX36 lenne a kiszolgalo.
-
Tamy
senior tag
Mi most a legolcsóbb (avagy ár/érték arányban legjobb) itthonról, újonnan, számlával elérhető router, ami wifin biztonságosan elbír kb. 30 laptopot, és lehetőleg mindenféle speciális mókolás nélkül rakható rá OpenWRT? Előny, ha Gargoyle is van rá. Sebességben a gigabites tempó elég, és csak AP-nak lenne használva.
-
Joe123
senior tag
Sziasztok,
Egy régi MT7621-es routernek (Xiaomi Redmi AC2100) 866-os link mellett kb. mekkora sebességet kellene tudnia Wifin keresztül? PPPoE-t is ez a router csinálja, HW offloaddal a gigás netet vezetéken kiforgatja 940-ig ahogy kell, de Wifin jellemzően csak 250-300mbit jön Openwrt alatt. Amikor egy kölcsön noti AX200-as kliensével próbáltam, volt hogy elvétve 450-et is mértem, de ha egy másik routerrel (Asus AC57u V1 szintén Openwrt-vel) csatlakozom rá kliens módban, akkor se nagyon akar 320 fölé menni (jellemzően inkább kevesebb, 300 alatt), ha egymás mellé vannak téve és Rx/Tx irányba egyaránt stabilan 866,7-es linket ír ki a Luci. (866,7mbit, 80MHz, VHT-MCS 9, VHT-NSS 2, Short GI)
Most pl. lefelé irányba 230-250-et mértem, felfelé 260-300-at.Letöltés alatt:
Feltöltés alatt:
-
vargalex
Topikgazda
válasz
Archttila
#20953
üzenetére
A Flint2-höz hasonló vassal az Asus TUF-AX6000 is beszerezhető itthon 57k-tól. Lehet, hogy jobban megéri, mint az AX9000. Bár, személyes tapasztalatom egyikkel sincs, viszont egy ismerősöm nagyon elégedett a kistesójával, a TUF-AX4200-al (természetesen OpenWrt alatt).
-
trance89
őstag
válasz
adika4444
#20951
üzenetére
AX9000-el sztem nemnagyon foghatsz melle, az a baj hogy a flint2 jelenleg majd 2x ennyibe faj EU-s rendelessel es nemigen tud tobbet
Nalam 3db Xiaomi AX3600-as van hasznalatban, par hete tertem at 24.10 OWRT-re a gyari fw-rol, egyelore nagyon biztato amit nyujt 800/200 optikan. Anno jopar eve pont a rendes OWRT tamogatas miatt esett a valasztas erre a tipusra es egyelore nem csalodtam. Az AX9000 szinte ugyanez csak sokkal magasabb orajelen -
válasz
vargalex
#20942
üzenetére
Archlinuxarm.org -on semmi válasz
Legalábbis az Allwinner része kong kb.
AXP20* táp IC kezelésével van bajom.Adott egy Sunxi Linux supportált Allwinner tablet, arra felhackeltem egy Arch-ot. Kijelző 5.x kernellel hajlandó működni (mindegy, wifis kijelző lenne belőle, szóval nem kell up to date-nek lennie). Viszont nincs akkutöltöttség-mérés, és túl meleg a proci. Gondolom proci tápfesz-szabályozás sincs, meg órajel se. AXP20x a táp IC típusa, a/sys/class... alatt ott van az USB része, de battery nincs.
Szóval annyi lenne a kérdés, hogy hogyan lehet ARM-on tápfeszt, órajelet szabályozni, esetleg hogy mik az ACPI megfelelői ARM-on.
-
ARM témában lehet itt kérdezni? Nem OpenWRT, hanem Arch, ARM-on - ha valahol akkor itt lehet bárki, aki ért hozzá
-
#20940
kismacska7
újonc
kismacska7
újonc
Sziasztok!
Szeretnék egy openwrt one routert összerakni. Úgy értem van fent az interneten egy csomó nyák terv, és azok alapján összerakni egy routert amin openwrt fog futni. Én szeretném meghatározni mekkora legyen a nyák és milyen interface-éi legyenek a routernek. Ebben ha valaki segít, pénzt is adok érte.
-
kutga
félisten
válasz
trance89
#20927
üzenetére
Úgy látom az én Cudymra is elérhető már a 24.10.0, jelenleg 23.05.5 verzió fut rajta. Ha frissíteni szeretném, akkor jól gondolom, hogy elég betallózni a letöltött Sysupgrade image fájlt, és az openwrt webes felületéről telepíteni? Valamiféle visszaállítást érdemes csinálni, előtte és/vagy utána?
-
.-..-.
tag
válasz
attilav2
#20929
üzenetére
Igazabol nekem csak a kabeles reszre kell Router, mert van egy Mikrotik AP-m, ami megoldja az 5GHz Wifi kerdest a telefonokhoz/tabletekhez. Es egy n66u router switc-kent hasznalva a mikrokontrollerek 2.4GHz-e miatt elhelyezve nagyjabol a terulet kozeppontjan.
Tarsashaz leven iszonyu sok Wifi van es minden egyeb helyen kabel van nalam a stabilitas miatt. Gigabitre kabeleztem anno (CAT5E) minden helyiseget.
Emiatt tovabbra is ugy gondolom, kenyelmesebb volna az x86 vonal. Nagyobb szabadsagot ad a varialassal, nem kell foglalkoznom vele, hogy eleg eros-e a cpu, megy-e rendesen a hw offload, stb. -
adika4444
addikt
válasz
xabolcs
#20924
üzenetére
Köszi a választ! Úgy néz ki, HW offload nélkül jobb, de fura, mert a MikroTik hAP ac3-mal is hasonló a jelenség.
Offload nélkül meg az MT7621 nagyon gyenge önmagában.
Agyalok egy GL.iNet GL-MT6000 beszerzésén, ahogy elnézem, ez gyakorlatilag HW offload nélkül is képes lenne elbánni a nettel és szerintem megoldaná a problémámat.
-
attilav2
őstag
válasz
.-..-.
#20925
üzenetére
Esetleg egy Archer C7v5 beszerzése használtan(hátha a realtek kártya jó barátságban lesz a qualcomm routerrel), ha visszaolvasol akkor az egyik korábbi hozzászólásomból láthatod hogy majdnem teljesen kihajtja a gigabitet 23.05.5-el, illetve az Archer C7v4 is kis hackeléssel (archattila leírja egyik hozzászólásában, illetve neki megfelelő beállításokkal 24.10 alatt is vitte a gigabitet megfelelő beállításokkal). Ez áthidaló megoldásként szóbajöhet míg egy combosabb routerre össze nem jön a pénz, pl GL.inet Flint2.
-
válasz
trance89
#20927
üzenetére
Lattam, igaz csak ma reggel raktam fel Attended Sysupgrade -el es hat nagy meglepetesemre a WAN / PPPoE nem tudott csatlakozni. Szerencsere upgrade elott (is) mindig csinalok egy teljes config backup-ot, szoval egy config restore utan a friss rendszeren is minden ugy mukodik mint elotte..
-
devast
addikt
válasz
.-..-.
#20925
üzenetére
Nem tudom hasznalhatoak-e, de en tavol tartanam minden broadcom dologtol. Szimplan az uzletpolitikajuk miatt. intel 2.5g-s kartyak nagyjabol mukodnek, (i226-v), az elso revizioik katasztrofak voltak (i225- v1 - v3). Nekem konkretan a realtek-el sincs bajom (azon kivul, hogy aspm-et le kell tiltani), bar nem hasznalok 2.5-ös (rtl8125) verziót linux alatt. Mas "olcso" nic nagyon nincs.
-
.-..-.
tag
A jelenlegi AC65P routeremtol fuggetlenul, egy sajat x86_64-alapu routert csinalok.
Amolyan kivancsisagbol, mert kezd erdekelni a Linux halozatkezeles melyebben az eddigi ismereteimhez kepest.
Illetve szeretnek sajat szabalyokat alkalmazni a halozatkezelesnel es ugy gondolom az x86 vonal eleg eros es konnyebben beszerezheto vonal lenne ehhez.
Azt mar elhataroztam, hogy nem Realtek lesz a halozati vezerlo.
Az irant erdeklodnek, hogy az Intel ketportos kartyai mellett/helyett mennyire hasznalhatoak a Broadcom ketportos kartyai?
Van esetleg valami ismert problema, ami esetleg rossz valasztassa tenne egy ilyen kartyat Linux hasznalathoz? -
adika4444
addikt
válasz
adika4444
#20922
üzenetére
Küzdöttem a gonddal és furcsa mód akkor jön elő igazán, ha aktív a HW offload. HA inaktív, akkor az iperf3 mérés 200 Mbps fölé is megy (offload-dal 100 a teteje), viszont offload nélkül azért szépen látszik a CPU-terhelés, offloaddal meg marad 0, de valahogy még is megáll a sebesség.
Tesztelek majd egyet MikroTik-kel, kíváncsi vagyok, az jelenleg mit fog produkálni, a korábbi eredmények pár hónaposak, ezek szerint változhatott valami a képletben.
MT7621-es platformon ez amúgy ismert hiba? Olyat láttam, hogy PPPoE-val nem az igazi a HW offload, de ezek régebbi posztok voltak.
-
adika4444
addikt
Hali!
Már emlegettem korábban is ezt a problémát, de azóta is fennáll és azóta is szeretnék a végérejárni, mert iszonyat idegesítő.
Van nekem egy gigabites One (ex DIGI) FTTH internetem, és mögötte egy ASUS RT-AX53U OpenWRT-vel, de előtte volt már Ubiquiti EdgeRouter ER-X (chipset mondjuk ugyanaz az MT7621), szintén owrt-vel.
A problémám és ezt főleg külföldi desztinációkon tapasztalom (hosszabb trace, magasabb késleltetés), hogy a router mögött lévő munkaállomásokon az egyszálas TCP és UDP sebességg számottevően lassabb, mint a routeren. Van több OVH, netcup és egyéb szerverem, VPS-em és kivétel nélkül azt tapasztalom, hogy ha pl. iperf3-mal mérek, Wireguard VPN-ben csinálok bármit vagy épp SCP-vel másolok, sokkal lassabb egy Windows, Debian laptopon kábelen és wifi-n, vagy telefonon, mint akkor, ha a routerről megy a mérés, a routeren SCP-zek vagy a routeren van a Wireguard alagút vége és a mögötte lévő klienseket a router NAT-olja a VPN-hez.
Ha közvetlen laptopon építek PPPoE-t, akkor igazán hasít minden, a routernél mindig azt látom, hogy a CPU-ból fogy ki, ha rajta megy az iperf3, VPN etc. Belföldi célokon ezt kevésbé tapasztalom, bár itt is jellemző, hogy a gigabitet sehová nem tudom kimérni, 500--600 Mbps körül tetőzik. Volt már próbálva MikroTik routerrel is, de hasonló a hibajelenség. Próbálkoztam azzal, hogy a MTU-t állítgatom a PPPoE interfészen, de szintén nem segít, meg a routeren nézve jó amúgy is a sebesség.
Röviden összefoglalva tehát a problémám az, hogy ezen a DIGI végponton, ha NAT-olt IPv4 hálózat és router mögötti (az nem NAT-olt) IPv6-ról próbálok csinálni valamit, az meglehetősen lassabb, mint közvetlen a PPPoE-t felépítő eszközön.
Amit eddig próbáltam:
- Elvittem a routert egy Telekomos giga/giga végpontra, nem tapasztaltam a hibát.
- Bedugtam a laptopom a környéken egy DIGI-s eszközbe, az router módban van és ugyanez a szomorú eredmény.
- Csekkoltam teljesen másik fejállomáson lévő DIGI végponton, hasít minden hibátlanul és ezt a régi DIGI topikban is lejátszottuk, ott is többnyire jó eredmények voltak, de 1--2 ember azért szintén belefutott ebbe.Valami gond tehát a routolás / NAT-olás frontján lehet, de lövésem sincs, hogy mi. Talán MTU?
Ha valakinek van valami ötlete, mindenképp ossza meg, mert ez egy hosszú évek óta fennálló probléma. Zavart eddig is, de most már főleg, hogy közvetlen kapcsolódva és másoknál látom, hogy milyen jó lett az One-nal a külföldi peering, tehát a probléma biztosan nálam van, vagy a végponton, vagy a fejállomáson, de sajnos az ügyfélszolgálat ezzel eddig nem igazán tudott mit kezdeni.
-
adika4444
addikt
válasz
.-..-.
#20898
üzenetére
Mindenképp jó volna tesztelni valami mással. Ez az r8168 az MT7621-gyel nálam sem igazán jött ki jól, ilyen link down-up köröket tolt, néha naponta, néha hónapokig semmi. Nem tudom, mi okozta, nálam az lett a megoldás, hogy kidöglött a gép, amiben ez a chip volt.
Én is raktam kernelmodult, cserélgettem a kábeleket, de semmi, nem tudtam elérni a hibamentes működést.
-
.-..-.
tag
válasz
vargalex
#20916
üzenetére
Nem fogod elhinni mi volt a hiba ...
Persze user error
Semmi OpenWRT, az teszi a dolgát rendesen.Az volt a gond, hogy telepítés közben (arch-chroot /mnt) írtam meg a /etc/resolvconf fájlt, még a legelső normál boot folyamat előtt.
Azt viszont nem tudtam, hogy ilyenkor a systemd-resolved felülírja egy saját, nagy semmi konfiggal.
Így csak éppen a nameserver, ami esetemben a router, na az hiányzott.
A vicces az egészben, hogy mindeközben csomagokat tudtam telepíteni a repo-ból és ping esetén is működött valahogy a névfeloldás.
Nem látom át a miérteket sajnos, de az valamiért gondolom a /etc/systemd/network/20-wired.network konfigot használta.
Ott a Gateway és DNS is a router IPv4 címe.
De ami a resolvconf-ra támaszkodott, az elvérzett.
Oda is beírva a nameserver RouterIP címet, helyreállt a rend. -
vargalex
Topikgazda
válasz
.-..-.
#20915
üzenetére
A linkelt oldal TCP-n ellenőriz (UDP-n nem is tud). Pont ezt tudnád ellenőrizni telnet-el is. Az nginx is TCP-n hallgat.
Nem lehet, hogy valami blokkolja az UDP forgalmat? UDP-t többféle módon is tudsz ellenőrizni. Én lehet, hogy az iperf3-at preferálnám. Elindítanám a szerveren szerver módban, és egy külső gépről megpróbálnám a klienst futtatni.#20914 .--..-. Nem volt egyértelmű, hogy nem ugyan arról a szerverről van szó...
-
.-..-.
tag
válasz
.-..-.
#20914
üzenetére
Egy olyan jellegű trükköt most megcsináltam, hogy
- qbittorrent leállít
- nginx felrak
- nginx konfigolva 20000 portra
- nginx látható intranetről/internetről (az ISP-től kapott IP-t használva)Ergo a Port Forward működik.
Vagyis nem OpenWRT gond.
A hiba tehát már a PC-ben van.Vicces, ha itt a saját IP-m és a 20000-t csekkolom, akkor minden rendben és azonnal meg is lesz a torrent-kliensben a várt Connected Status.
Bár nem tudom ez így mennyire valid, mert tracker oldalon nincs nyoma. -
.-..-.
tag
válasz
vargalex
#20913
üzenetére
Amiről a linux haladóban írtam, az egy VPS. Azon természetesen mindenféle védelmet állítok, mert "megtalálják zsiványok", mivel több domain is van hozzá.
Amiről most szó van, az a "házi-szerverem", az amivel küzdök már egy ideje.
A LAN eldobós, folyton úratelepítős, VPN-el leállós, Port Forward-dal nem működős.
Hisz tudodA telnet-es dolgot nem ismerem.
A router éppen használatban van, asszony még aktívan dolgozik. -
vargalex
Topikgazda
válasz
.-..-.
#20912
üzenetére
A linux haladó topicban azt írtad, hogy van ufw...
LAN-ról tudsz csatlakozni telnettel a szerver 20000-es portjára? A HW NAT-nak ehhez nincs köze.Esetleg privátban nem tudsz adni valamilyen távoli hozzáférést (mondjuk SSH) a routerhez? Adok IP-t, tehát nem kellene a teljes netről megnyitni. Persze, ha csak megbízol bennem...
-
.-..-.
tag
válasz
vargalex
#20911
üzenetére
Na ... visszatérve az alapokhoz.
Port ForwardAkkor vagyon egy új OS és systemd-networkd/resolved beállítva.
A PC a 192.168.100.100 IP címet kapja.
Ugyan az OpenWRT-ben a DHCP-ben beállítottam, hogy az adott MAC-Address esetén mindig ezt adja neki, de a szerveren is statikusra vettem ugyanezt az IP-t neki.Namost a szokott módon a Port Forward be van állítva a 20000 portra, de mégsem lesz aktív a torrent kliens kapcsolata, pedig ott is ugyanez a port van ismét beállítva.
Nem rakott az ISP-m NAT mögé, mert ugyanazt az IP-t látom a Router-ben és a WhatIsMyIP-n is.
A PC-n nincs felrakva még az ufw sem, tehát minden port nyitott.
Az IP-cím is klappol, mert különben az ssh sem találna oda.Így mutat az OpenWRT:
Mi lehet a gondja, hogy torrent kliensben a "Connection status: Firewalled" rémséget mutatja?Feltételezem nem a Router-ben beállított HW-NAT okozza a hibát. Legalábbis remélem.
-
vargalex
Topikgazda
válasz
.-..-.
#20910
üzenetére
Nem lehet, hogy éppen a névfeloldás állt meg nálad? Az
openresolvcsak opcionális függősége awireguard-tools-nak és ahogy a linkelt bejegyzés is mutatja, megysystemd-resolved-el is (sőt, az az ajánlott), csak fel kell tenni asystemd-resolvconf-ot.
Sőt, konkrétan a linkelt bekezdés kiemeli aNetworkManager-t, hogy az ugye alapból nem használja aresolvconf-ot, így megállhat a névfeloldás (lehet, hogy ez történt korábban is nálad). És ez ugye csak akkor probléma, ha a teljes forgalom awireguard-on van keresztülzavarva.
A wiki-t mindig érdemes átnézni. De ez már lassan inkább az Arch topicba való, hiszen régen nem az OpenWrt-ről beszélünk.A portforward-nak működnie kell, ha nincs tűzfal a szerveren, illetve ha publikus IP-t kapsz a szolgáltatótól (azaz a WAN IP-d egyezik pl. az itt láthatóval).
Én egyébként
systemd-networkd-t használok a szerveren. DesktoponNetworkManager-t.Szerk.: De nem kell ám mindig új install...
-
.-..-.
tag
válasz
vargalex
#20909
üzenetére
Már nem vagyok biztos semmiben
Nekem elég érthetetlen, hogy VPN nélkül például miért nem volt például portforward, holott a routeren beállítottam.
Az sem tetszett, hogy a wg-quick-nek (wireguard-tools) kellett az openresolv és így tiltanom kellett a systemd-resolved-t.Simán lehet, hogy én szúrok el valamit, de akkor nagyon lépésenként kéne épitkezni.
Kezdve a LAN probléma kiderítésével.
Azt már elfogadtam, hogy egy ideig nem lesz a megszokott seed, majd megy, amikor megy.De akkor most visszatérek a kályhához...
- teljesen új install (Arch)
- systemd-networkd - a hálózathoz (talán Static ismét és nem DHCP)
- systemd-resolved - a névfeloldáshoz
- közvetlen kapcsolat a Router-szerver között, új CAT6 kábellal (eddig CAT5e volt)
- nem lesz VPN (egyelőre)
- lesz PortForward (egyelőre)
- lesz Samba (ez az egyetlen ami rendben is működött mindig)Aztán ha ezek mennek rendesen, akkor mennék tovább.
A LAN kapcsolat probléma mellet ezt a PortForward dolgot is ki kéne deríteni, mert érthetetlen, hogy miért nem működött.Egy kérdés amúgy:
Te (vagy más, aki foglalkozik ilyennel) milyen network-manager-t használsz szerver esetében a wired kapcsolathoz?
(NetworkManager, systemd-networkd, netctl ... etc) -
-
.-..-.
tag
Teljes katasztrófa ...
Arra jövök haza, hogy nagyjából 22 óra környékén megint leállt minden seed.
Sem a router, sem a szerver logban nincs semmi erre utaló jel. Nem mutat lan kapcsolat eldobást.A szerver logban ennyi látszik aból az időszakból:
Apr 16 17:00:12 server systemd[1]: Starting Cleanup of Temporary Directories...Apr 16 17:00:13 server systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.Apr 16 17:00:13 server systemd[1]: Finished Cleanup of Temporary Directories.Apr 16 21:23:19 server kernel: perf: interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 79000Apr 16 22:27:05 server systemd-timesyncd[390]: Timed out waiting for reply from 81.0.124.253:123 (2.arch.pool.ntp.org).Apr 16 22:27:15 server systemd-timesyncd[390]: Timed out waiting for reply from 195.111.92.55:123 (2.arch.pool.ntp.org).Apr 16 22:27:25 server systemd-timesyncd[390]: Timed out waiting for reply from 62.112.195.56:123 (2.arch.pool.ntp.org).Apr 16 22:27:36 server systemd-timesyncd[390]: Timed out waiting for reply from 193.227.197.2:123 (2.arch.pool.ntp.org).Apr 16 22:27:46 server systemd-timesyncd[390]: Timed out waiting for reply from 193.227.197.2:123 (3.arch.pool.ntp.org).Apr 16 22:27:56 server systemd-timesyncd[390]: Timed out waiting for reply from 193.6.222.20:123 (3.arch.pool.ntp.org).Apr 16 22:28:06 server systemd-timesyncd[390]: Timed out waiting for reply from 213.157.100.71:123 (3.arch.pool.ntp.org).Apr 16 22:28:17 server systemd-timesyncd[390]: Timed out waiting for reply from 194.38.104.150:123 (3.arch.pool.ntp.org).A szerveren jelenleg nincs internet elérés sem, kizárólag az itthoni hálózat él.
Nem értem az egészet. Nem a VPN használat kavar be neki ennyire?
Lehet egy ideig VPN nélkül kellene kipróbálnom?Elméletileg futott a service, de egy "systemctl restart wg-quick@wg0" hatására visszajött a szerveren a net.
-
.-..-.
tag
válasz
vargalex
#20906
üzenetére
Természetesen nem. Különben az itthoni RasPi kliensek sem találnák meg a filmeket rajta
De most amúgy is már VPN mögött van, szóval nincs használatban a port.
Viszont nem értem miért nem akart működni. Mindegy, most már lepróbálni sem tudom, mert a wg0-t használja a torrent kliens.Még várom a Lan eldobásról a log-ot...
-
.-..-.
tag
válasz
vargalex
#20904
üzenetére
Természetesen. Nincs ufw sem (még) és a kliesben is az a port van beállítva és úgy tűnik a szolgáltató sem rakott NAT mögé.
Mondjuk most éppen a wg-quick (wireguard-tools) és a resolvconf (openresolv, függősége a wireguard-tools-nak) segítségével próbáltam VPN-t beállítani.
Nem látom, hogy azzal menne esetleg a dolog ...Update ...
Megjött a VPN kapcsolat a wg0-val. -
.-..-.
tag
válasz
vargalex
#20901
üzenetére
Az a reviziós LAN, a másik alaplapban volt.
Abban a miniITX lapban, amit most is használok és régebben is ezt használtam, olyan kártya van, mint a tiedben.03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 11)Tegnap megpróbáltam systemd-networkd használattal beállítani a VPN-t, de nem sikerült.
Volt wg0 eszközöm, de nem működött valamiért. Talán rossz helyre írtam az értékeket a szolgáltató által adott conf fájlból, nem tudom.
Mivel nem sikerült systemd-networkd esetében bekonfigolnom a VPN-t, ezért letiltottam és a NetworkManager-t raktam fel. Azzal beimportálva működött a VPN.
Így ment egész éjjel és reggelre láttam a hibákat.Most újratelepítettem az Arch-ot ismét és VPN nélkül használom systemd-networkd megoldással. Így figyelem lesz-e valami hiba.
Arra számítok, hogy valamelyik oldalon lesz a logban bejegyzés.Most próbáltam a Router-ben PortForward-ot beállítani, de valamiért a torrent kliens tűzfal mögötti állapotot jelez.
Elrontottam valamit?
-
vargalex
Topikgazda
válasz
.-..-.
#20893
üzenetére
A systemd-networkd-nek natív wireguard támogatása van. De wg-quick-hez is van systemd service, nálam azzal megy.
#20894 devast: A kollégának nem a routeren fut a wireguard...
-
vargalex
Topikgazda
válasz
.-..-.
#20900
üzenetére
Sajnos olyan is előfordul, hogy 2 hálózati eszköz "inkompatibilis" egymással. Persze ezt akár ki is lőhetnénk, hiszen azt írtad, hogy korábban évekig nem volt vele semmi gond.
Viszont nyilván azóta cserélődött a kernel, így a kernel modulok is mind a router, mind a szerver oldalán. Esetleg meg lehet próbálni Arch-on egy LTS, vagy ZEN kernellel is, hátha változik a helyzet.Egyébként nekem ez a hálókártya van a mini szerveremben:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 11)Tehát az, mint a tiéd, csak másik revízió. Nem használok AUR kernel modult. Korábban Atheros ar71xx routereim voltak, majd MT7621-esek, most Mediatek Filogic (természetesen mindegyik OpenWrt-vel), egyikkel sem volt problémám.
Ha Budapesten laksz, én is fel tudok ajánlani tesztre konkrétan Asus RT-AC65-öt is.
Még az lehet, hogy az AC-65P tápja, vagy belső tápáramköre haldoklik, így esetleg egy tápcserét is megpróbálhatsz.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Pont előttem kérdezték meg.
Mi lehet a gondja, hogy torrent kliensben a "Connection status: Firewalled" rémséget mutatja?
Új hozzászólás Aktív témák
Hirdetés
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Játékkulcsok a legjobb áron: Steam
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Bomba ár! Dell Latitude 5400 - i5-8GEN I 16GB I 512SSD I 14" HD I HDMI I Cam I W11 I Gari!
- BESZÁMÍTÁS! Gigabyte B450 R7 5700X 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman Z1 Seasonic 650W
- Bomba ár! Dell Latitude 7480 - i5-6GEN I 8GB I 256GB SSD I 14" FHD Touch I HDMI I Cam I W10 I Gari!
- BESZÁMÍTÁS! Gigabyte H610M i5 12400F 32GB DDR4 512GB SSD RX 6700XT 12GB Rampage SHIVA Seasonic 650W
- IKEA Format lámpák eladóak (Egyben kedvezménnyel vihető!)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest