-
GAMEPOD.hu
Ubiquiti hálózati eszközök - téma összefoglaló
Új hozzászólás Aktív témák
-
Protezis
őstag
Egy EdgeRouter 4 eszközt (meg persze sok minden mást) szeretnék 10"-es rack szekrénybe rakni. Hivatalosan csak 19"-esbe lehet rögzíteni, de nekem egy tálcás módszer is megtenné. Valaki próbált már ilyet, mi a tapasztalat? Rack szekrénnyel sincs semmi tapasztalatom.
Elvileg belefér, ha lenne 3D nyomtatóm, meg is oldanám: [link] -
Protezis
őstag
válasz Varszegig #9281 üzenetére
Köszönöm azért! :)
Ez ugye 2 darabból áll, és a hátsó is rögzítve van a szekrényhez. Amit kinéztem szekrényt, ott csak a front oldalon lehet rögzíteni eszközöket. Megnézve más szekrényeket, mindenhol ez van. Nem tudom, hogy lehet-e külön venni extra 2db 9U magas lemezt a szekrény hátsó felébe. Kezdő vagyok még a témában, a nevét se tudom ezeknek.Berendeltem egyébként a szekrényt is, meg 3 tálcát. Mivel szélesebb a router, mint 222.25 mm, a tálcára is csak úgy fér rá, ha azt fejjel lefele rögzítem. Sok helyen bukhat a számításom, remélem azért össze tudom legózni a dolgokat. Majd megírom a tapasztalataimat.
-
Protezis
őstag
-
Protezis
őstag
A hálózatom fontosabb elemei:
- EdgeRouter 4
- Zyxel GS1200-8HPv2 switch
- Unifi 6 LiteRouterben:
- eth0-án jön be a net
- eth1 a "normál" hálózat (192.168.10.1/24
)
- eth1.2 (192.168.20.1/24
) pedig a guest hálózat.Switch-ben az 1-es VLAN-on minden port untagged, a 2-es VLAN-on pedig a routerrel és az AP-vel összekapcsolt 2 port van taggelve.
Kérdésem: most lőttem be először VLAN-t és most használok először Unifi Controllert. Bár látszólag minden működik, a Controller-ben a Default network
192.168.1.0/24
. Kell ezzel foglalkoznom?--------------------------------
Volt szó korábban EdgeRouter 4 és 10"-es rackről. A 3D-s modellre kaptam egy 5k-s ajánlatot, így inkább egy sima tálcával oldottam meg. Azt viszont fordítva kellett beszerelnem csakúgy, mint a switch tálcáját, így buktam a szekrényben 1U-t. Majd egyszer ha kell a hely, kinyomtatom valahol olcsóbban.
-
Protezis
őstag
válasz MasterMark #9335 üzenetére
Köszi, akkor hagyom úgy, ahogy van.
Ugye?! Én imádom nézegetni
Én ezt vettem: Lanberg PPKS-9112-B 10" Patch panel - 12 port
A keystone csatlakozókat meg innen: Vention Cat.6 UTP Keystone Jack csatlakozó, 5 darabos fekete - Keystone
Egyébként hűtésre meg vettem egy 5V-os Noctua 12cm-es ventillátort, amit az EdgeRouter USB portjáról hajtok meg. Ha másra nem, legalább erre jó A ventillátor szabályozó szintén Noctua, nélküle elég hangos volt.[ Szerkesztve ]
-
Protezis
őstag
Én a ping-et is szoktam még engedélyezni a local-on.
rule 30 {
action drop
description "drop ping flood"
icmp {
type 8
}
log enable
protocol icmp
recent {
count 20
time 10
}
}
rule 40 {
action accept
description "allow ping"
icmp {
type 8
}
log disable
protocol icmp
recent {
}
} -
Protezis
őstag
EdgeRouter 4 tud static link aggregationt? Mindenhol csak az LACP bondingot találom, de azt nem tudja a switchem.
-
-
Protezis
őstag
válasz MasterMark #9719 üzenetére
Köszönöm mindkettőtöknek, ez biztató. A hw offload vajon mindegyiknél működik?
A switchem static load balanceot tud, nem tiszta, arra szükség van-e egyáltalán. Mindenesetre utána olvasok ezeknek a módoknakEgyébként a Synology NAS is 2 kábellel van bekötve, bonding interface-szel. A célom az lenne, hogy külön VLAN-na rakom a NAS-t (DMZ). Az inter-VLAN routing meg L3 switch hiányában a router csinálná. Nyilván szeretném minél kevésbé limitálni az egyes VLAN-ok közötti forgalmat, valamint a gigás net elérést. Ezért gondoltam a switch és a router között is egy bondingra, mint megoldásra. Hibázik valahol ez?
[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #9721 üzenetére
Zyxel GS1200-8HP v2. Source, destination, vagy mindkét (egyszerre) MAC alapján tud hasht.
53. oldal: https://download.zyxel.com/GS1200-8HP_v2/user_guide/GS1200-8HP%20v2_V2.00_Ed1.pdf -
Protezis
őstag
Megosztanám kicsit részletesebben, hogy sikerült beállítani EdgeRouter 4-en a bondingot.
Amit el szerettem volna érni
L3 logical networkA NAS-t DMZ-be akartam rakni, ne lásson rá más hálózatokra. A NAS-on van még DNS szerver, valamint Dockerben fut az Unifi controller. Amiről végül lemondtam, mert úgyse használtam, az a Dockerben futó HomeAssistant.
Mivel a NAS már eleve 2 kábellel csatlakozott "Adaptivel Load Balancing"-gal, szerettem volna továbbra is potenciálisan 2 Gbit-tel elérni. A DMZ miatt viszont inter-VLAN routingra van szükség, így minden csomag átmegy a routeren. A switch-router közötti 1 kábel így szűk keresztmetszet.
Az IoT & Guest network-öt szét lehetne választani, nekem egyelőre megfelel így egybe. IoT-be szánom a TV-t, Chromecast-eket, nyomtatót az egyéb okos-kütyük mellett (lámpa, porszívó). A munkás laptoppal is erre csatlakozok.
A megoldás
- switch oldalon static link aggregation a 7. és 8. porton,MAC SA & DA
-val
- router oldalon
-mode round-robin
-hash-policy layer2+3
Ezzel kábeles PC + wifi laptoppal kb. 1.5 Gbit-en töltök a NAS-ről. A szűk keresztmetszet a laptopon a wifi. A router CPU kb. 20-22%-on van ilyenkor (offload-ok be vannak kapcsolva).bonding bond0 {
address 192.168.10.1/24
description MAIN
hash-policy layer2+3
mode round-robin
vif 2 {
address 192.168.20.1/24
description Guest
firewall {
in {
name GUEST_IN
}
local {
name GUEST_LOCAL
}
}
}
vif 3 {
address 192.168.30.1/24
description DMZ
firewall {
in {
name DMZ_IN
}
local {
name DMZ_LOCAL
}
}
}
}
ethernet eth0 {
address dhcp
description Internet
duplex auto
firewall {
in {
ipv6-name WANv6_IN
name WAN_IN
}
local {
ipv6-name WANv6_LOCAL
name WAN_LOCAL
}
}
speed auto
}
ethernet eth1 {
bond-group bond0
duplex auto
speed auto
}
ethernet eth2 {
bond-group bond0
duplex auto
speed auto
}Chromecast és AirPlay is megy VLAN-ok között. A nyomtató még hátra van, Sonos hangfal meg marad a MAIN-ben... Ezekhez tűzfal configot tudok mutatni, ha valakit érdekel.
Amikkel szívtam
1. Többször is kilőttem minden hálózatot a routeren. Eleve a bondingot úgy kell megcsinálni, hogy törölni kell az ethernet interfészeket és commit. Emiatt beszereztem egy console kábelt. Ajánlom mindenkinek!2. Mivel a NAS másik subnetbe került, megváltozott az IP címe. Így az Unifi controlleré is. Az AP offline volt, annak ellenére, hogy működött. A megoldás az volt, hogy SSH-n belépek az AP-re és beadom set-inform-mal az új hostot.
3. A roud-robin-on kívül próbáltam minden mást is, szinte minden kombinációval beleértve a switch oldali configot is. A legtöbb nem is működik úgy, ha a switchen be van kapcsolva a LAG: a router is elérhetetlenné válik. Egyetlen szépséghiba van, ami még nem bizonyított: wifi-s eszközökről a feltöltés eddig mindig ugyanazon a kábelen (eth1) érte el a routert. Mivel az AP is 1Gbit-tel kapcsolódik a switch-hez, ez talán nem is akkora baj. Még egyszer: ezt nem teszteltem kimerítően.
4. Ajánlom a teljen config mentését a művelet előtt. Valamint én előre megírtam a parancsokat (87 sor). Nem lett 100%-os, de mégis sokat segített. Ne élesben írogasd
Köszönet MasterMark-nak és user12-nek.
[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #9738 üzenetére
Miért? LACP hiánya miatt?
-
Protezis
őstag
válasz MasterMark #9740 üzenetére
Amíg L3 (L2+?) switchben gondolkodtam, a TP-Link TL-SG2008-at néztem ki. Nem is drága, és baromi sok mindent tud. Olvasgattam is a több, mint 1000 oldalas manualt
Végül a bonding mellett döntöttem (egyelőre).
Miért gondolod szűk keresztmetszetnek a Zyxelt? Vagy úgy érted, hogy nincs vele semmi baj, de ha upgrade kell, akkor azt cseréljem először? A Switch Enterprise 8 PoE mondjuk tud mindent, amit szeretnék, csak az ára... -
Protezis
őstag
EdgeRouter-4 felületi hőmérséklete a portok körül 39-41 fok körül van. 10"-es szekrényben van. Ez így hosszú távon ok?
MasterMark: egyelőre elég port van, csak a desktop gép csatlakozik kábelen.
[ Szerkesztve ]
-
Protezis
őstag
Fut egy DNS szerver DMZ VLAN-ban, IP-je 192.168.30.10.
Egy másik VLAN-on lévő kliens IP-je: 192.168.20.22Az alábbi log bejegyzéseket látom, amiket EdgeRouter-4 loggol:
[DMZ_IN-20-D]IN=bond0.3 OUT=bond0.2 MAC=fc:ec:da:42:fa:a9:00:11:32:7b:aa:a5:08:00 SRC=192.168.30.10 DST=192.168.20.22 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=42160 DF PROTO=TCP SPT=853 DPT=38106 WINDOW=0 RES=0x00 RST URGP=0
A DMZ tűzfal configja:
# show firewall name DMZ_IN
default-action accept
description "DMZ to lan/wan"
rule 10 {
action accept
description "allow to DMZ"
destination {
group {
network-group DMZ
}
}
log disable
protocol all
}
rule 20 {
action drop
description "drop DMZ to lan"
destination {
group {
network-group LAN_NETWORKS
}
}
log enable
protocol all
state {
established disable
invalid enable
new enable
related disable
}
}Miért akar a DNS szerver új connectiont nyitni a kliens felé? Itt ugye DNS over TLS-ről van szó. A 853-as portra küldi a kliens a kérést, onnan szimplán válaszolnia kéne a szervernek.
-
Protezis
őstag
válasz MasterMark #9869 üzenetére
bond0.3, in
-
Protezis
őstag
válasz MasterMark #9874 üzenetére
A DMZ VLAN-ban lévő szerver csak a netre tud kimenni, valamint a bejövő kérésekre tud válaszolni. Ez remekül működik, DNS (UDP 53), HTTP, egyéb más dolgokra. A DoT esetén viszont mintha a szerver akarna kimenni, mivel a rule 20 szabály okozza a problémát. Az pedig ugye csak a new és invalid kommunikációt tiltja a LAN_NETWORKS irányba. Utóbbi a belső címeket takarja:
192.168.0.0/16
172.16.0.0/12
172.16.0.0/12[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #9876 üzenetére
Nem. A 192.168.30.10 szerver a bond0.3-ban van, ami a DMZ. A DMZ_IN szabályhalmaz a DMZ in -hez van assignolva. Nem használok sehol se "out"-ot.
A log azt mondja, hogy a szerver nem tudott csatlakozni a klienshez, a rule 20 ezt megakadályozta. Amit nem értek, mert alapvetően a kliens csatlakozik a DoT szerverhez, az csak válaszol (tehát RELATED packetek mennek a szervertől a kliens felé).
-
Protezis
őstag
válasz MasterMark #9878 üzenetére
Valamelyikünk nagyon félreért valamit, egyelőre nem tudom, hogy ki.
Tudtommal az "in" úgy általában a routerbe adott portról/interfészről bejövő forgalomra értendő, ami aztán egy másik portra/interfészre fog kimenni. A DMZ_IN szabályhalmaz a DMZ-ből (bond0.3) a routerbe bejövő, ám másik interfészt célzó (tehát nem local) forgalmat szűri. A DMZ-ben lévő szerver nem küldhet NEW, vagy INVALID csomagokat más VLAN-okba.
-
Protezis
őstag
válasz MasterMark #9880 üzenetére
Igen, így van. Jobb oldalon írja is, hogy "Disallow GUEST to LAN can be done on eth2 in or eht0 out". Én a DMZ in-t szűröm. A szervertől jövő válasz csomagoknak ESTABLISHED-nek kellene lennie, amit a tűzfalszabálynak nem kéne eldobnia. Mégis dobja.
[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #9883 üzenetére
A bond0.3 in, az a DNS szerver által küldött, nem a routert célzó csomagok. Ezeket szűröm a DMZ_IN szabályhalmazzal. Hol ezzel a gond?
-
Protezis
őstag
válasz MasterMark #9885 üzenetére
Ok, akkor csak nem irkáltam hülyeséget
Igen, ezt értem, de a meglévő szabályok tekintetében ez nem felesleges? A default action ACCEPT, és csak az INVALID és NEW csomagokat dobom el. Tehát az established és related csomagoknak menniük kellene, nem?
-
Protezis
őstag
válasz MasterMark #9887 üzenetére
Úgy néz ki, hogy félre volt konfigurálva a DNS szervernek a DoT része. Invalid volt a cert, szerintem az okozhatta. De a mélyére nem ástam le, hogy végül milyen csomagok voltak azok. Most működik a DoH és DoT is.
@MasterMark: Köszi a segítséget és a megerősítést, hogy jók a szabályaim. Ez nekem nagyon hasznos volt, a hálózatokban úgy általában még sok dolog homályos számomra.
Egyébként Adguard Home a DNS szerver, tesztelésre pedig ezt használtam. Egy kicsit nyögvenyelősen, de sikerült átjátszani a Let's Encryptes Certet a Synology-tól az Adguard-os Docker containernek. A DoH-t megoldja a container elé rakott Nginx reverse proxy, de a DoT esetén a kliens közvetlenül megy a szerverhez, amiatt kellett oda is a cert+privát kulcs.
[ Szerkesztve ]
-
Protezis
őstag
válasz bekes.andras #9945 üzenetére
Én a napokban lőttem be L2TP-t szintén EdgeRouter-4-en ezt a leírást követve. Az alábbi tűzfalszabályok vannak WAN_LOCAL-ra:
# show firewall name WAN_LOCAL | no-more
default-action drop
description "WAN to router"
rule 10 {
action drop
description "drop ping flood"
icmp {
type 8
}
log disable
protocol icmp
recent {
count 20
time 10
}
}
rule 20 {
action accept
description "allow ping"
icmp {
type 8
}
log disable
protocol icmp
recent {
}
}
rule 30 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 40 {
action drop
description "Drop invalid state"
log disable
state {
invalid enable
}
}
rule 50 {
action accept
description ike
destination {
port 500
}
log disable
protocol udp
}
rule 60 {
action accept
description esp
log disable
protocol esp
}
rule 70 {
action accept
description nat-t
destination {
port 4500
}
log disable
protocol udp
}
rule 80 {
action accept
description l2tp
destination {
port 1701
}
ipsec {
match-ipsec
}
log disable
protocol udp
} -
Protezis
őstag
válasz bekes.andras #9947 üzenetére
Nálam eth0 a WAN, router előtt szolgáltatói eszköz bridge módban. Saját DNS szerverem van, de szerintem működik akár külső (pl. 8.8.8.8), akár a router.
# show vpn | no-more
ipsec {
ipsec-interfaces {
interface eth0
}
}
l2tp {
remote-access {
authentication {
mode radius
radius-server 192.168.30.10 {
key {radius-server-key}
}
}
client-ip-pool {
start 192.168.100.240
stop 192.168.100.249
}
dhcp-interface eth0
dns-servers {
server-1 192.168.30.10
}
ipsec-settings {
authentication {
mode pre-shared-secret
pre-shared-secret {secret}
}
}
}
}
Ami még érdekes (és elkeserítő), hogy az L2TP forgalmat körülményes limitálni tűzfalban. IN oldalon nem lehet megfogni, csak OUT működik. Az összes LAN interface OUT-ját kell hozzárendelni. Nálam 3 VLAN van, a VPN klienseknek csak a DMZ-hez engedek hozzáférést az alábbi szabályokkal. Ha már van hasonló nálad, akkor esetleg ott van valami korlátozva.# show firewall name LAN_OUT | no-more
default-action accept
description ""
rule 10 {
action accept
description "Allow DMZ for VPN clients"
destination {
group {
network-group DMZ
}
}
log disable
protocol all
source {
group {
address-group VPN_RANGE
}
}
}
rule 20 {
action drop
description "Limit VPN clients"
destination {
group {
network-group LAN_NETWORKS
}
}
log disable
protocol all
source {
group {
address-group VPN_RANGE
}
}
} -
Protezis
őstag
EdgeRouterekhez jött frissítés.
-
Protezis
őstag
vicze1: Pontosan mit és hogy?
[ Szerkesztve ]
-
Protezis
őstag
Nincs mély tudásom a témában. De ahogy MasterMark írja, ha ugyanazok a kliensek (lassú, és gyors) csatlakozik ugyanazon AP-ra, akkor nem mindegy, hogy 1 vagy 2 SSID-n teszik azt? Van mérhető overheadje a 2 SSID-nek az 1-el szemben?
De persze külön AP, külön SSID és más frekvencia, akkor kimaxolhatod a dolgot. -
Protezis
őstag
Adott 2 Synology NAS egymástól 100 km-re. Mindegyik előtt egy-egy EdgeRouter-4. A 2 NAS között backupolni szeretnék, mindkét irányba. Milyen VPN megoldást javasolnátok?
Körülmények:
- Az "A" oldalon a NAS külön VLAN-ban van, a "B" oldalon nincsenek VLAN-ok
- Jelenleg mindkét oldalon egyazon belső IP tartomány van használva (legalábbis van átfedés)
- "A" oldalon már üzemel egy L2TP IPsec VPN az ER-4-en, oda telefonnal/laptoppal csatlakozok be távolról és érem el a NAS-t (meg használom a DNS szervert)
- DNS-sel elérhető mindkét oldal, fix IP nincs
- mindkét oldalon full accessem van mindenhezKövetelmények:
- A NAS-oknak fix IP-vel kell rendelkezniük a VPN-en belül
- A LAN-on lévő kliensek nem láthatják a másik oldali klienseket, sem a másik oldali NAS-tJelenleg ez úgy van megoldva, hogy "A" oldalon fut egy OpenVPN szerver a NAS-on, "B" oda csatlakozik és egymásra backupolnak. "B"-nek sajnos nincs fix belső IP-je, eddig szerencsére ez nem okozott gondot. Mégis, nem érzem teljesen megbízatónak. Ha lenne jobb megoldás, főleg az EdgeRouter-eken alapuló, akkor arra kíváncsi lennék.
[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #10152 üzenetére
Úgy érted, hogy mindkét routeren futna egy-egy Wireguard szerver és a NAS-ok a másik oldali szerverhez csatlakoznának?
-
Protezis
őstag
válasz ArthurShelby #10154 üzenetére
Hyperbackupot használok. Régen nyitott porton keresztül ment, azt cseréltem le a NAS-on futó OpenVPN-re, hogy biztonságosabb legyen.
[ Szerkesztve ]
-
Protezis
őstag
válasz ArthurShelby #10157 üzenetére
Nem értelek. Továbbra is HyperBackupot fogok használni, de ez most lényegtelen.
-
Protezis
őstag
válasz MasterMark #10159 üzenetére
Nem akarnék a tartományokon alakítani, meg tanulásnak se rossz, úgyhogy csináltam SNAT + DNAT-ot. Ma este belőttem az egyik routeren + iPhone-t használtam "kliensként", látszólag működik: a másik oldali interface IP-jét tudom pingetni, NAS-on futó DNS szervert is tudom használni a telefonon szintén a router oldali interface IP-jén keresztül. Bármi probléma lehet ezzel a megoldással? Teljesítményben nem tudom okoz-e veszteséget a NAT, de mivel egyik oldalon 20, másik oldalon 25 Mbit a max upload, szerintem nem fog fájni.
Köszi egyébként a tippet. A DDNS azonban okozhat gondot, ezt a workaroundot találtam: https://github.com/WireGuard/wireguard-vyatta-ubnt/issues/130
[ Szerkesztve ]
-
Protezis
őstag
válasz Protezis #10174 üzenetére
iperf3-al mérve mind OpenVPN-en, mind Wireguard-on 25-26 Mb/s sebességet értem el a 2 NAS között. Utóbbinál mivel a routerek csatlakoznak egymáshoz, néztem CPU használatot az egyik ER-4-en: lényegében kimutathatatlan, 1-2%.
@MasterMark: köszi a tippet! :) Néhány napig monitorozom, hogy minden ok-e, aztán lelövöm az OpenVPN szervert. -
Protezis
őstag
válasz MasterMark #10220 üzenetére
Erről jut eszembe: múltkor tippként írtad a Wireguardot, azóta használom. Viszont firmware upgrade-nél mi a teendő? Config backup, firmware upgrade, wireguard reinstall, backup visszatöltés?
-
Protezis
őstag
EdgeOS 2.0.9 alatt ezt be lehet üzemelni, van vele tapasztalat?
https://github.com/britannic/ubnt-bcast-relay[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #10635 üzenetére
Az már be van lőve. Most az SSDP-t akarnám inter-VLAN megoldani, ami egy broadcast UDP message az 1900-as portra. Log alapján be is jön a DMZ_LOCAL-ra, azt kéne a másik VLAN-ra átvinni, ha jól értem a dolgokat.
-
Protezis
őstag
Tűzfalat kicsit erősítettem, logban most megjelentek ilyenek:
[HOME_IN-50-R]IN=bond0.2 OUT=eth0 MAC=fc:ec:da:42:fa:a9:e0:d5:5e:48:9c:d2:08:00 SRC=192.168.20.10 DST=10.8.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=54825 DF PROTO=TCP SPT=49668 DPT=3260 WINDOW=64240 RES=0x00 SYN URGP=0
A 192.168.20.10 ez a gép, amiről írok (Windows 11), a 10.8.0.1 IP nem tudom, hogy mi. Segítsetek, mi ez? Ez egy belső IP, nem? (kezdek fejben szétesni )
Hálózati interfacek, EdgeRouter-4-ben.
Korábban futott egy OpenVPN szerver a Synology NAS-omon, 10.8.0.1 címen. A szerver bár nem fut már egy ideje, most uninstalláltam, az IP továbbra is válaszol ping-re.
Routeren az alábbit látom:
$ traceroute 10.8.0.1
traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 38 byte packets
1 10.226.128.1 (10.226.128.1) 8.278 ms 7.501 ms 7.585 ms
2 145.236.81.242 (145.236.81.242) 8.764 ms 8.097 ms 7.499 ms
3 Te0-0-0-0.er0-hatvan.net.telekom.hu (84.1.66.79) 16.498 ms 84.1.67.87 (84.1.67.87) 17.597 ms 84.1.67.85 (84.1.67.85) 17.441 mswg0 egy "site-to-site" Wireguard interface egy másik ER-4-gyel, SNAT és DNAT-tal megoldva, hogy csak és kizárólag a routerek mögötti Synology NAS-ok tudjanak egymással kommunikálni. A túloldali ER-4-re SSH-n belépve (ER-4 -> wg0 -> ER-4) az IP szintén látható, pingre válaszol.
Végül már csak azt nem értem, miért akar a gépem ehhez az IP-hez csatlakozni a 3260-as TCP porton, ami elvileg az iSCSI. Egyébként a gépem csatlakozik a NAS-hoz iSCSI-val, de a NAS IP-je 192.168.30.10
[ Szerkesztve ]
-
Protezis
őstag
válasz MasterMark #10721 üzenetére
Nincs neki, legalábbis a kérdéses IP nem szerepel itt:
# ifconfig
bond0 Link encap:Ethernet HWaddr 00:11:32:7B:AA:A5
inet addr:192.168.30.10 Bcast:192.168.30.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:232908670 errors:0 dropped:4418 overruns:4418 frame:0
TX packets:75444809 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:311875106983 (290.4 GiB) TX bytes:59713474277 (55.6 GiB)
docker0 Link encap:Ethernet HWaddr 02:42:B8:59:FE:EB
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
inet6 addr: fe80::42:b8ff:fe59:feeb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21958 errors:0 dropped:0 overruns:0 frame:0
TX packets:40373 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:64990137 (61.9 MiB) TX bytes:10042133 (9.5 MiB)
dockerad7 Link encap:Ethernet HWaddr DE:E7:1A:5F:11:9A
inet6 addr: fe80::dce7:1aff:fe5f:119a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20630 errors:0 dropped:0 overruns:0 frame:0
TX packets:39120 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:65104501 (62.0 MiB) TX bytes:9458313 (9.0 MiB)
dockerc34 Link encap:Ethernet HWaddr 2A:49:69:EB:B2:9A
inet6 addr: fe80::2849:69ff:feeb:b29a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1328 errors:0 dropped:0 overruns:0 frame:0
TX packets:19389 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:193048 (188.5 KiB) TX bytes:5235816 (4.9 MiB)
dockerd7b Link encap:Ethernet HWaddr EE:A5:3D:B0:42:A2
inet6 addr: fe80::eca5:3dff:feb0:42a2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18110 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:4646066 (4.4 MiB)
dockereb8 Link encap:Ethernet HWaddr E6:4E:BA:79:C1:84
inet6 addr: fe80::e44e:baff:fe79:c184/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:18110 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:4646066 (4.4 MiB)
eth0 Link encap:Ethernet HWaddr 00:11:32:7B:AA:A5
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:232574835 errors:0 dropped:4418 overruns:4418 frame:0
TX packets:47880102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:311849575734 (290.4 GiB) TX bytes:36408424387 (33.9 GiB)
eth1 Link encap:Ethernet HWaddr 00:11:32:7B:AA:A6
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:333835 errors:0 dropped:0 overruns:0 frame:0
TX packets:27564707 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:25531249 (24.3 MiB) TX bytes:23305049890 (21.7 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10445378 errors:0 dropped:0 overruns:0 frame:0
TX packets:10445378 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:3548440655 (3.3 GiB) TX bytes:3548440655 (3.3 GiB)Ping-re menne a gatewayhez, ezt viszont a tűzfal megfogja:
# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
From 192.168.30.1 icmp_seq=1 Destination Port Unreachable
From 192.168.30.1 icmp_seq=2 Destination Port Unreachable
From 192.168.30.1 icmp_seq=3 Destination Port Unreachable
From 192.168.30.1 icmp_seq=4 Destination Port Unreachable
^C
--- 10.8.0.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 1002msBocs a formázás miatt, az első CLI kimenetet sehogy sem tudom belevarázsolni monospace blokkba.
A wireguard interfaceket letiltva (disabled) a ping továbbra is megy.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5
- Bomba ár! HP EliteBook 830 G6 - i7-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!