Új hozzászólás Aktív témák
-
Essejó
veterán
-
#71841
Goblin12
őstag
juhaszmarci
#71840
Goblin12
őstag
válasz
juhaszmarci
#71840
üzenetére
Osztrák, itt a leírás: [Magenta "Home Box Fiber"]
A régi fajtával lehetett, de ez már nem igényelhető: [Magenta "Internet Fiber Box"] itt külön volt DMZ és Bridge mód is, az újban már egyik sincs.Elméletileg valami Technicolor ami igazából tudja a beállítást, de nem elérhető.
default gateway IP-re csak tölt tölt és semmi. 
-
#71839
Goblin12
őstag
juhaszmarci
#71838
Goblin12
őstag
válasz
juhaszmarci
#71838
üzenetére
Oh köszi az infót, akkor nem kihagyható, pedig elhittem.
Ezeket az ISP-ket nem lehet már konfigurálni, nincs webes overlay, kapsz egy telós appot amiben a WLAN PW-t tudod állítani és esetleg még MAC-hez tudsz DHCP IP-t hozzá rendelni és ennyi, nincs már olyan, hogy bridgemode-ba rakom az ISP-t. Sajnos.
-
#71838
juhaszmarci
csendes tag
Goblin12
#71837
juhaszmarci
csendes tag
válasz
Goblin12
#71837
üzenetére
Kell a cuccokhoz egy management eszköz, ami az én hozzászólásomban az UDM-Pro Max volt, rekop tervében a Cloud Gateway Fiber (nálam sima Pro van itthon). Amellett, hogy mindkét eszköz router is.
Ezek nélkül minden "standalone" vagy "buta" módra áll be, azzal nem leszel előrébb.
Minden szolgáltatói eszközt "ki lehet iktatni" a hálózatból, DMZ vagy bridge/modem mód. Így nem lesz dupla NAT -
Goblin12
őstag
Hali.
Gondolkodtam sokat ezen a setupon és felmerült az a kérdés, hogy vajon szükségem van-e a Gateway-re ha az internet Coax kábelen jön be egy ISP -be, ha kihagyom a Gateway-t akkor kihagyom a duplna natolást.
Elég lenne talán csak a Switch meg a kettő U7 vagy 1 E7.
Vagy rosszúl látom? -
Akkor nálad ez bevált? Vagy nem neked kellett?
Igen, igazad volt hogy titkosítatlan aktív FTP esetén belelát a router és megoldja magától. Titkosítottnál meg nem lát bele. A fenti kép (triggering) a tippem a megoldásra. (de ismétlem: nem próbáltam, akinek kell próbálja ki) -
válasz
Borisz76
#71833
üzenetére
A házat egy hosszú nyél köti össze az utcával, és az utcai kapun van egy IP-s kaputelefon. A kiépítésnél viszont tartalékolási alapon eleve két UTP-kábelt húztam ki (amelyet az ügyes villanyosok a 230-as fővezetékkel közös csőben vezettek), és így adta magát, hogy kipróbáljam, hogy mi történik, ha a két vezetéket a kapunál összetoldva az oda-vissza távolságon is kipróbálom, hogy működik-e a dolog. Működik, bár a gigabit már nem volt meg.
Érdekesség egyébként, hogy a jelenlegi, kb. 140 méteres (vagy a házban kanyargó szakasz miatt kicsit nagyobb) hosszon a PoE is hibátlanul táplálja a kaputelefont.
MaCS
-
válasz
Borisz76
#71830
üzenetére
"Az utp kábel hossza 100 méter lehet elviekben.
Ha ettől nagyobb távot kellene áthidalni , akkor egy AKTÍV eszközt ( árammal működő berendezést ) kell közbeiktatni. Egy routert vagy switch-et."Tényleg csak elviekben. Nálam jelenleg kb. 140 méteren, villanyvezeték mentén vezetve remekül megvan a gigabyte/s. Sőt, ennek a dupláján is volt stabil kapcsolat.
MaCS
-
Borisz76
nagyúr
válasz
tibee77
#71828
üzenetére
Nem lehet gond a késleltetés.
Az utp kábel hossza 100 méter lehet elviekben.
Ha ettől nagyobb távot kellene áthidalni , akkor egy AKTÍV eszközt ( árammal működő berendezést ) kell közbeiktatni. Egy routert vagy switch-et.Ha a gépen megnézed a LAN csatlakozásnál a kapcsolati sebességet és 10/100/1000-es ...azaz Gigabites, akkor jó a kábel !
Természetesen ez csak akkor igaz, ha a kábel mindkét végén Gigabites csatlakozás van ! Ha mondjuk a PC.ben csak Fast Ethernet kártya van , vagy a router-ben ....akkor 10/100-t fogsz látni. De manapság már szinte mindenben Gigabites LAN van.
Egyedüli kivétel ez alól a TV-k !
Azokban a mai napig csak Fast Ethernet van.....sajnos. -
tibee77
őstag
Szevasztok.
Szobaban egyik helyröl a masikra atköltöztetve a gepet kellett kb. vennem egy 20 meteres utp kabelt, hogy legyen internet.Probaltam itt visszakeresgelni a kommentek között, hogy vajon 20m-en mennyi a jelveszteseg de nem nagyon talaltam semmit.A lenyeg, hogy a latencym online jatekokban elegge rossz lett, folyamat 200-300 ms ami kb jatszhatatlan kategoria.(meg nem tudom hogy a jatek hibaja-e, mert egy jatekot probaltam csak, lehet a szerok szarakodnak).A letöltesi sebessegem kb. ugyanaz maradt, ott nincs nagy gondom.Szoval a kerdes, hogy vajon a tul hosszu kabel miatt lehet ez a gond?Nagyon megtörve nincs a kabel sehol se (elegge gagyin oldottam meg sajnos, falon megy a szobaban körbe-körbe a kabel, szoval az se lehet, hogy megserült.(vagyis legalabbis en ugy gondolom)Elöre is köszi a segitseget.
Le tudom valahogy mashogy is ellenörizni, hogy a kabellel lehet-e a gond?vmi progi vagy kell hozza egy konkret eszköz? speedtest.net-en se a sebesseggel se a latency-vel nincs gond (17ms-t ir) -
#71827
MasterMark
titán
Doky586
#71826
-
#71826
Doky586
félisten
MasterMark
#71824
válasz
MasterMark
#71824
üzenetére
"egyszerűen azt a portot minden cél IPv6 címre beengeded a tűzfalon"
Nem lehet tcp forgalmat broadcastolni. Egy nagy sebességű bejövő forgalomnál ez amúgy is hazavágná az egész lant. -
#71825
Doky586
félisten
MasterMark
#71824
válasz
MasterMark
#71824
üzenetére
Nem azt mondtam hogy le lesz. Csak azt hogy képzeld el. Így jobban nyilvánvaló a terheléseloszlás. 4-6 közt.
-
#71824
MasterMark
titán
Doky586
#71823
MasterMark
titán
válasz
Doky586
#71823
üzenetére
Az IPv4 nem lesz lekapcsolva ettől nem kell félj.
Azt el tudom képzelni, hogy esetleg lesz valami UPnP-hez hasonló dolog, ami tudja jelezni a tűzfalnak, hogy melyik portot engedje át neki.
Nem kell kikapcsolni az egészet amúgy. #71822-ben írtam, hogy elég csak az adott portot átengedi de bármilyen IPv6 címre. A végpontok tűzfala úgyis eldobja ha nem neki szól, ahol a torrent van ott meg beengedi, és akkor egyszerűen megoldottad a dolgot.
-
#71823
Doky586
félisten
MasterMark
#71822
válasz
MasterMark
#71822
üzenetére
Gondolj bele: Tételezzük fel hogy már nincs IPv4 (lekapcsolták mint a 3G-t)
Az emberek 99,99%-a otthon torrentezik IP6 miatt passzív módban. Nem cégnél.
Nem tudnak letölteni, nem tudnak feltölteni. Csak azon 0.01% emberhez akik ezt (#71816) beállították, vagy az egész tűzfalat úgy ahogy van kikapcsolták. -
#71822
MasterMark
titán
Doky586
#71820
MasterMark
titán
válasz
Doky586
#71820
üzenetére
Passzív módban is működik a torrent, akiknek van rendes szervere fix címmel, meg nyitott porttal azokhoz tudsz kapcsolódni.
Ilyen nem lesz "'beprogramozva", mivel nem így működik.
De pontosan mit is szeretnél elérni amúgy? Ha csak tanulni szeretnél akkor abban tudunk segíteni, itt több megoldást is leírtam miket lehet csinálni.
szerk.: Még egy megoldás eszembejutott, egyszerűen azt a portot minden cél IPv6 címre beengeded a tűzfalon, és az OS tűzfalára bízod hogy megszűrje. Ez talán a legegyszerűbb.
-
Na ha ez ennyire bonyolult akkor nem hiszem hogy sok százezer magyar torrentező fogja megcsinálni. (vagy milliónyian világszerte) Mindenki marad IPv4-en és hiába látszanak IPv6 peerek is azokon keresztül senki semmit nem fog fel/le tölteni. IPv4-en legalább lehet egyszerűen portforwardot beállítani, igaz a tendencia az hogy egyre több a CG-NAT amit kuncsologva ki lehet -még- kapcsoltatni, de ki tudja mi lesz 10-20 év múlva.
Talán addigra beleprogramoznak a home wifi routerekbe egy torrent kompatibilis IPv6 tűzfalat.
-
#71819
mrots
junior tag
MasterMark
#71818
mrots
junior tag
válasz
MasterMark
#71818
üzenetére
Nekem fogalmam sincs mit csinal, de elengedtem es sok sikert kivanok neki.
-
#71817
mrots
junior tag
MasterMark
#71816
mrots
junior tag
válasz
MasterMark
#71816
üzenetére
"a tűzfalba pedig DNS-el adod meg, de abban nem vagyok biztos, hogy ilyet lehet."
Lehet, de a tuzfal szabalyokba mindig IP cim kerul, fuggetlenul attol, hogy az end user nevet rakott oda. Ket implementacio van.1) az iptables lefutasakor csinalnak egy nevfeloldast es amire eppen feloldodik, az kerul be - ezt lehet cronba is tenni, bar ez vagy megszakithat session-oket, vagy beengedhet nem vart forgalmat a futas idejetol, mivel egy tuzfal script altalaban azzal kezdi a dolgokat, hogy kiuriti a tablakat es feltolti a szabalyokkal nullarol. a default action donti el, melyik nem vart mukodes tapasztalhato
2) a tuzfal magatol, periodikusan frissit. az, hogy mennyi, az gyarto fuggo. A palo alto tuzfalaknal peldaul a 9.0 szoftver ota figyeli a TTL mezot a DNSben a tuzfal es ehhez igazitja a frissites idoziteset. Vannak egyeb korlatok is, 30 vagy 60 (elfelejtettem melyik) masodpercnel gyakrabban akkor sem frissit, ha a TTL ennel kisebb. Van termeszetesen egy custom ertek amit be lehet allitani, a TTL es e kozul a kisebbet fogja venni, de legalabb a minimumot. Ez csak egy pelda, mas gyartok maskepp csinaljak."Sajnálatos dolog, hogy az ISP cserélgeti az IPv6 prefixet"
Azert a dolog nem megoldhatatlan. Barmikor regisztralhat az ember sajat v6 subnetet, akar /48 -at is kap, ha ker, kulso szolgaltatotol, GRE-n keresztul. Ez a prefix sosem fog valtozni, hordozhatja magaval az ember. Ha ez nem jo, akkor lehet olyan torrent klienst hasznalni, ami nem dual stack es egyszeruen nem ismeri a v6-ot, akkor ugye nyilvan nem erdekes, hogy valtoznak a cimek. Illetve lehet a hoston magan tuzfalat is futtatni, olyat, amely processzek alapjan tud korlatozni. Barmikor lehet kompletten tiltani a v6 forgalmat a torrent processznek, ami ezek utan fallback-elni fog v4-re. Es ezen tulmenoen lehet v4 only proxyt futtatni a localhoston, a torrent kliensnek pedig megadni, hogy ezen a proxy-n keresztul kapcsolodik az internetre - itt megint csak nem fog mukodni a torrent szamara a v6, de megsem kell teljesen kikapcsolni a v6-ot.Egyik sem tokeletes, de opciok azert vannak.
-
#71816
MasterMark
titán
Doky586
#71815
MasterMark
titán
válasz
Doky586
#71815
üzenetére
De nem tartozik oda. Egy szervernél a fix host id az elvárt. Ha ez egy desktop gép, akkor kerülőút kell, vagyis a torrentet bindeld rá a fix IPv6 címre. De ha a prefix változik, az is változni fog, ehhez meg a windowsban kell megadni, hogy amiből generálja a címet az perzisztens maradjon.
Másik kerülőút, hogy az összes IPv6 Global címedet egy script mindig befrissíti a tűzfalba.
Esetleg még egy olyat lehet, hogy dinamikus DNS-el, mindig frissíted az aktuális IP-det, a tűzfalba pedig DNS-el adod meg, de abban nem vagyok biztos, hogy ilyet lehet.
Ha nem lehet, akkor pedig a routerre kell egy cron job ami mondjuk 10 percenként ellenőrzi, hogy a DNS amire felold cím az van-e a tűzfalban, és ha nem akkor cseréli.NAT-olást elengedném, bár ha jól rémlik van itt más, aki ezt így oldja meg, de ezzel az IPv6 lényegét veszed el, hogy nem kell NAT, mert a végpontok címezhetők.
Sajnálatos dolog, hogy az ISP cserélgeti az IPv6 prefixet, mivel nem kéne neki az RFC ajánlások szerint, de mégis így csinálják. Ezzel direkt nehezítik az ilyen konfigokat, mert körbe kell írnod ezt, hogy folyton változik az IP.
-
#71815
Doky586
félisten
MasterMark
#71814
válasz
MasterMark
#71814
üzenetére
"A temporary címek arra vannak, hogy ne tudjanak követni a weboldalak a címed alapján"
Ezt nem én írtam de a funkcióját meg akarom tartani. a router nem tudná át NAT-olni? Nem tudja a router hogy a két cím ugyanazon gép ugyanazon programjához tartozik?
-
#71814
MasterMark
titán
Doky586
#71813
MasterMark
titán
válasz
Doky586
#71813
üzenetére
Ezért mondtam, hogy bindeld rá a másikat... Ezt neked kell megoldani jól. A windows alapból a temporaryt fogja csak odaadni a programoknak, ha te kifejezetten nem mondod neki, hogy ne ezt csinálja.
Tesztelni lehet, csak azt teszteld amit csinálsz.
Temporaryból egy idő után több is lesz, és össze-vissza használják a programok random.
-
#71813
Doky586
félisten
MasterMark
#71812
válasz
MasterMark
#71812
üzenetére
Torrenten meg más helyen se tud senki a fix d075 címemről, csakis a temp 27de-ről..! Felesleges foglalkozni/tesztelni.
-
#71812
MasterMark
titán
Doky586
#71811
MasterMark
titán
válasz
Doky586
#71811
üzenetére
De hogy ellenőrzöd, hogy nyitva van-e a port? IPv6-on a böngésző mindenképp az egyik temporary IP-t fogja használni, nem azt amire te nyitottad. Vagy megadod kézzel?
szerk.: De mutatja is a képeden, hogy a 27de végű IP-t ellenőrzi. Akkor így mit vársz a másik IP-nél?
A 27de-re persze hogy nincs beengedve ha a d075-re engedted be. Akkor a 27de végűre nyilván azt írja, hogy closed.
Nem a beengedés nem működik, hanem rossz IP-t nézel.Amúgy mondtam már, hogy úgy tudod tesztelni a nyitott portot, ha mobilnetről vagy más netről betelnetelsz az adott portra. Ha üres képet kapsz akkor nyitva van, ha timeout, akkor zárva.
-
#71811
Doky586
félisten
MasterMark
#71810
válasz
MasterMark
#71810
üzenetére
Ha ezt a szabályt írom a routerbe
ip6tables -I FORWARD -p tcp -d 2001:4c4e:1941:xxxx:xxxx:xxxx:xxxx:d075 --dport 12345 -j ACCEPT akkor ez az erdmény: [kép] azaz nem működik a beengedés. (fix ip6)Ha viszont ezt:
ip6tables -I FORWARD -p tcp -d 2001:4c4e:1941:xxxx:xxxx:xxxx:xxxx:27de --dport 12345 -j ACCEPT akkor ez az eredmény: [kép] azaz minden rendben, működik. (ideiglenes ip6)A routerbe egyszerre csak az egyik van. visszaellenőriztem. wildcardokkal majd ezután foglalkozok ha ez megoldódik, ne bonyolítsuk két problámával egyszerre.
-
#71809
Doky586
félisten
MasterMark
#71808
-
#71808
MasterMark
titán
Doky586
#71805
MasterMark
titán
válasz
Doky586
#71805
üzenetére
Úgy látom nem érted amit írtam.
Ezért írtam, hogy a végét fixálni kell, ezért írtam, hogy a torrent program a stabil IP-re bindeljen, ne a temporaryra, stb.
Ha nem látod át mit csinálsz, úgy nehéz lesz.Szóval, előszőr kell egy fix host id-s IP cím, az a képeden az első, ami nem temporary. A torrent kliensnek erre az IP-re kell bindelnie, nem másikra, ezt a beállításaiban meg tudod adni. (Vagy az összes címre bindeljen, az is jó.)
Ezt a címet kell aztán wildcardozva felvenni a tűzfalban. -
#71806
Reggie0
félisten
MasterMark
#71790
Reggie0
félisten
válasz
MasterMark
#71790
üzenetére
A portforward sosem volt NAT. A portszam, ha egyaltalan van, az a transzport reteghez tartozik, nem a network reteghez, amit a NAT modosit.
-
#71805
Doky586
félisten
MasterMark
#71804
válasz
MasterMark
#71804
üzenetére
Sajnos mégsem vált be.
Ma amikor bekapcsoltam a gépet mindkét sorban az első 3 számjegycsoport kivételével minden szám megváltozott. (valószínű egy pillanatnyi áramszünet is volt reggel)
Ha nem a "Temporary IPv6 Address"-t írom be hanem a simát akkor nem működik a forward (külső webes port scannerrel tesztelve).
"Nem az egész címnek kell fixnek lennie, csak a végének"
mindig a cím vége változik, nem a 2001..! -
#71804
MasterMark
titán
Doky586
#71803
MasterMark
titán
válasz
Doky586
#71803
üzenetére
Az 1bfc végű IP-t tedd be szabályba, az elvileg nem fog változni. A torrent pedig erre az IP-re bindeljen.
Nem az egész címnek kell fixnek lennie, csak a végének. (Host azonosító, az IPv6 cím utolsó 64 bit-je.) A prefixet meg cserélgeti az ISP. (Network azonosító, első 64 bit.)
A temporary címek arra vannak, hogy ne tudjanak követni a weboldalak a címed alapján. Azt pár óránként vagy naponta cserélgeti a windows. (RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6)
-
#71803
Doky586
félisten
MasterMark
#71802
válasz
MasterMark
#71802
üzenetére
Köszönöm így tökéletes lett. A következő napok IP6 változásainál még figyelem mi történik. Ez egy Telekom otthoni vdsl internet előfizetés. Természetesen nem fix a cím és a gép is naponta ki/be van kapcsolva egy régi tplink router mögött. [kép]
-
#71802
MasterMark
titán
Doky586
#71801
MasterMark
titán
válasz
Doky586
#71801
üzenetére
Pedig így kell, akkor valamit elrontasz:
Példa:
last64=::ffff:ffff:ffff:ffffip6tables -A FORWARD -p tcp -d ::216:3eff:fea3:c06a/$last64 --dport 80 -j ACCEPTA te címeddel:
::e518:1b32:ebca:36e5/::ffff:ffff:ffff:ffff
De ez ránézésre nem fix cím, a fentinél FF:FE középen látszik hogy egy mac címből generált fix EUI-64 cím.Egyébként a többi se konvertálódik át, hanem amikor lekérdezed akkor feloldja DNS névre a megjelenítéshez. Gondolom van rá kapcsoló, hogy ezt ne csinálja.
-
#71801
Doky586
félisten
MasterMark
#71790
válasz
MasterMark
#71790
üzenetére
Sajnos wildcardozva nem akar működni. A parancs sikeresen lefut de a port zárva marad. Ahogy mutattam átkonvertálódik valami dns névvé (wildcardok helyén 0 vagy f) és ennyi.
-
válasz
tototos
#71799
üzenetére
Semmi haszna nincs (maga az érpár sodrottsága megfelelő zavarvédelmet biztosít), hacsak nincs valami komolyabb áramerősségű vezeték nagyon közel hozzá.
Gondot viszont ki valószínűséggel ugyan, de okozhat, ha nincs megfelelően leföldelve az árnyékolás egyik vége.
Szóval extrém esetek kivételével határozottan ellenjavallott az árnyékolás alkalmazása.
MaCS
-
válasz
Borisz76
#71793
üzenetére
Nálam kb. 15 évig volt kilógatva két épület között, közvetlen napfénynek és csapadéknak kitéve a legolcsóbb, beltéri praktikeres UTP-kábel. A végén a felülete ugyan nem volt szép, már krétásodott, de nem repedezett. Sima Cat5 volt, de kb. 70 méteres hosszon hozta a bruttó gigabitet.
Ettől függetlenül én sem ajánlanám a beltéri kábel használatát kültéren. Kültérit vennék, sőt, feszítőhuzalost, és akkor nem kell másik huzallal és a függesztéssel szórakozni.
A föld alatti vezetéshez viszont nagyon ajánlott a védőcső -- én KPE-t használok --, és a jelölő szalag használata.
MaCS
-
Borisz76
nagyúr
válasz
tototos
#71794
üzenetére
A két épület között kifeszítesz egy drótkötelet.
Normál esetben a kötélhez rögzítik a kábelt...
De rögzíthetsz rá csövezést is...amiben a kábel fut.Vagy ha megoldható, akkor 2 ásónyom mélységben viszed a csövezést , benne a kábellel. Azért 2 ásónyom ...mert esetleg később az asszony virágot ültet és nem tudja, hogy ott kábel fut....akkor is legyen 1 asónyomnyi "biztonsági" mélység.
Hirtelen ezek jutottak az eszembe...de lehet másnak is lesz majd még ötlete.
-
Borisz76
nagyúr
válasz
tototos
#71792
üzenetére
Nem hiszem , hogy olcsóbb de hosszútávon talán jobb mintha 4-5 évente új kábelezés kellene.
Ez attól függ , hogy mennyi kábelt kell húznod és ebből mennyi van kitéve napsugárzásnak.De szabad ég alatt vagy UV álló kábelezés kell vagy csőben vinni a nem uv álló kábelt.
Tehát vagy vagy....de , hogy melyik az olcsóbb azt nem tudom.
Nálam nincs kábel a szabadban.
Minden utp kábelem az aljatbetonban fut Symolen csőben.
Egyedül a teraszra fut nálam koax kábel de az is a tetőszerkezet alatt , közvetlen napfénytől védett helyen. -
#71791
Doky586
félisten
MasterMark
#71790
válasz
MasterMark
#71790
üzenetére
Nem én nevezem forward-nak hanem az ip6tables.
Köszi kipróbálom. -
Új kérdés.
Ti hogy oldjátok meg IPv6-on routeren a portforwardot (tűzfal port beengedést)? Pl torrenthez.
Fel lehet venni egy ilyet:
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT udp anywhere 20014C4E1941E100BC95D0DDCAE2E047.dsl.pool.telekom.hu udp dpt:12345
ACCEPT tcp anywhere 20014C4E1941E100BC95D0DDCAE2E047.dsl.pool.telekom.hu tcp dpt:12345
De itt csak a PC "Temporary IPv6 Address" írható be, ami sűrűn változik.
DHCP reservation-al pont a követhetetlenséget veszteném el. Ezért nem jó.
Marad az hogy naponta ipconfig /all copy paste
ip6tables -L --line-numbers
ip6tables -D FORWARD 1
ip6tables -I FORWARD -p tcp -d 2001:4c4e:1941:e100:e518:1b32:ebca:36e5 --dport 12345 -j ACCEPT
ip6tables -I FORWARD -p udp -d 2001:4c4e:1941:e100:e518:1b32:ebca:36e5 --dport 12345 -j ACCEPT
szükséges? Vagy lehet ezt valahogy automatizálni? -
Borisz76
nagyúr
válasz
Icewloxy
#71785
üzenetére
Van egy jó , saját routered ?
Ha igen , akkor az ügyfélszolgálattal rakasd birdge módba és használd a saját routeredet.Ekkor a szolgáltatói eszköz nem piszkál bele semmit.
A saját routeren kell beállítani a PPPoE csatlakozás adatait.
Végpont azonosítót és a hozzá tartozó jelszót.
Mindent a saját routered intéz.
Ez a legjobb megoldás.Mod :
Amúgy lehet , hogy érintkezési hibás a kábel....ezért dobja le Gigabitről ( 10/100/1000 ) Fast Ethernet-re ( 10/100 ) a sebességet.
Cserélj kábelt első körben.....Mod2 :
Korábban írtam másnak is erről....még Digi volt akkor.
[link] -
-
Borisz76
nagyúr
válasz
dokee78
#71772
üzenetére
A kérdés jó , nem tudom mert nekem nincs.
Azt az egy eszközt , amit beállítottam ..azt pedig aránylag egyszerű volt üzembe helyezni és igen....telefon kellett hozzá. Emlékeim szerint volt egy APP amit telepítettem ...
Telefon wfi-jével csatlakoztam hozzá.
Ott ki kellett választani, hogy mi legyen a "forrás" wifi + meg kellett adni a hozzá tartozó jelszót , majd amit a készülék sugároz....milyen néven tegye + jelszót beállítani neki. Restart és a kis eszköz csatlakozott a forrás wifihez meg szórta a sajátját.....amit a telefonon is láttam.
De az ilyen egyszerű eszközöknél nem is nagyon van más lehetőség a beállításra...csak a telefon. -
#71771
Reggie0
félisten
MasterMark
#71770
Reggie0
félisten
válasz
MasterMark
#71770
üzenetére
Elobb irtam, hogy nem onnan jon. A problema forrasa, hogy a szolgaltato esz nelkul cserelgeti a cimeket. Ezt pedig nem az IPv4 szokas miatt teszi, hanem mert penzt akar kerni azert, hogy ne cserelgesse a cimeket. Azaz kvazi vedelmi penzt akar.
-
#71770
MasterMark
titán
Reggie0
#71769
MasterMark
titán
-
#71769
Reggie0
félisten
MasterMark
#71763
Reggie0
félisten
válasz
MasterMark
#71763
üzenetére
Messze nem errol van szo. Az egesz szolgaltatas profitorientaltan megy. Tehat ebbol adodik, hogy a cimcsere nem logikai szuksegszeruseg, hanem egyfajta szivatas. Az meg a szokasos hetkoznap, hogy a komplex funkcionalitasok sosem mukodnek 100%-osan, foleg sok gyarto es sok eszkoz eseten, szabvany ide vagy oda. Emiatt ugy lesz stabil a halozat, ha lokalisan valtozatlan cimekkel mukodnek az eszkozok es a szolgaltatotol kapott cimtartomanyba a router forditja, minthogy allandoan cserelgetni az eszkozokon a szolgaltato kenye-kedve szerint, aztan szivni a glitchekkel. Lasd itt is volt nem egyszer tema, hogy papiron ez egy lezongorazott funkcio, csak lemegy RA alapjan mindenhova az uj cim(prefix), de a gyakorlatban azert elofordulnak vele gondok, szakad a kapcsolat, stb. es vegul az a legkenyelmesebb megoldas, ha minden eszkoz a helyi dns-tol kap egy lokal cimet.
Szoval de, ez csak marketing, mert a gyakorlati korulmenyekkel nem kompatibilis.
-
-
Borisz76
nagyúr
válasz
dokee78
#71765
üzenetére
Szia !
Alap infók :
- 2.4 GHz-s rádió nagyobb területet képes lefedni.
Alacsonyabb az adatátviteli sebessége.
- 5 GHz-s sáv kisebb területet tud lefedni de nagyobb az adatátviteli sebessége.
- Minél magasabb a frekvencia annál jobban blokkolják a falak a födém , a terptárgyak....főleg ha fémből van de a vályog fal is nyeli a rádióhullámokat !
- Ezért BIZOS , hogy ugyanaz az eszköz másképpen működik másik házban...mert mások a körülmények.
- A kliens-nek ( telefon , tablet , Laptop ) is ismernie kell az adott wifi szabványt ( AC , AX stb... )A linkelt eszközökön NINCS LAN csatlakozó.
Ezért rádión veszi az eredeti wifi jelet ...aztán más néven sugároz tovább. Mivel ad-vesz-ad-vesz ezért FELEZŐDIK az elérhető sebesség is !
Nos...nem azt mondom , hogy használhatatlan....mert böngészi esetleg YT videókat nézni lehet velük.
De másra nem igen jók mert alapvetően lassúak.
Erre megoldás lehet :
- Hasonló eszköz amin van 10/100/1000-s azaz GIGABIT-es csatlakozó , 2 wifi sávot tud ( 2.4 és 5 GHz ) , nagyméretű 2 vagy több antennával.
- Vagy egy router AP módba állítva.
- Vagy egy dedikált APEzen eszközöket pedig LAN kábellel a te FŐ routeredve csaltlakoztatod.
Egyedüli előnye a linkelt eszközöknek, hogy könnyen viheted magaddal és használhatod máshol is....akár napi szinten hurcolászva.
Természetesen az igényeidet nem ismerem ezért nem tudom, hogy neked melyik megoldás lenne a legjobb. -
#71760
daninet
veterán
MasterMark
#71759
daninet
veterán
válasz
MasterMark
#71759
üzenetére
Nem vagyok teljesen biztos mire gondolsz, a routerben ki van kapcsolva a biztonsági blokkolás
-
daninet
veterán
válasz
daninet
#71757
üzenetére
Hozzáadtam egy statikus útvonalat a PC-men de így sem jo
~ sudo ip route add 192.168.2.0/24 via 192.168.1.200 Fri 30 May 2025 10:17:05 CEST
[sudo] password for daninet:
~ ip route 3192ms Fri 30 May 2025 10:32:58 CEST
default via 192.168.1.1 dev enp31s0 proto dhcp src 192.168.1.103 metric 100
192.168.1.0/24 dev enp31s0 proto kernel scope link src 192.168.1.103 metric 100
192.168.2.0/24 via 192.168.1.200 dev enp31s0 -
daninet
veterán
Sziasztok!
Tegnap ujraindítottam a házi szerverem és azóta fura mód nem érem el a PC-mről a Home Assistant-ot. Tudtommal módosításokat nem végeztem rajta. Unraid alapú a szerver.
Alábbi a felállás:
192.168.1.0/24 subneten van a házi szerver (címe 192.168.1.200)
A home assistant virtuális gép a 192.168.2.0/24 subneten van (címe 192.168.2.200)
Az összes IoT eszközöm a .2.0/24 subneten van.Wifiről telefonon elérem a .2.200 címet és bejön a home assistant. A házi szerveremen terminálból meg tudom pingelni és elérem a címet. Az IoT eszközök elérik a HA-t.
Viszont a PC-m aminek a címe 192.168.1.103/24 nem éri el a 192.168.2.200 címet.Unifi routerem van, most próbából beraktam egy ilyen szabályt, de semmit nem javított a helyzeten:
A PC-n fedora 42 fut.
ip address
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp31s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 70:85:c2:b5:4e:f0 brd ff:ff:ff:ff:ff:ff
altname enx7085c2b54ef0
inet 192.168.1.103/24 brd 192.168.1.255 scope global dynamic noprefixroute enp31s0
valid_lft 79675sec preferred_lft 79675sec
inet6 fe80::d672:946d:e495:6400/64 scope link noprefixroute
valid_lft forever preferred_lft forever~ ip route Fri 30 May 2025 09:55:55 CEST
default via 192.168.1.1 dev enp31s0 proto dhcp src 192.168.1.103 metric 100
192.168.1.0/24 dev enp31s0 proto kernel scope link src 192.168.1.103 metric 100 -
#71756
jerry311
nagyúr
MasterMark
#71754
jerry311
nagyúr
válasz
MasterMark
#71754
üzenetére
Sajnos van NAT IPv6-on, mert valakinek kellett, pedig igazan megszabadulhattunk volna mar tole amikor tobb IPv6 cim van mint atom a vilagegyetemben.
Oke, otthoni kornyezetben remelhetoleg nem talalkozik 6-to-6 NAT-tal az ember.
-
#71755
Doky586
félisten
MasterMark
#71754
válasz
MasterMark
#71754
üzenetére
Tehát az automatika tűzfal szabályt tud kezelni, nat szabályt (portforwardot) nem. Igen ez is egy lehetőség, de csak lehetőség. A tesztben való megerősítéshez ezért kértem hogy mondjatok ftps publikus szervert, de senki nem tudott mondani ilyet.
Pedig mindenképp biztosra kell menni mert az alternatíva az amit mrots is mondott hogy nincs is benne tűzfal, ezért megy ipv6-on és ezért nem megy ipv4-en a filezilla-kliensel.És akkor még ott van hogy ipv4-en a Totalcommander ftp kliense mind aktív mind passzív módban csatlakozik. Mind az androidos mind a windowsos verzió. Mindenféle portforward nélkül. Ha nem hiszitek könnyen kipróbálhatjátok magatok is. Ez is rejtély.
-
#71754
MasterMark
titán
Doky586
#71751
MasterMark
titán
válasz
Doky586
#71751
üzenetére
Mondjuk két dolgot kevertek amúgy. IPv6-on nincs NAT, szóval nem kell port forward. Tűzfalon attól még átmehet, mivel egy stateful tűzfal related kapcsolatnak fogja látni, és átengedi.
IPv4-en pedig nincs automatikus port forward, még ha a tűzfal át is engedné, akkor se talál oda.
-
Ok ezeket tudtam, de nem baj hogy leírtad.
Ok megértettem hogy a passzív FTP befelé jön.
Eszerint ipv4 és ipv6 közt nem látsz ellentmondást?
Ha ipv6-on ki tudja olvasni a linux firm akkor ipv4 en miért nem? Csak routeren tiltottam az ipv6-ot más változás nem volt a kettő közt.
De még mindig ott a TC ről készült kép ami ipv4-en is átjut aktív módban a naton. -
mrots
junior tag
válasz
Doky586
#71745
üzenetére
Lassuk pontrol pontra, mert osszekeversz par dolgot, illetve rossz kovetkezteteseket vonsz le.
"Nem gondoltam hogy ilyen 'okos' a kiöregedő routerem."
Kezdjuk azzal, hogy a legtobb otthoni primitiv router linux alapu, valahol melyen. Linuxban mar 20 eve is letezett connection tracking, illetve FTP tamogatas. Azota letezik, amiota a kernelben ezek a modulok megjelentek, szerintem mar a 2.4-es kernel idejen is voltak ezek, A 2.4-es kernelt pedig 2001-ben adtak ki. Nem annyira hiszem, hogy 26 eves, vagy idosebb routered lenne otthon. Az a helyzet, hogy a "kioregedo" router lehet, hogy neked kioregedo, mert mondjuk 3-4-5 eve megvan, de a protokollok, mint peldaul az FTP mar az 1980-as, 90-es evekben is leteztek. Szoval ebben a kontextusban a routered nem kioregedo. Az a problema, hogy egy alkalmazasnak ket kulon csatornaja van (egy parancs vagy jelzes es egy adatatvitelre hasznalhato) nem uj dolog, az FTP csak az egyik. Ilyen a SIP (signaling + RTP stream), a H.323 de meg egy csomo masik is. Az FTP csak az amivel az otthoni hobbista ossze tud futni. A ket kulon csatorna, illetve ezek egymastol valo fuggetlensege pedig regota problema, amire mint irtam, 20+ eve van megoldas is.Az alapproblema az, hogy van egy tuzfal a halozatban valahol - ez lehet az FTP szerver elott is, de lehet az otthoni felhasznalo es az internet kozott is, sot, lehet mindketto. A tuzfalak regen amikor meg butak voltak csak annyit tudtak csinalni, hogy megmondtad: az X porton Y IP cimrol bejohet a forgalom, mashonnan meg nem. Vagy Y porton X cimre kimehet. Vegyuk a kliens elotti tuzfalat. Ha ez csak annyit tud, hogy bentrol kimehet a forgalom, de kintrol nem johet be, akkor az aktiv FTP sosem fog mukodni. Azert, mert kb hatodjara irom le, hogy aktiv FTP eseten az adatkapcsolatot nem a kliens inditja, hanem a szerver a kliens fele. A tuzfal szempontjabol ez egy random kintrol jovo tcp forgalom, es mint jo tuzfal, nem engedi be a csomagokat kintrol bentre.
Lehetne azt mondani, hogy dehat a bentrol inditott forgalomra erkezo valasz (pl weblap lekerese) is bejovo forgalom azt megis beengedi, ezt miert nem. Azert, mert egy weblap letoltesenel a forgalomat belul kezdemenyezi a kliens a szerver fele, a szerver valaszol ugyanabban a session-ben es kesz. Ez egy egyszeru osszetartozo ketiranyu folyamat es a TCP allapottabla alapjan lehet tudni, hogy egy bejovo forgalom az valasz-e valamire, vagy kintrol kezdemenyezett kapcsolat. Ami valaszt, azt be lehet engedni. Stateful tuzfal, vagy connection tracking tuzfal az ilyen es kb 20 eve minden otthoni szappantarto ilyen, mert a linux is ilyen.
Ugyanakkor az FTP eseten ket kulon session van, a masodik egy kintrol kezdemenyezett, tehat nem valasz egy keresre, hanem egy teljesen onallo adatfolyam. Ahhoz mar a tuzfalnak ossze kene tudnia kotni a dolgokat, hogy lassa: ez a masodik teljesen kulonallo session valojaban kapcsolodik az elsohoz. Ezt is ossze tudja kotni a linux, mint egy 20 eve, ugy hivjak, hogy ip_conntrack_ftp kernelmodul. Tehat az otthoni routerek is elvileg ossze tudjak kotni.
Mint a peldad mutatta, ipv6-on ez meg is tortent. Kezdemenyezett a szerver feled egy masodik adatfolyamot, bejott, mukodott, kesz. Vagy nem volt tuzfal, vagy pedig osszekototte a dolgokat es rajott, hogy be kell engednie. Nem nagy mutatvany. Viszont ez valoban arra utal, hogy ipv6 felett tarva-nyitva volt a halozatod, barmilyen csomag ami a belso halozatodra ment az oda is jutott. Bator dolog, minden egyes vegpont a belso halozatodon direktben elerheto volt, hiszen semmilyen ipv6 tuzfal nem allitotta meg az ftp csomagot sem, ahogy amugy elvarhato lett volna. Hogy nem tudja ezt a router, vagy csak nem allitottad be, az az eredmeny szempontjabol tokmindegy.
"Mégse olyan okos a routerem. IPv4-en már nem tudott aktívban kapcsolódni."
Ugyanakkor, a masodik peldad IPv4 felett volt (szinten aktiv FTP). IPv4 felett az otthoni felhasznaloknal van cimforditas tehat (mivel csak 1 cim van) PAT (amit hibasan NAT-nak hivnak az egyszeru felhasznalok, de hagyjuk rajuk).Mig IPv6 felett a te munkaallomasod kozvetlenul cimezheto az ftp szerver szamara, tehat nincs cimforditas (bar van olyan szolgaltato aki ipv6-on is csinal, de keves) ezert az ftp szerver megcimezte a laptopod ipv6 cimet es kozvetlenul elerte. A laptopod pedig inditotta az ftp kapcsolatot, o mondta meg a PORT paranccsal, hogy melyik porton varja vissza az adatot es amikor az megerkezett, kozvetlenul neki cimezve, akkor elfogadta es kesz, tehat mukodott.
De IPv4 felett nem tudja megcimezni kozvetlenul a szerver a laptopodat. IPv4 felett a routered publikus cimerol latja erkezni a kapcsolatot, de azt valojaban nem a routered inditotta, hanem mogotte egy gep. A routered pedig annyit csinal, hogy amikor bejon valami csomag kintrol, akkor megnezi, hogy az melyik bentrol inditott kacsolathoz tartozik. Visszaforditja az IP cimeket es bekuldi a belso halozatra. Mit lat a routered aktiv FTP eseten? Bejon az o cimere egy csomag az ftp szerver 20-as portjarol, de mivel ez nem valasz valamire, hanem kintrol lett kezdemenyezve, a cimfordito tablazataban nem talal hozza bejegyzest. Tehat nem tudja betovabbitani. Ezert timeout-ra fut az egesz, mer a szerver kuldi kuldi de a windowshoz nem jon meg es feladja. Ezert segitett az, ha elore megmondtad, hogy a a port, amit a windows ftp kliens majd mondani fog, az oda a router cimere beerkezo csomagokat tovabbitsa a windowsra, akkor ezeket a router tudta cimforditani es igy megerkezett minden. De ez nem biztonsagos es nem javasolt, ezt a routernek dinamikusan kell kitalalni, nem mindenfele jottment forgalmat betovabbitani.
"scannerek egyike azt mondja hogy minden portom zárva, még az is amin pc-n torrentezek, másik meg azt mondja hogy minden portom nyitva van"
Az elso, amit belinkeltel az URL alapjan TCP portokat tesztel. A masodik amit belinkeltel pedig UDP portokat. A ketto tehat nem ugyanazt teszteli. Egy TCP port zarva van akkor, ha a ra kuldott csomagra TCP RST erkezik vissza. Az UDP viszont nem tamogat ilyen flag-eket, tehat nincs UDP reset flag.
Azaz, ha kuldesz egy TCP portra egy csomagot, amit amugy be tudsz kuldeni, de arra TCP RST jon, akkor az a port tekintheto ugy, hogy zarva van, mert a TCP RST-t kuldhette egy tuzfal is. Igaz, akkor is TCP RST erkezik vissza ha nincs tuzfal, hanem csak siman nem bind-el semmi szolgaltatas az adott portra, ekkor a kernel valaszol vissza. UDP eseten ilyen valasz nincsen. Ha jon valasz akkor jon, ha nem akkor nem, ebbol kovetkeztetest nem lehet levonni.
Ennel bovebben nem tudom, mert ennyi energiat ebbe belefektetni eppen eleg volt, szoval a linkeket reszletesen nem neztem meg, csak az URL-bol gondolom, hogy ezert adott ket kulonbozo eredmenyt.
-
válasz
jerry311
#71748
üzenetére
Én ezt nem tudom másként értelmezni, csak hogy nincs.
Internetes ipv6 port scannerek egyike azt mondja hogy minden portom zárva, még az is amin pc-n torrentezek, másik meg azt mondja hogy minden portom nyitva van. Kivétel nélkül. Szóval azoknak nem lehet hinni. Ez pedig 10/10-et ad.
Még a tegnapi friss firmel is. Előtte egy évvel ezelőtti volt rajta.
-
-
mrots
junior tag
válasz
Doky586
#71741
üzenetére
Teljesen biztosan elbeszelunk egymas mellett. Az altalad berakott kep ugyanazt mondja, amit en. Nyilvanvaloan nem jol fejeztem ki magam, ha nem ment at.
Amit en mondtam: az aktiv FTP hasznalata eseten a parancs csatornan (tcp/21) a kliens altal inditott kapcsolaton keresztul a kliens PORT paranccsal jelzi a szervernek, hogy melyik sajat portjara varja az adat csatorna felepiteset.
Nezd meg a sajat screenshotodat az aktiv FTP-rol. Ahol EPRT parancs van, abban a sorban (ahol az ipv6 cimedet kitakartad) szerepel a 49571. Ezt a parancsot (EPRT) a kliens kuldi a szervernek a parancs csatornan.
Erre valaszkent a szerver visszavalaszol (alatta levo zold sor), hogy PORT parancs sikeres. Azaz a szerver megertette. Majd kiadod a konyvtar listazasi parancsot, azaz konkreatan elkezdodik az adat csatorna felepitese. Az MLSD parancsra (kek sor) a szerver valasza (alatta zold sor): 150 Conecting to port 49571. Tehat a szerver a sajat tcp/20-as portjarol indit egy uj, masodik kapcsolatot vissza a klienshez, annak a 49571 portjara. Ez az amit en eddig is mondtam. Aktiv FTP eseten ez igy mukodik.
Amennyiben az atjaro tamogatja az FTP-t mint alkalmazast, ez minden tovabbi nelkul mukodni is fog. Miutan belelatott a 21-es porton futo kommunikacioba, latta, hogy a kliens azt uzente a parancs csatornan a szervernek: a 49571 -es portomra kerem az adatokat. A tuzfal ezt latvan felkeszult arra, hogy kintrol, a szerver IP cimerol be fog erkezni egy, az elozotol fuggetlen TCP kapcsolat, a szerver 20-as portjarol es azt be fog kelleni engedni, mert ez nem egy random valami, hanem a megfigyelt es felepitett FTP kapcsolatoz fog tartozni.
Mivel regen az ilyen tuzfalak nem voltak maguktol ertetodoek, ezert regen az aktiv FTP kevesse sikerult mikor a vilag elkezdte letuzfalazni magat mindenhol. Ahhoz, hogy tovabbra is menjen, a tuzfalad tamogatasa kell es ez a tamogatas nem mukodik, ha nem tud belelatni a 21-es port kommunikaciojaba, mert nem fogja tudni, hogy a sok bejovo kapcsolat kozul melyik az, amit be kell engednie.
En csak ennyit mondtam az elejetol kezdve, de egyatalan nem ment at. Mindenesetre orulok, hogy a sajat kepernyofotod is igazolja mindezt.
-
-
válasz
jerry311
#71737
üzenetére
NEM az FTP szabványról beszélünk hanem az implementációról a programokban.
Nálam TC-vel mindkét módban összejön a kapcsolat, de egy másik programban nem.Passzív: [kép] [kép]
Aktív: [kép] És az én helyi ip címem, így gondolom én küldöm.De lehet az IPv6 is bezavar nála. Szerencsére ez a program csak IPv4-et használ.
-
mrots
junior tag
válasz
Doky586
#71734
üzenetére
Nem bizonygatom, hanem ugy van. Kell portot nyitni es ezt automatikusan elvegzi az a tuzfal, ami erre kepes.
Hogy megertsd, a funet.fi -s szervert hasznalva (nem tudom ez mivel valodibb, mint barmilyen mas ftp szerver de ezen lepjunk tul). Tovabbra is csak az aktiv ftp-rol van szo.
Egy FTP-t nem ismero, alkalmazasi reteget nem ismero tuzfal mogott aktiv FTP kapcsolat nem fog menni:
User (ftp.funet.fi:(none)): ftp230 Anonymous user logged inftp> dir200 PORT command successful425 Could not open data connection to port 56879: Permission deniedVedd eszre, hogy ez az elvart mukodes. Eppen ezert volt szukseg a passziv FTP-re. Aktiv FTP eseten ugyanis amint lekernem a konyvtarstrukturat, a funet.fi szerver a sajat 20-as portjarol inditana egy adatkapcsolatot a kliens altal megadott portra, ami itt az 56879. A hibauzenet azt mutatja, hogy ez nem ment. Mindekozben a tuzfal logjaban ez latszik:
May 28 12:06:38.047: %IPV6_ACL-6-ACCESSLOGP: list acl_outside-in-v6/200 denied tcp 2001:708:10:8::2(20) -> 2001:470:xxxx:xxx:xxxx:xxxx:xxxx:xxxx(56879), 1 packetErtelemszeruen a sajat ipv6 cimem kimaszkoltam, de teljesen jol lathato, hogy a tuzfal eldobta a funet.fi szerver 20-as portjarol a klienshez beerkezo kapcsolatot. Ez egy uj kapcsolat, amit a szerver indit a kliens fele. Es azert dobodik el, mert a tuzfal nem az alkalmazasi retegben dolgozik, nem ismeri, hogy mukodik az FTP, nem tudja osszekotni, hogy az elso session, ami bentrol indult es a masodik session, ami kintrol indult volna, az osszetartozik.
Igy mukodik az aktiv ftp es ez a magyarazata annak, hogy miert kell passziv ftp-t hasznalni ilyen kornyezetben - az maskepp mukodik, ott valoban a kliens inditja mindket csatornahoz a kapcsolatot.
Mi tortenik akkor, ha a tuzfal ismeri az FTP alkalmazast es dolgozik az alkalmazasi retegben? Ekkor figyeli a parancs csatornat es a szerver felol inditott, kliensnek cimzett kapcsolatot be fogja engedni. Ez az, amit titkositott FTP eseten nem fog tudni megtenni, mert nem tudja, hogy melyik lesz az a session, ami az elsohoz tartozik majd, mert nem latta az elsoben a masodikra vonatkozo informaciokat.
-
#71734
Doky586
félisten
MasterMark
#71733
válasz
MasterMark
#71733
üzenetére
Ezt mondom én is.
Mrots bizonygatja az ellenlezőjét. -
mrots
junior tag
válasz
Doky586
#71730
üzenetére
"Akkor próbáld a routeren a "Port Triggering" funkciót"
Nekem nincs FTP problemam, az eredeti kerdezonek volt, es mar megoldodott. Neki nem tudom ez segitett volna, mert nem tudom mit jelent a port triggering."A win ftp servere szerintem túl buta"
Senki nem hasznalt win ftp szervert, en a peldamban win ftp _klienst_ hasznaltam azert, hogy lathato legyen, az aktiv ftp ugy mukodik ahogy leirtam. -
Akkor próbáld a routeren a "Port Triggering" funkciót, (ott a portforward mellett) talán erre való, ámbár sose használtam. A win ftp servere szerintem túl buta, nálam a ftpzilla server vált be, ott megadható a külső ip. [kép] és csak passzív módot támogat. Egy gondal kevesebb.
-
mrots
junior tag
válasz
jerry311
#71727
üzenetére
Amugy te elolvasod azt, amire valaszolsz? Ezzel kezdtem:
Ez egy aktiv ftp kapcsolat, mert a windows beepitett ftp kliense csak ezt tamogatja, soha nem is tamogatott passziv modot
Mire azt valaszolod, a magad sajatos stilusaban, hogy nope, a parancssori kliens csak aktiv modot tud. Eppen ezt irtam le. Egesz vegig az aktiv FTP-rol beszeltem.
-
mrots
junior tag
válasz
Doky586
#71721
üzenetére
"A 20 port teljesen megszűnt. Mindkét módban ma már mindkét csatornát a kliens indítja."
Szerintem nem szunt meg es nem, nem inditja mindket modban a kliens a csatornat. Lasd a mellekelt kepet, amin pontosan latszik egy ftp kapcsolat, amit az iment az otthoni nasomra inditottam.
Ez egy aktiv ftp kapcsolat, mert a windows beepitett ftp kliense csak ezt tamogatja, soha nem is tamogatott passziv modot, tehat teszteleshez es demonstralashoz megfelel most.Mint lathato, plaintext ftp-t teszteltem, mert nincs jelentosege a titkositasnak az aktiv ftp mukodesenek megerteseben, sot, nehezitene azt. A sikeres belepes a 21-es porton tortenik, ami a parancs csatorna. Az, hogy ezt a kapcsolatot a kliens inditotta az nyilvanvalo, hiszen o kezdemenyezte az ftp kapcsolatot - lasd cmd ablak.
Amikor a dir parancsot kiadtam, ami valojaban egy FTP LIST parancs, a packet capture mutatja, hogy a kliens egy PORT paranccsal indit, aminek hat parametere van. Az elso negy szam, vesszokkel elvalasztva a kliens IP cime, ez az a cim, ahova a kliens varja, hogy a szerver inditsa az adatkapcsolatot. Az utolso ket szam pedig a portszam, ahova a kliens varja az adatkapcsolatot a szervertol. A portszam ugyebar 0-65535 kozott lehet, a kliens 206, 167 -et kuld portszamnak. Ebbol a szerver tudja kiszamolni a tenyleges portszamot, ami ugy kovetkezik, hogy 206 * 256 + 167. Azaz 52736 + 167 = 52903. Es valoban, ha megnezed a forgalomban a sotetszurke sorokat, akkor itt a NAS a sajat IP cimerol es a sajat 20-as portjarol indit egy uj kapcsolatot (TCP SYN) a kliens IP cimere es a fentiekben kiszamolt 52903 portszamra, es ide kuldi az adatot.
Tehat mint lathato, 1) de, igen, hasznalatban van a mai napig a 20-as port az aktiv FTP kapcsolatban, es 2) de, valoban a szerver kezdemenyezi a kapcsolatot visszafele a kliens fele a sajat 20-as portjarol.
Eppen ezert kellett kitalalni a passziv FTP kapcsolatot, mert 1) ha lenne tuzfal a szerver es kliens kozott ami nem alkalmazas-ismero, akkor egy kivulrol erkezo latszolag random kapcsolatot szo nelkul eldobna, illetve 2) ha van NAT a kliens es szerver kozott, akkor a kliens nem tudvan errol, a sajat valodi cimet kuldi el a PORT parancsban, de a kapcsolatot nem erre, hanem a cimforditott cimre kell kezdemenyeznie a szervernek, ezt a cimet viszont a kliens nem tudja, hogy micsoda.
Szoval de, igy mukodik az aktiv FTP ma is.
-
-
válasz
Csaba.no1
#71720
üzenetére
Valóban aktív módnál a régi leírások nem fedik a mai aktív módú működést. Mostanra alig különbözik az aktív és passzív mód. Csak annyi a különbség hogy nem a server mond portszámot hanem a kliens hasraütésszerűen kitalál egy 1 és 65 ezer közti számot és utasítja a szervert hogy ott várja a kapcsolatot. A 20 port teljesen megszűnt.
Mindkét módban ma már mindkét csatornát a kliens indítja. -
Csaba.no1
tag
válasz
jerry311
#71714
üzenetére
Köszönöm mindenkinek a választ!
Eredetileg is egyébként az alapértelmezett portokon akartam volna kipróbálni a kapcsolatot. A 22-es portot hiába nyitom és állítom be az ellenőrzésekor zárva van, a 21-es pedig gond nélkül nyitható. TC-vel szeretném használni a FileZilla szervert, a TC csatlakozáskor az entering passive mod után a starting data transfernél (letöltés) megáll. szerver oldalon pedig: Failed connection for data socket. Reason: ETIMEDOUT - Connection attempt timed out." -
mrots
junior tag
válasz
Doky586
#71716
üzenetére
Sehol nem mondtam, hogy ne lenne biztonsagos. Arra hivtam fel a figyelmet, hogy mikozben a titkositas megold egy problemat (az adatvedelmet, bizalmassagot) addig letrehoz egy ujat: lehetetlenne teszi a dinamikus portnyitast egy kozbenso, amugy erre kepes tuzfal szamara.
-
Az FTP + TLS = FTPS tökéletesen biztonságos ha odafigyel a user. TC és a Filezilla kliens is figyelmeztet hogyha megváltozik a tanúsítvány. A szerver is elveti az adatcsatorna kapcsolatát ha annak tanúsítványa nem egyezik a vezércsatornáéval.
Cégnél ha csak bizonyos portok vannak kiengedve az valóban gond mert nem jut ki a kliens. Ekkor szerver oldalon lehetne változtatni persze amihesz szintén semmi köze a kliens oldali usernek.
-
mrots
junior tag
válasz
jerry311
#71714
üzenetére
"FTP titkositastol fuggoen lehetnek meg problemak.
Titkositatlan FTP nem javasolt, mert titkositatlanul megy rajta a felhasznalonev es jelszo is."Ugyanakkor viszont egy titkositott FTP kapcsolatban az parancs csatornan (tcp/21) amikor a kommunikalo felek megbeszelnek az adat csatorna portszamat, hiaba van tuzfal, ami dinamikusan kinyitna ezt, nem fogja tudni, mert a titkositott kommunikacioba nem lat bele. Igy aztan konnyen eloallhat az a helyzet, hogy a titkositott FTP nem mukodik, megha minden egyeb komponens rendelkezesre is allna, csak azert, mert a tuzfal nem tudja, melyik portot kellene kinyitnia.
Megoldas lehet visszaterni az aktiv ftp kapcsolatra, ahol fixen a tcp/21 hasznalatos parancs kommunikaciora es tcp/20 hasznalatos adatkommunikaciora, nincs semmi dinamikus. A dinamikus portokat a passziv FTP vezette be. A trukk ott van, hogy aktiv FTP eseten a tcp/20 forgalmat a szerver nyitja (a tcp/21 -et a kliens nyitotta) tehat ha van tuzfal a kliens oldalon, akkor azt kell felkesziteni arra, hogy a tcp/20 porta bejovo forglaom engedelyezve legyen.
Amugy azert eleg kemeny, hogy a szolgaltato egy trivialisan ftp / tuzfalazasi problemara automatikusan modemet cserel es oszinten hittek abban, hogy ez lesz a megoldas.
-
jerry311
nagyúr
válasz
Csaba.no1
#71712
üzenetére
TCP/21 csak a vezerlo port. Azon nem megy adat.
Passziv modban a szerver TCP/21-en egy vezerlo uzenetben megmondja melyik veletlenszeru portra csatlakozzon a kliens ha adatot akar. Ezt egy jobb tuzfal automatikusan nyitja, mert figyeli az FTP forgalmat. Ha nem figyeli, akkor az adatkapcsolat nem megy at, csak a vezerlo.
Egy jobb szerveren be lehet allitoan, hogy milyen tartomanybol osszon ki dinmaikus portokat adatpakcsolatra. Es egy egyszerubb tuzfalon elore ki lehet nyitni azokat a protokat. Nem idealis.
FTP titkositastol fuggoen lehetnek meg problemak.
Titkositatlan FTP nem javasolt, mert titkositatlanul megy rajta a felhasznalonev es jelszo is.Javaslom TCP/22-n (ha az alapertelmezett porton hagyod) az SCP-t vagy SFTP-t. Mindeketto titkositott es csak egy portot hasznal, nem nyitogat ujabb portokat dinamikusan.
-
krealon
veterán
válasz
Csaba.no1
#71712
üzenetére
Az FTP kettő darab portot (csatornát) használ az átvitelre.
1-es: a Szerver 21-es portján a különböző parancsokat fogadja a klienstől.
2-es: egy dinamukusan kiválasztott portot kell nyitni az adatátvitelhez. A könyvtár lista is egy adatátvitel.A dinamikus port nyitását a 21-es port kódolatlan forgalmában beszéli meg a szerver és a kliens.
Ha a van útközben NAT-oló eszköz (pl a szolgáltatói vagy saját router), akkor annak kell hogy legyen egy aktív FTP segítő modulja, ami ezt a dinamikus portnyitást lehetővé teszi.A másik lehetőség, hogy az (elég fejlett) FTP szerverben meg lehet adni egy port-tartományt, amit felhasznál adatátvitelre és routerben ezt a port-tarományt kell a szerver IP címére forwardolni.
Például ilyen FTP szerver Windows-on a FileZilla szerver.De a legjobb az lenne, ha az FTP szabványt már senki sem használná.
-
Csaba.no1
tag
Sziasztok!
FTP szerver gondjaim vannak, remélem valaki tudna ötlettel szolgálni.
Belső hálózatot illetően minden rendben működik.
Külső hálózatról viszont elérem és be is jelentkezik, de a könyvtárat már nem látom és utána a kapcsolat időtúllépéssel meg is szakad. A szolgáltatóm telekom koax hálózaton, a szerver jelenleg is fixen az eszközükre van kötve. Az FTP-hez köthetően csak az alapértelmezett 21-es portot tudom kinyitni, a többit nem engedi, illetve külső hálózatról a távoli aztali kapcsolat működik nyitott portal. Windows tűzfal teljesen kikapcsolva, a gép fix ip-re állítva. A szolgáltatónál a hibajelentésemre kicserélték az eszközüket egy újabbra, a problémát nem oldotta meg. Natolva nem vagyok, lehet esetleg a hálózatukon valami FTP-vel kapcsolatban elkonfigurálva? Az eszközüket nem tudják bridge módba tenni az android tv miatt. Végig nyálaztam itt a fórumot, sajnos előrébb nem vagyok.
A segítséget előre is köszönöm!
Üdv,
Csaba -
Truman
senior tag
válasz
Truman
#71678
üzenetére
Úgy volt ahogy mondtátok, rákötöttem a számítógépet az NVR egyik POE kamera portjára, a hálókártyának fix IP címet adtam a 192.168.254... tartományból és simán elértem a kamerákat egyenként.
Jelentem nem égett le semmi! (bár biztos amit biztos 2 db swich -en keresztül és egy Temu -s USB -s LAN kártyával nyomultam )
Köszönöm a segítséget!do3om:
Mi az a PR, a szolgáltató? A modemet nem hagyhatod ki, mert csak azt tudja kezelni az optikai hálózatot. Sima UTP kábellel kell összekötni a két routert. És igen, oda vidd ahol jobb a jel az egész házban.
dokee78:
Arra csak a WDS bridge üzemmód ezen az típuson, amit a Wi-Fi beállításoknál találhatsz meg. De TP-Link routeren nekem az még soha nem működött stabilan. Bár lehet én voltam a béna.
-
Truman
senior tag
válasz
dokee78
#71697
üzenetére
Ha ezzel a gyors beállítású varázslóval akarod akkor a Dynamic IP -t kell használni.
Persze ahhoz hogy ez működjön különböző alhálózatban kell lenni, ami elvileg adott mert TP-Link: 192.168.0.1 Huawei: 192.168.8.1 A kábelnek a WAN/Internet portban kell lenni.
Ennek persze hátránya lehet a dupla címfordítás. Ami port átirányításoknál okozhat bonyodalmat.Ami ennél jobb az AP mód. De az ennél a típusnál nincs külön opcióként azt meg így tudod beállítani.
default gateway IP-re csak tölt tölt és semmi. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Gubek-Einste- Nem várt platformon a OnePlus Nord 5
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- gban: Ingyen kellene, de tegnapra
- Tőzsde és gazdaság
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- iPhone topik
- Milyen házat vegyek?
- Proxmox VE
- sziku69: Szólánc.
- További aktív témák...
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- LG 65B4 - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready
- Crucial 240GB SSD eladó
- Dell Latitude 8-11. gen i5, i7, 2-in-1 szinte minden típus csalódásmentes, jó ár, garancia
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest