-
GAMEPOD.hu
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
Beggar
csendes tag
Sziasztok!
Az elmúlt 2 évben 2 ismerősömre is rárúgta a TEK az ajtót, mert illegális tartalmak továbbítására használták a gépeiket. Ketten élünk a párommal itthon, mindketten laptopot használunk, valamint van egy kisebb szerverem ubuntu server 16.04-el. A router egy, a UPC-től kapott Technicolor TC7200-as csoda. Mi a véleményetek, valamint milyen módon lehet igazán növelni a belső hálózat védelmét?[ Szerkesztve ]
-
Topikgazda
-
btz
addikt
Valaki csinált már olyat, hogy 2 WAN 2LAN-os hálózat egy routeren openwrt-vel?
Sajnos próbálgattam a statikus routet is, de nem jött össze.ⓑⓣⓩ
-
statikus route nem elég. egyébként lartc a barátod.
én csináltam már dualwant, csak nem openwrt-n.
az a dolog lényege, hogy csinálni kell két routingtáblát, és meg kell jelölni a csomagokat, hogy melyiket melyikkel kezelje.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
btz
addikt
Üdv!
Van egy router. Két bejövő internet kapcsolat, két lan hálózat az 192.168.1.X (Erre lehet kapcsolódni wifivel és a 4 vezetékes lanport is ehhez tartozik) és az 192.168.4.X (Ez utóbbin csak wifi van).Openwrt tplink router az eszköz.
2 pppoe wan a bejövő net. Egy wan és egy dwan interfész van felvéve. Az elsőhöz tartozik a lan a másikhoz a dlan intetfész. Így néz ki a dolog.A probléma, hogy vagy az egyiken van net, vagy a másikon. Az első képen (az interfész fülön) a kapcsolódásra kattintok bármelyik pppoe interfésznél, az lesz az elsődleges ipv4 wan, amit az áttekintés fülön mutat is.
Mindig csak azon van net elérés, amelyik az áttekintés fülön ipv5 wan-ként szerepel. Mindig az kerül oda, amelyiket az interfész fülön a kapcsolódás gombbal befrissítem. Vagy ha az áttjáró metrikájához írok számokat, akkor mindig az alacsonyabb metrika számú kerül oda.A dlan wifije a VanNet sssid-n van a sima lan wifije a Tplink nevű ssid, így tudok váltogatni köztük.
A cél az lenne, hogy mindkettőn menjen a net elérés, egy whatismyip oldalon mindig azt az ip-t lássam, amelyik pppoe intetfészen keresztül netezek.
[ Szerkesztve ]
ⓑⓣⓩ
-
a lartc az egy dokumentum, egy könyv, amiben a linux kernel routing és tűzfal konfigurálását írják le.
ezt kell elolvasni, majd kitalálni, hogy ami alap linuxban megvan, abból mi és hogy jelenik meg openwrtben.[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
btz
addikt
válasz vargalex #7014 üzenetére
(#7013) bambano
Én azt hittem valami linux csomag
Majd letöltöm és áttnézem. Biztos sokat lehet belőle tanulni a routing lelkivilágáról.(#7014) vargalex
Meg is néztem az Openwrt wikiben is írták, hogy a multiwan elavult, használjuk az mwan3-at.
Loade Balance-re használtam, így már tudtam kb hova kell nyúlni.
Hamar be is állítottam a kellő szabályokat és nagyon szuperül megy!Köszönöm a segítséget mindenkinek!
ⓑⓣⓩ
-
VeryByte
őstag
Sziasztok,
Adott egymástól 15-20 méterre két épület.
Kábellel lesz összekötve, valószínűleg csatornában a földben.
Kérdés, hogy milyen kábel legyen?
UTP? Optika? (Mondjuk ehhez akkor switch-et is kellene ugye cserélni) Egyéb ötlet?
Wifi nem játszik, nem szeretem.Előre is kösz az ötleteket.
VB
"What is the most important thing in a woman?" - "The soul."
-
crok
nagyúr
válasz VeryByte #7016 üzenetére
Kizárólag üveg, ne szopassátok magatokat, senkinek sem kell egy földhurok vagy egyéb anomália. Switchet se kell cserélni csak 2 médiakonvertert kell venni (ha a switchek nem tudnak fogadni se SFP-t se GBIC-et).
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
két, egymástól 20 méterre levő épületnél a földelések között már jelentős potenciálkülönbség lehet. ez a régebbi ethernetes cuccoknál (még a koaxos időkben) akár teljesen megakadályozhatta az adatátvitelt.
a potenciálkülönbség miatt áram folyhat a kábelen, amitől korrózió is lehet.két épület esetén előfordulhat, hogy nem ugyanarról a betápról vagy fázisról mennek, ez is potenciálkülönbséget okozhat.
jobb az optika.
az optikánál csak egy dolog jobb: a mégtöbb optika. remélem, amikor behúzzák majd ezt a bizonyos kábelt, akkor nem pont annyit húznak be, mint amennyire prompt szükség van, hanem többet. utólag ki szokott derülni, hogy jó ötlet.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Magnat
veterán
válasz bambano #7020 üzenetére
Na ok, de miben különbözik attól a helyzet, ha épületen belül vannak ennél sokkal nagyobb távolságok redundáns tápolással meg csilliárd fázissal? Úgy értem, h ott már egy adott eszközön belül is a két betáp miatt simán lehet(ne) földhurok, de valszeg megoldják galvanikus leválasztással, szóval csak emiatt sztem felesleges az optika, ha meg nem az, akkor meg kb mindenhova az kellene épületen belül is ... egy switch meg a 30 méterre lévő földelt aljzatba dugott pc között pont ugyanannyi sansza van egy földhuroknak, főleg, h vmelyik eszköz a szünetmentesbe van dugva, aminek a földje a 3 épülettel arrébb lévő generátorok mellett van..
[ Szerkesztve ]
̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
-
-
E.Kaufmann
addikt
Valaki találkozott már olyannal, hogy egy közelben lévő webstick megzavart egy vezetékes hálózati kapcsolatot?
Van egy több WAN-t kezelni képes router, bedugtam egy webstick-et, amit rendben használatba is vett, ment rajta a forgalom, erre az ADSL látszólag ment tovább de érdemi adatot nem nagyon lehetett átpréselni rajta. Maga a modem és az ADSL vonal több mint 10 méterre volt, tehát vagy a router nem bírja egyszerre a pppoe-t és a mobilnetet vagy zavarta az ethernet kapcsolatot a stick, másra most nem tudok gondolni.Le az elipszilonos jével, éljen a "j" !!!
-
crok
nagyúr
válasz E.Kaufmann #7023 üzenetére
Szvsz. a router a webstick-hez írta most át a default route-ot, azért van ez a viselkedés.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
E.Kaufmann
addikt
-
crok
nagyúr
válasz E.Kaufmann #7025 üzenetére
Igen, így keletkezik az aszimmetrikus routing.. az ADSL FIX IP-t csak egyféleképp érheted el, mert arról csak egyféleképpen - az ADSL-eden keresztül - tud a külvilág. Ám a válasz ha a websticken megy ki mert a router szempontjából a def-route azon keresztül mutat ki - ami most valószínűleg meg is van terhelve - lesz válasz meg lassú is lesz.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
-
crok
nagyúr
válasz E.Kaufmann #7028 üzenetére
Miért lenne a forráscím más? A forráscím jó, a route, ahol kimegy.. az nem jó.. (ha lenne uRPF a szolgáltatónál akkor totál eldobná még azt is.. de ezek szerint nincs).
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
crok
nagyúr
válasz E.Kaufmann #7030 üzenetére
Csak akkor ha a maszkolásban a forráscímek közt szerepel az ADSL fix IP mint forráscím - de mivel forrás csak a LAN-od lesz és egyetlen WAN-od sem lesz benne mint forrás cím így nem lesz NAT-olva, tehát azzal a source-al megy ki ami ugyan korrekt, csak rossz interface-en.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
válasz E.Kaufmann #7028 üzenetére
de ne keverd a vpn-be csomagolt ip csomag forráscímét a vpn szerverből jövő csomag forráscímével
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"tehát azzal a source-al megy ki ami ugyan korrekt, csak rossz interface-en.": nem mindig azzal a source-szal megy ki, ami az adott interfészé, mert annak a csomagnak a vpn a forrása, ezért azt az ip címet kapja, amelyiken kimegy.
ettől független, hogy a vpnbe, mint adatkapcsolatba, egy belső hálózati ip csomag van belecsomagolva
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
E.Kaufmann
addikt
Ok, hogy a LAN-t pingelem, de a VPN (SSTP, TCP alapon) csatornának a kliensét futtató csomópontnak ennyire tökmindegy, honnan jön a csomag? Vagy arra gondoltok, hogy állandóan hol ide-hol oda kapcsolódik? Úgy gondoltam, ha már a LAN-t tudom vacak késleltetéssel pingelni, akkor a csatornát alkotó csomagok is jó irányból jönnek, csak rohadt lassan.
[ Szerkesztve ]
Le az elipszilonos jével, éljen a "j" !!!
-
crok
nagyúr
válasz bambano #7033 üzenetére
Nem, mert azt írja hogy az ADSL fix IP-re csatlakozik valami VPN-el. A NAT nem is játszik. A forráscím pedig a leírás szerint csak az ADSL fix IP lehet, mert arra jött be - itt természetesen csak feltételezem hogy a router a VPN-t termináló eszköz és ténylegesen az ADSL fix IP-t használja a session felépítésére és fenntartására mert az is egy processz és ha változna a kimenő interface és azáltal a forrás cím akkor az már más SPI lenne, más session és természetesen leszakadna (pontosabban nem menne az eredeti session) de itt erről nincs szó, csak arról hogy ha a timeout-ot megemeli akkor jön a pingre válasz - szvsz mert a webstick-en megy a válasz de az ADSL-en jön a kérés.. tökmindegy hogy most az VPN. Alapvetően igaz, hogy a legtöbb router a kimenő interface IP-jét használja mint source ha pl. NAT-ol (természetesen) de a VPN innentől kezdve más más káposzta, ott valahogy session-t kell csinálni, új SSTP session kell csinálni.. ott nincs lehetőség hogy megváltozik a source IP csak úgy pacsira, azt nem engedheti meg a processz csak tervezetten (failover situation) - de, mint írtam a ping megy ha a timeout nagyobb. Egy tracepath esetleg segíthet ping helyett de én inkább annak a routernek a routing tábláját nézném meg, de alaposan.
"mindig azzal a source-szal megy ki, ami az adott interfészé, mert annak a csomagnak a vpn a forrása, ezért azt az ip címet kapja, amelyiken kimegy" - nem. Ez igaz ha a routeren átmenő forgalomról beszélsz, de itt ha az SSTP-t a router terminálja akkor az már nem átmenő hanem feldolgozott forgalom. (Lentebb leírom miért lesz más a source).
"ettől független, hogy a vpnbe, mint adatkapcsolatba, egy belső hálózati ip csomag van belecsomagolva" - ha a VPN-ben megy akkor az a forrás ami a session-ben be van állítva. Ha más az exit interface akkor más, az SSTP session attól még SSTP session, TCP, van neki forrása, célja, ami nem változik meg attól hogy más interface-en megy ki a csomag. Ennek megakadályozására jó az ISP oldalon az uRPF (mert ez így spoof-olt csomagforgalom amúgy).
Egyébként meg Wireshark a megfelelő helyen megmondja ki merre van arccal ( :
Meg egy ábra jól jönne ha nagyon bele akarunk menni, ajánlom a draw.io-t ha nem használtátok még esetleg, bal oldalon More shapes és Cisco majd szép routereket/switcheket/bármit be lehet tenni. Gyors és ingyé' van (és nem mellesleg 100% használhatóbb mint az M$ Visio valaha lesz IMHO).Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
crok
nagyúr
válasz E.Kaufmann #7034 üzenetére
"direktbe az ADSL fix IP címére csatlakozott egy eszköz VPN-en és próbáltam ping-gelni, nem működött, amint megemeltem a várakozási időt, már át-át csúsztak a válaszcsomagok 1000 ms feletti válaszidővel."
Vagyis te az ADSL fix IP-t használod a routeren az SSTP terminálására? A router terminálja az SSTP kapcsolatod? Vagy a LAN-ban van valami amire portforward van beállítva? Mert eddig a leírásod alapján az ADSL fix IP-t használod az SSTP terminálására és a router az SSTP vége.
Egyáltalán nem mindegy hogy melyik forrás címet használod és hacsak a routerben levő processz nem tudja mindkettőt használni, de ahhoz két SSTP kapcsolat is fel kell hogy felépítve legyen. Ilyen failover a világban nincs hogy két IP és egy SSTP..
De ahogy írtam, ha az SSTP-t a LAN-ban levő eszköz terminálja akkor már máshogy működik a dolog.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
E.Kaufmann
addikt
Nagyon belegabalyodtatok. Router mögött SSTP szerver, a kliens meg mindegy hogy hol.
A router meg úgy is átírja a szerver címét a WAN végberendezéseken kapott címekre. Ha máshová irányítja a kimenő forgalmat, mint a bejövőt, akkor a kliens máshonnan kap SSTP csomagokat, mint amerre kiépítette a forgalmat, azokat meg illene figyelmen kívül hagynia. Tehát mikor a tunelen belül jönnek a kliens felé a csomagok, mivel az alagutat felépítő csomagok máshonnan jönnének, eleve el lesz dobva mind a VPN forgalmat alkotó csomag, mind a tartalma. De itt meg jöttek a csomagok, csak k...... lassan, tehát azt gyanítottam, vagy nem bír egy pppoe és egy másik ppp kapcsolatot mobilneten át, vagy az a webstick buzerálja az UTP kábelen folyó forgalmat.Tehát akkor. Senki nem tapasztalt olyat, hogy az ethernetet mobiltelefon vagy webstick b....ná?
Ha nem, akkor pont.Le az elipszilonos jével, éljen a "j" !!!
-
crok
nagyúr
válasz E.Kaufmann #7037 üzenetére
De, tapasztaltam, leírtam hogy miért és nem, nem volt tiszta a helyzet mert azt nem mondtad, hogy az SSTP szerver nem a router hanem egy eszköz mögötte.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
crok
nagyúr
Ja igen, mégvalami: mivel az ADSL alatt az SSTP már élő kapcsolat volt és nyilván már volt rá NAT bejegyzés így nem keletkezik új attól függetlenül mert más lesz az exit interface a forwarding szerint (hiszen egy TCP kapcsolatról beszélünk a router szempontjából, az egyik lába a LAN-ba mutat a másik meg "kifelé", már van élő NAT bejegyzés erre a session-re). Ez így van Cisco-ban, Juniperben, iptables-ben Linux alatt mindenben. Így aztán tulképp nem változik semmi csak a webstick bedugásakor lesz egy új, működő kapcsolat és a def-route megváltozik - de minden marad a régiben. Mivel a webstick szolgáltatója nem használ uRPF-et így a tulajdonképp spoof-olt csomag nem dobódik el, ellenben mivel a (valszeg) a webstick sávszélje kisebb mint az ADSL így ott keletkezik majd egy nagyobbacska késleletés - amit érzékelsz is.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
-
crok
nagyúr
válasz E.Kaufmann #7040 üzenetére
Nem az okosság hanem az order of operation számít:
logikusan hamarabb van a NAT mint a routing/forwarding.Képzelt el hogy kondícionális a NAT-olásod, nem csak egy
sima masq - mondjuk a source-ot is cserélni akarod meg a
destination-t is, mert olyan a setup.. akkor nyilván mivel
a destination-t is átírtad és a routing tábládban sem csak
egyetlen def-route lehet így a NAT hamarabb *kell* legyen
mint a routing/forwarding decision. Ennyi.Ha törlöd a NAT bejegyzést vagy lemegy a pppoe akkor
már a másikat fogja használni - mert csak azt tudja és
mert mivel már nem valid a pppoe interface így már nem
is használható az az interface - okafogyottá válik a NAT
bejegyzés és felszabadul, aztán jön a LAN-ból a csomag
majd NAT-olódik és route-olódik is ki a webstick-en.Ha most pl. a webstick be van dugva és kihúzod majd
vissza is dugod az ADSL-t akkor megint minden fain lesz.Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
-
válasz E.Kaufmann #7040 üzenetére
az iptables azt csinálja, amire utasítod. tehát elég okos, nem okoskodik helyetted
ha natolás olyan lesz, amilyenre állítod. ha megmondod, hogy mire natoljon, akkor arra natol, ha meg azt mondod neki, hogy kimenő interfészre natoljon, akkor arra natol.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
VeryByte
őstag
Sziasztok,
Két épület összekötése most már biztos, hogy optikával lesz megoldva.
Kérdéseim:
- mono vagy multi optikai kábel szülséges ehhez, illetve hol lehet ennek kicsit utána nézni (ezt a kérdést nekem szegezték, nem is értettem, bevaééom őszintén)
- milyen átalakító szükséges optika és UTP összekötéséhez?Nem vagyok benne ebben az optika témában, gondolom ez látszik.
Tudom, lehetne Google-zni, de hátha van valakinek pontosabb és célravezetőbb információja vagy információ forrása, mint a nagy testvérnek.
Előre is köszi!
G."What is the most important thing in a woman?" - "The soul."
-
válasz VeryByte #7046 üzenetére
én monomódusút rakatnék bele, az jobban fejleszthetőnek tűnik...
optikát utp-vel vagy médiakonverterrelrel kötsz össze, vagy olyan switcheid vannak (lesznek), amikben van sfp aljzat és akkor sfp modult kell venned.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
crok
nagyúr
válasz VeryByte #7046 üzenetére
Gyors súgó:
https://mega.nz/#F!cx5CxJqL!YmrmiTkCKH0ZxjbdenPZlA!xkgxgTBA
Books > misc > networking-forum
gbic.pdf
mediadistances.pdf
physical_terminations.pdf
Valamint:
http://lostintransit.se/2010/08/05/quick-facts-about-fibre-standards/Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
togvau
senior tag
Ha egy modemrouterben kikapcsolom az ipv6 dhcp-t, akkor az azt jelenti, hogy azután csak SLAAC-al szerez ipv6 címet minden rá csatlakozó eszköz?
[ Szerkesztve ]
hitler, sztálin, micro usb
Új hozzászólás Aktív témák
- Yettel topik
- Milyen légkondit a lakásba?
- Budapest és környéke adok-veszek-beszélgetek
- AMD GPU-k jövője - amit tudni vélünk
- Elektromos autók - motorok
- Nyár közepén jön az AOC 540 Hz-es gaming monitora
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Assetto Corsa Competizione
- Olcsóbb lett a Tesla Full Self-Driving szoftvere
- A TikTokon marakodik Trump és Biden, betilthatja az USA
- További aktív témák...