Hali, teljesen céges policy függő.
Ahol annyira nem szigorúak, ott az internet felé port szerint nem szűrűnk, maximum tor-t, torrentet ilyeneket blokkolunk.
Ahol szigorúak ott 80, 443, icmp és csókolom más ne kelljen. Vagy ha mégis, akkor az külön elbírálási alapon megy.

szíszíenpí vájörlesz /én

Én átlag usernek a 80, 443-at is tiltom, böngészésre ott a proxy, azon keresztül kimehet.

Egész életemben azon gondolkodtam, hogy kéne valamit dolgoznom. Ezért aztán a végén nem is maradt rá időm.

Az 55'555 port felé is átmegy a proxyn. Vagy tévedek?

Ha jól sejtem, akkor a nyitott 80/443-as portnál ki tud menni a felhasználó vpn-nel (oda állítja a portot), míg proxynál ezt nem tudja nem tudja megcsinálni (mivel van egy köztes szerver).
Vagy rosszul értelmezem?

A rosszban mindig van valami megtévesztően jó, különben nem választanánk a rosszat

Még egyszer visszatérek a VLAN-os kérdésemre, mivel innen a fórumból két homlokegyenest ellentétes tanácsot kaptam.

A kérdés tehát az, hogy ha van egy nem VLAN-t támogató kombi routerem, de az a LAN-portján egy multilayer switchre csatlakozik, amely ténylegesen az itthoni LAN-t szolgálja ki fizikailag, akkor ezen a switchen tudok-e VLAN-okat kezelni.

Az alábbi két választ kaptam provátban:

1. Nem tudok, mert a router switche nem VLAN-képes, márpedig ott választódnak szét az alhálózatok, és a saját switch nem tud mit kezdeni a wifikkel. Tehát csak akkor működne a dolog, ha a router-eszköz már lekezelné ezeket is. Tehát a wifiről mondjak le, hacsak nem tudom a routert CLI-ből konfigurálni, ami nem is biztos, hogy menni fog Merlinben.)

2. Minden további nélkül menni fog a dolok, csak arra számítsak, hogy a switch a router felé untagged kapcsolatot tud csak létesíteni, tehát a VLAN-ok csak a switch felől fognak érvényesülni (ami mondjuk számomra is triviális), tehát a switch Ethernet-portjait VLAN-okba tudom szervezni, csak a wifi ki fog ebből maradni, de a switchben össze tudom kötni a wifit az összes VLAN-tartománnyal.

Szerintetek?

(Attól, aki a tévesnek bizonyuló véleményt írta, előre is elnézést kérek.)

Közönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Nemigazán értem a kérdést, de ha egy vlan aware switchen két külön vlan untagged portját bekötöd egy másik switchbe akkor azon keresztül minden további nélkül eléri egymást a két vlan, ergo semmi értelme a vlanoknak így.

Switch Tax

Pont ez az, amit szeretnék tisztán látni, mert ellentétes információt kaptam.

A két switchemből az egyik a router-eszköz switche, a másik a Ubiquiti multilayer. Ebbe van bekötve a ház minden Ethernet-vezetéke. (A router switch többi LAN-portját nem használom.)
A kérdés az, hogy ha a Ubiquitin csinálok VLAN-okat, akkor azok hogyan fognak működni. (A wifit most hagyjuk, az triviálisan a router-switchez kapcsolódik.)

Leegyszerűsítve a két kapott választ:
1. Nem fognak működni, mivel a router és a Ubiquiti között untagged kapcsolat van, és a router-switch összemossa a VLAN-okat, a wifit is beleértve. Tehát VLAN-jaim cím szerint lesznek, de nem fognak elkülönülni.
2. Működni fognak, mivel a Ubiquiti a router-switchtől elkülünülten működik. Mondjam meg a Ubiquitinek, hogy a VLAN-ok lássanak ki a netre (De hogyan?), és hogy melyik IP-címről lehessenek elérhetőek.

