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 ]

Kezdetnek a szolgáltatói eszköz bridged módba és egy saját router használata nem lenne rossz.

Egy dolog állandó: a változás - Internet powered by Vodafone Internet 150 with CBN CH7465VF & Asus RT-AC65P

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.

ⓑⓣⓩ

Mi a cél pontosan?

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

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

Egyszer csináltam ilyet, ráadásul mobil stick-ekkel. MultiWAN a te barátod szerintem.

"What is the most important thing in a woman?" - "The soul."

Ü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 tűzfal beállítások hozzá.

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 ]

ⓑⓣⓩ

Üdv! Utánanézek, hogy mit tud ez a lartc, gondolom csak szerverrel használható, nincs openwrt-hez használható vetziója.

ⓑⓣⓩ

Szia!

Szerintem ez Multiwan-al megoldható, hiszen ott akár forrás cím alapján is megmondhatod, hogy melyik interface-on menjen kifelé.
Szerk.: most látom, hogy megelőztek.

[ Szerkesztve ]

Alex

Üdv!
Nem összehozni akarom a két kapcsolatot, hanem két külön lan hálózatnak adni őket. Sajnos csak 1 routerem van a dologra, ezért kéne valami olyan beállítás, amivel mindkét lan a saját pppoe wanját használná.

ⓑⓣⓩ

Üdv!
Az jó, akkor lehet mégiscsak ez kell nekem. Megnézem.

ⓑⓣⓩ

Nem találom a multiwan csomagot, csak mwan3-at, az is jó lehet ehhez?

ⓑⓣⓩ

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

Ha trunk-ot (vagy LEDE-t használsz), akkor valóban nincs multiwan. Az mwan3 is jó.

Alex

(#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!

ⓑⓣⓩ

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."

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).

Kösz, én is ilyesmiben gondolkodtam.

"What is the most important thing in a woman?" - "The soul."

Konkrétan mitől tud kialakulni a földhurok vagy az egyéb anomália, azért mert a kábel a földben van vagy mert két külön épületben van a kábel két vége?

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

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

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 ]

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

"miben különbözik attól a helyzet, ha épületen belül": semmiben, épületen belül is vagy egy betápról megy az egész, vagy érdemesebb optikát húzni.

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

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" !!!

Szvsz. a router a webstick-hez írta most át a default route-ot, azért van ez a viselkedés.

Nem, mert 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.

Le az elipszilonos jével, éljen a "j" !!!

De akkor a VPN túloldal nem dobná el a más forráscímről érkező csomagot? Itt meg megjött, csak lassan. Amúgy meg miért az offtopic jelölés?

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

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).

Ez egy 2 WAN portos +USB router, ami alapból maszkol. Tehát ha másfelé megy ki, más lesz a forrás IP címe is.

Le az elipszilonos jével, éljen a "j" !!!

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.

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

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" !!!

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).

"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.

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" !!!

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.

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.

Azt hittem, ennél okosabb az IPTables, és nem számít, hogy élő-e a kapcsolat, hanem ha rosz irányba megy a csomag, akkor annak az interfésznek a külső címét kapja mindenképpen, mikor kilép a NAT túloldalára.

Le az elipszilonos jével, éljen a "j" !!!

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.

"logikusan hamarabb van a NAT mint a routing/forwarding.": ezért rakod a postrouting táblába a masquerade-t? nem, előbb van a routing döntés, mint a snat. a dnat van a routing előtt.

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

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

Ez true!

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."

é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

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/

@crok és @bambano,

Köszi a válaszokat!

vb

"What is the most important thing in a woman?" - "The soul."

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