Számomra is az Általad leírt a logikus, azaz a Ubiquitiben csak azt tudom megmondani a VLAN-oknak, hogy lássák a router-switchet, mivel a kapcsolat odáig untagged. Tehát nem tudom azt mondani, hogy a WAN irányába lássatok csak, hiszen az untagged kapcsolat már nem tud különbséget tenni a WAN és a LAN-portok között -- arra csak maga a router képes, az viszont éppen nem VLAN-barát. (Ezért is untagged a kapcsolata a Ubiquitivel.)

A probléma aktualitását az adja, hogy most kell eldöntenem, hogy visszavigyem-e a VLAN-os Asus routert. Nekem úgy tűnik, hogy ha VLAN-okat akarok, akkor a WAN és a LAN-hosztok között minden switchnek VLAN-képesnek kell lennie (hiszen taggelni kell az adatfolyamot) -- de ennek mond ellent a 2. vélemény.

Köszönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Sziasztok!

Meg van a megoldás: "Protocol" TCP-re kell állítani és utána megy mind2 irányból az OpenVPN.

És sebességre milyen a TCP-n az OVPN?

MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Mintha gyorsabbnak tűnt volna, mint az UDP.

az ovpn tcp-n lassabb, nagyjából harmada. viszont nem fogyasztja el a memóriát, ez kevés memóriás eszközön számít.

szerk: csomagvesztéses hálózaton lehet gyorsabb a tcp.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az alap"probléma", hogy a routered az nem egy eszköz. A router rendszerint egy switch és egy router. A switch egy hardveres csomaghajigáló, a router pedig szoftverből pakolgatja a csomagokat. Egy másik történet, hogy a router switche képes úgy működni, mintha a processzor saját ethernet interfésze lenne. legalábbis openwrt alatt.

Az előfordulhat, hogy a routered gyári szoftvere nem kezel vlan-t, de a switch majdnem biztosan kezel, mivel úgy szokták megoldani a wan/lan kapcsolatot, hogy egy portot kineveznek wan-nak, a többit lannak, és azt tagged cpu linken tolják be a router procinak.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Továbbra sem értem.

Ha nincs VLAN aware routered (és a switch se L3 switch) akkor nem tudsz a különböző VLAN-ok között forgalmat irányítani.

Untagged VLAN-ok olyan mintha teljesen külön switchek lennének. Most ha van egy switched amiben össze vannak dugva, de a routerre nincs bekötve, akkor ott csak magukban lesznek, se internet, se semmit amit a router csinál.
Ha meg rádugod azt is a router beépített switchére, akkor onnantól egy LAN az egész, és a külön VLAN értelmét veszti.

szerk.: Úgy még lehet, ha külön router portokra dugod őket akkor nem kell tudnia a VLAN-t a routernek, de amelyik tud külön routing portokat kezelni, az VLAN-t is tud...

[ Szerkesztve ]

Switch Tax

Hali!

Ha jól értem, akkor olyan routered van ami képes több hálózatot kezelni, de nem képes vlan-t taggelni. Semmi baj, megoldható.
További feltételezésem, hogy a routered úgy tud több hálózatot kezelni, hogy a hálózatjait az interfészeihez rendeli, tehát ha van mondjuk 4 portja, mondjuk úgy, hogy 1-es port 192.168.1.0/24, 2-es port meg 192.268.2.0/24.
Ebben az esetben az a dolgod, hogy mind a két portját bekötöd a vlan-képes switch-edbe, a switchen meg megmondod, hogy az egyik port access (untagged) vlan 1 a másik pedig access vlan 2. Itt gyakorlatilag kész is vagy, amelyik eszköznek az egyes vlan kell annak kiadod accessben azt, amelyiknek a kettes, annak meg azt. A router pedig végzi az átjárást a kettő között.

A másik realitás, amennyiben a routered képes vlan-t taggelni, akkor elég egy kapcsolat a router és a switch közé, mindkét oldalon meg taggelve a trunk kapcsolat a megfelelő vlan tag-ekkel. A további pedig ugyan az, akinek ez kell az access ez akinek meg az annak az.

szíszíenpí vájörlesz /én

Mindenkinek nagyon köszönöm a választ!

A router nevű kombi eszköz (nem tudom, hogyan kéne hívnom, ezért eddig router-eszközöztem) elvben VLAN-képes, a saját gyári konfigurációján túl is. Ez egy Asus készülék (RT-AX86s), amelyiken Merlin FW fut, amelyik pedig CLI-ből ismeri a VLAN-okat. Csak én sajnos nem találok rá dokumentációt.

Az újabb eszköz, amelyik visszavitelén vacillálok, szintén Asus, mégpedig egy GT-AX6000u. Ebben Guest Network PRO néven már alap szinten konfigurálható VLAN-funkcionalitás van, tán öt VLAN-nal, az AP-ot is vezérelve -- csak még nagyon érezhető rajta a kezdeti stádium minden nyűgje. (A meshre pl. csak egy-egy VLAN-t enged ki frenkvenciatartományonként, ami IoT esetén nem előnyös...)

Köszönettel: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

ha a routeredbe kell wifi, akkor asus.
ha a routered csak router, akkor mikrotik. az 5009-es mikrotik elég jól sikerült darab.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Éppen ezért volt a dilemma arra, hogy visszavigyem-e a GT-AX6000u-t és így maradjon-e az RT-AX86s. (Amikor ezt vettem, még nem volt PRO és VLAN.)

Úgy döntöttem, hogy marad a GT, bár a VLANképessége az AIMesh node-okon fájdalmasan korlátozott -- de állítólag már úton van a frissítés, és talán Merlin is fejleszt még.

Nem szoktam ugyan két évente routert cserélni, de ez így most belefér, a családban körbeshiftelődnek a kiváltott darabok.

Továbbá a napokban kipróbálok egy Mikrotiket is, az mégiscsak férfiasabb irány!

Mindenkinek köszönöm a segítséget: MaCS

Fán nem lehet motorozni, motoron viszont lehet fázni!

Sziasztok!

Érdekes problémával állunk szemben mehelyen.
Van egy performance desktop gép, alaplapi Intel hálókártya van a céges hálóra és ezáltal az internetre is kötve.
Külön I350 4portos hálókártya pedig a belső hálón ér el egy másik offline PC-t és egyéb eszközöket, fix IP-n.

Valamennyi futás után, pár óra, de lehet hogy egyéb trigger is van (bealszik a gép, vagy futtatunk valamit) egész egyszerűen nem elérhetőek dolgok a hálózatán. A saját címét lehet pingelni a hálókártyának, de sem vele mást a hálón, sem őt a hálóról nem lehet pingelni.
Bizonyos belső hálós shared mappák elérhetőek voltak, de javarészt inkább nem.

Nem jelez semmi hibát ,csak nem működik. Újraindítás után minden frankó.

Valami windows update/driver verzió összeakadásra gyanakszunk.

Intel 2022.11.03-madikai driver van fent az alaplapinak, és 2022.12.21 az I350-nek.
Most felrakok egy új drivert, hátha megoldja.

Bárki tapasztalt hasonlót?

https://tinyurl.com/rasoapro

Szia.

Először is az eszközkezelőben a hálókártya tulajdonságainál ellenőrizd, hogy ki van kapcsolva az energiatakarékosság.

Második körben meg rakjátok fel a wireshark-ot, akasszátok rá a problémás interfészre és nézzük meg milyen kommunikáció megy ott amikor a hiba fennáll.

szíszíenpí vájörlesz /én

Kíváncsi voltam, kipróbáltam és tényleg lassabb.

Az OpenVPN egy Asus RT-N18U-n futott (FreshTomato 2023.4, a router-re rá volt dugva egy sima USB-s WD merevlemez. SMB-n keresztül mozgattam egy nagyobb iso file-t.

Lan-on keresztül:
- SMB írás: 19MB/s
- SMB olvasás: 24MB/s

UDP-s OpenVPN:
- SMB írás: 4.8MB/s
- SMB olvasás: 2MB/s (ezt nem teljesen értettem, hogy miért ennyi)

TCP-s OpenVPN:
- SMB írás: 3.15MB/s
- SMB olvasás: 2.4MB/s (ezt sem értettem teljesen)

[ Szerkesztve ]

Proxy az layer 4-7, a vpn meg layer 2-3.

Switch Tax

Nem az a probléma, hogy az osi elavult-e vagy sem, hanem hogy ma már senki sem alkalmazza. Anno a nagyon régi szép időkben volt OSI szabványnak megfelelő hálózat is, de a többség már akkor sem az volt, és amióta gyakorlatilag ethernet-ip alapon működik minden, azóta fel sem merül az osi.

Egyébként hivatkozási modell volt, annak jó.

A másik, hogy egy rakás "szakértő" nyilatkozik hálózatokról, például nekem tanítottak olyat, hogy az ip az négyrétegű protokollcsalád, aminek a 3. rétege az ip.

A távközlésből folyton kihalnak a távközlési mérnökök által tervezett szabványok

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az openvpn például layer 2/3.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az l2tp-nek még a nevében is benne van a Layer2.

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Nem az a kérdés, hogy hogy működik, hanem hogy mit valósít meg. OpenVPN az vagy Layer 2-t valósít meg a TAP adapterrel vagy Layer 3-at a TUN adapterrel.

[ Szerkesztve ]

Switch Tax

Az összes VPN úgy működik, hogy becsomagolja a packetet valamibe amit aztán elküld.

Az L2TP is UDP vagyis Layer 4 fölött működik. De attól még egy Layer 2 összekapcsolást valósít meg.

[ Szerkesztve ]

Switch Tax

Vonatkozásban még mindig használjuk, bár inkább tényleg csak négyig szoktunk számolni már.
Legalábbis akármelyik cég mérnökével is egyeztettem eddig mindig tiszta sor volt, hogy
Layer 1 - Fizikai (kábelezés vagy rádió kapcsolat)
Layer 2 - Mac cím, subnet-en belüli forgalom stb
Layer 3 - IP Routing, subnetek közti forgalom / irány az internet
Layer 4 - Alkalmazás, tcp udp stb.
(És a rettegett titkos Layer 8, ahol a legtöbb hiba található - A júzer )

Tehát az, hogy az openvpn L4 mivel (beállítástól függően tcp vagy) udp csomagokba van becsomagolva a forgalmad. Kvázi duplán van csomagolva és tls-el titkosítva.
Ezeket a megoldásokat hívjuk gyűjtően SSL vpn-nek. Ezekhez amúgy nem feltétlen kell külön szoftver/hardver, mivel minden böngésző használja az ssl-t (ami mamár igazából tls), így működik a brave vagy az opera beépített vpn-je, illetve a sok egyéb chrome extension.

Az ipsec pedig L3, mivel itt az ip rétegben megy a titkosítás. Itt a tcp/udp csomagokat nem egy újabb tcp/udp csomagba rejtik el, hanem egy AH vagy ESP header kerül rá az ip csomagra. Ennél mindenféle cryptográfia algoritmussal titkosítják a csomagot, kulcsot kell cserélni stb. Az ipsecnek sokkal nagyobb az erőforrás igénye.

Az eredeti kérdésre visszatérve pedig a különbség a proxy és a vpn között, hogy a vpn egy titkosítási metódus ami két végpont között egy "csatornát" hoz létre. Fontos viszont, hogy ez a titkosítás csak a két végpont között jön létre, onnan pedig szűzen megy tovább amerre kell. Tehát az, hogy te bekattintod a nordvpn-en vagy bármely tetszőleges vpn szolgáltatón, hogy Amerikából gyüttem, az annyit jelent, hogy a vpn kliensed a (jóesetben amerikába lerakott és nem csak oda proxyzott) vpn szerverrel elvégzik a tls kézfogást és felhúzzák a "csatornát". A csomagod így először elmegy a vpn szerverhez és ott, annak a publikus ip-jén lép ki a net-re, az eredeti állapotában. (Legyen az amúgy is titkosítva pl https, vagy titkosítatlanul.)

A proxy pedig majdnem ugyan ez, csak nincs ráhúzva titkosítás. Itt egyszerűen "meg van mondva", hogy minden csomagot a proxy szervernek kell küldeni. (Minden út Rómába vezet.. ) Majd a proxy dobja ki a netre.

Proxy-t inkább a vállalatok szoktak használni, hogy minden forgalom egy központosított, ellenőrzött helyről lépjen ki a netre, itt tudják szűrni a csomagokat, pl eldobja azt ami a p.hub felé menne. (Ez amúgy a mai modern tűzfalak mellett már kezdi értelmét veszteni, mert az ilyen szintű szűrések már ezeken is rendelkezésre állnak, míg a régi routerek ilyet nem tudtak.) A fordított változata (revproxy) pedig azért felel, hogy a nagyvilág felé csak egy ip látszódjon, a bejövő kéréseket pedig a megfelelő kiszolgáló szerverhez küldi el. (Ezt részben szintén a tűzfalak, de inkább a modern loadbalancer-ek végzik.)

Tehát míg egy proxyzott forgalomba bárki bárhol beleolvashat, a vpn csatornába nem lehet belelátni, így az (internet) szolgáltatód nem tudja milyen kétes jellegű oldalakat látogatsz. (Helyette a vpn szolgáltatónak adod át ezeket az infókat. )

szíszíenpí vájörlesz /én

VPN-nek több alkalmazási lehetősége is van.
Ha úgy nézzük akkor igen, egy titkosított proxy. De beállítás függő, hogy mennyi minden is menjen a vpn szerver felé.
Így két csoportra bontható, Full-tunnel és split-tunnel.
Full esetén a kliens kap egy 0.0.0.0/0 route-ot ami azt jelenti, hogy mindent a szerver felől lát.
Split esetén meg például csak a vállalat belső hálózatának a subnetjeit.
Pro-kontra, hogy a full esetén az internet böngészése is egyszerűen monitorozható / szűrhető, cserébe ez is a vállalat erőforrásait eszi, effektíve duplázva az internetes lábon a forgalom (bejön és ki is megy). Míg split esetén csak a szükséges forgalom érkezik be, a munka mellett elindított youtube, torrent nem a vállalatot terheli.

szíszíenpí vájörlesz /én

a layer 4 az nem alkalmazás, az alkalmazás az szigorúan l5.
az alkalmazások nem ip-t, hanem tcp-t vagy udp-t használnak, tehát nem lehetnek l4-ben.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Sziasztok!

Asus RT-N18U-hoz milyen külső antennát javasoltok, hogy jobban "kilásson" a rack szekrényből? (erősebb legyen a wifi jel)

lecsatolhatót. meghosszabbíthatót.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A Layer 4 az a TCP/UDP.

Switch Tax

gondolom ezt a 12390-re akartad válaszul írni, nem nekem.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Neked írtam, te vagy elcsúszva egy layerrel. Olvasd vissza mit írtál.

Switch Tax

akkor olvass vissza, hogy abban a hsz-ben hangzott el a hibás állítás, én pedig azt korrigáltam, amit te félreértettél.
utána pedig fáradj át a moderátor topicba és töröltesd ki az egész althreadet.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem jól írtad fogadd már el. Az UDP meg a TCP az Layer 4 ahogy ő is írta.

Ja értem már mire gondolsz, hogy az alatta lévő layer-t "használja"

[ Szerkesztve ]

Switch Tax