SSH elérés NAT-on keresztül

Hálózatok egyéb

A lényeg annyi, hogy a kedves ISP-m nem képes nyilvános IP-t adni, végig NAT-ol Budapesttől legalább a Balaton déli partjáig, mert én itt vagyok.

Szeretném elérni a gépemet ssh-n és sftp-vel távolról, de ha a nyilvános ip-vel csatlakozni akarok, akkor ki tudja kinek a gépére próbálok belépni :P Nem az enyémre az biztos, mert nem fogadja el a belépési adatokat.

Ha átállítanám más portra az ssh szolgáltatást, akkor meg a szolgáltató tűzfala miatt nem megy.
Szóval ezt valahogy nem lehet kiküszöbölni?

Mondjuk valami virtuális hálózattal, ami pl https-en keresztül küldi az adatokat, aztán a végén a gépemen átfordul ssh-ra. És egy egyedi azonosítóval (mint pl. TeamViewer esetén) vagy egy másik nyilvános IP-vel elérhetném a gépet. (bár ez utóbbi nem lenne túl biztonságos.

Szóval szerintetek van erre valami megoldás?

  • 17801 megtekintés

( VaZso v | 2012. 03. 01., cs – 22:40 )

Megoldás lehet pl. egy reverse ssh tunnel, de ehhez kell egy másik, publikus hálózaton lévő gép.

Tehát indítasz egy ssh kapcsolatot a NAT-olt hálón lévő géped felől a publikus hálózaton lévő gép irányába (ennek folyamatosan élnie kell), majd pedig ezen a gépen keresztül intézed a korábban megnyitott tunnelen keresztül a belépést vissza a NAT-olt hálózat felé.

Mondjuk egy VPS alkalmas lehet a feladatra.

Írjam le paraméterekkel? :)

Ssh tunnelt még nem csináltam, de jó ötletnek hangzik. Szóval ha tudsz valami konrétumot írni, azt megköszönném :)

Van mobilnetem is, de az telón keresztül megy, nem akarom itthon hagyni :D
Viszont ha keresek valakit akinek van nyilvános IP-je, nagyjából mindig megy a gépe, akkor megbeszélem vele a dolgot. Ha dinamikus az IP, az már nem gond, dyndns-el vagy valami hasonlóval gondolom megoldható.

Nos. :)
Kétféle ssh tunnel létezik - egyfelől a normál (forward) ssh tunnel valahogy így néz ki:

ssh user@gép.hu -L1234:távoli_cím:5678

Tehát gép.hu-ra lépsz be, a távoli gépen keresztül a távoli_cím gép 5678-as portját a helyi gép 1234-es portján éred el.
Ez esetben a távoli_cím-hez localhost-ot írva annak a gépnek az adott portjához férhetsz hozzá, amihez kapcsolódsz.
(Tehát a helyi gép jelen esetben a távoli gépnek felel meg.)

Gyakorlatban pl. a távoli hálózaton van egy routered mondjuk a 192.168.1.1-es címen és ehhez hozzá szeretnél férni a helyi gép böngészőjével a localhost:8080 webcímen, akkor ezt adod ki:
ssh user@gépcím -L8080:192.168.1.1:80

(Tehát 192.168.1.1 helyett localhost-ot írva pedig a távoli gép egy portját tudod elérni.)

Ami téged érdekel most, az a reverse tunnel - tehát nyitsz egy kapcsolatot a másik (távoli) gép felé, amin hallgatsz.
Ha a távoli gép mondjuk 4022-es portján szeretnéd elérni a helyi gép 22-es portját, azt így tudod megtenni:
ssh user@gépcím -R4022:localhost:22

Tehát a helyi gép ebben az esetben az a gép, amiről a kapcsolatot kezdeményezted.

Érdemes lehet megnézni még az autossh programot, ez elvileg felépíti újra a kapcsolatot, ha megszakadna, ill. szintén érdemes utánanézni a kulcsalapú hitelesítésnek, ha automatikusan szeretnéd indítani a dolgot.

Ami még érdekes lehet, az a -p paraméter, ezzel tudsz az alapértelmezettől eltérő portra kapcsolódni (pl. -p4022) - ha itt éred el az ssh szolgáltatást.
Paramétereknél kis és nagy betű lényeges, pl. -l -lel felhasználónevet adsz meg.

Ezután csak azt kell megoldanod, hogy a publikus IP-n lévő gép adott portjához csatlakozva elérd a tunnelt vagy be tudj lépni a gépre és onnan átmenni a másikra.

A portszámokat random írtam, nem biztos, hogy érdemes ezeket használni. :)

Remélem, nem voltam túl kacifántos - fáradt vagyok és egyébként is hajlamos vagyok kicsit túlbonyolítani. :)

Egyébként szerintem mobilhálózaton sem igen szokták hagyni a belépést kívülről.

No ezt majd holnap kipróbálom...

Jelenleg azzal szórakozom, hogy http://www.pcflank.com -on scannelem a portjaimat.
Van néhány nyitott. (jelenleg virtuális géppel tesztelem) A virtuális gép sshd_config fájlban átírtam a portot egy nyitott portra (mondjuk 443), de connection refused a válasz.

Helyi hálón az
ssh -p443 root[kukacz]192.168.1.100
paranccsal működik.

Tehát ugyanez a parancs, csak nyilvános IP-vel már nem megy.

Akkor gondolom ne is próbálgassam a nyitott portokat.
Lehet egyszerűbb lenne a szolgáltatótól kérni egy port forwarding-ot? :P /vajon átkonfigurálja az összes routerét az én kedvemért?/

Egyáltalán ilyen NAT-olt hálón lehet valahogy nyilvános IP-t osztani? Mert ha egyenlő a lehetetlennel, akkor nem is próbálom elérni őket :P (mert a legjobb egy publikus IP lenne, ami az enyém, mindenféle port finomsággal :D)

Amit írtál, elvileg ahhoz is kell legalább egy port, ami kifelé működik gondolom.

Most jutott eszembe, hogy anno a CS 1.6-al játszottunk neten. Bár az UDP-t használ (de lehet, hogy mellette TCP-t is), de valahogy működött. Mondjuk ahogy észrevettem, nekem nem az eléréssel van a bajom, hanem a megosztással. Szóval semmilyen szervert nem tudok üzemeltetni. SSH, FTP, HTTP, stb... kizárva. Még a CS szerver is szerintem :D

Vajon a TeamVIewer /megint csak itt lyukadok ki/ milyen protokollt, portot használ, mert azzal el lehet érni a gépem. Illetve hogy van az, hogy indítok egy FTP szervert, akkor távolról nem tudok csatlakozni hozzá, de ha én csatlakozom egy távolihoz, akkor tudok adatokat küldeni. Szóval ha valahogy úgy meg lehetne oldani, hogy van egy távoli gépem, ez automatikusan csatlakozik hozzá (ahogy te is írtad), mégis arról küldöm a parancsokat ennek. Vagy azon keresztül egy másikról. De ennek.

Remélem ki lehet bogozni amit írtam :D

A publikus IP-n (ami mögé be vagy NAT-olva) felesleges próbálgatnod a portokat, kétlem, hogy bármelyiket is a Te gépedre forwardolnák be.
3 megoldás jut hirtelen az eszembe:
1. kérsz publikus IP-t a szolgáltatódtol
2. reverse ssh tunnel
3. vpn
4. teamviewer és klónjai

Az 1. megoldás valószínűleg pénzes lesz. A 2. megoldáshoz kell egy gép, amit az otthoni (NAT mögötti) gépedről elérsz SSH-n. Amikor "haza akarsz menni", akkor belépsz ugyanarra a gépre és onnan tudsz belépni az otthoni gépedre.
A 3. esetben pedig az otthoni gépedről húzol egy pl. openvpn-t és azon keresztül jutsz vissza a gépedre. Ez a legbonyolultabb megoláds.

Szia

A 3. megoldáshoz is kell másik gép (fix IP cím, amivel kiépíted a VPN tunnelt). Egy esetben nem kell, ha amelyik gépről el akarod érni az otthonit, annak van fix IP címe, de akkor az SSH-hoz sem kell, mert az SSH tunnelt közvetlen ezzel a géppel tudod felépíteni.

Egyébként ne hidd el, hogy bonyolultabb OpenVPN-t használni, mint ssh tunnelt, főleg ha nem csak 1 portot szeretnél elérni az otthoni gépeden, hanem többet is. Ami az OpenVPN mellett szól, hogy stabilabb, mint az OpenSSH, és mindenfajta mágia nélkül újraépül, ha véletlenül leszakadna.

Ami neked esetleg jó lehet, az a LogMeIn vagy a TeamViewer vagy a klónjaik, ahol is a fix IP-s pontokat a szolgáltató biztosítja (magánszemélyeknek ingyen).

Izé, a NAT az "hálózati címfordítás" lenne.

Kb. arról szól, hogy egy publikus IP-ről több gép üzemel privát IP-címekkel.
Publikus IP: amit kívülről el lehet érni
Privát IP: fenntartott tartomány(ok)ból kiosztott címek

Amikor az egyik gép kérést indít (pl. megnézel egy weboldalt), ugyanennek a gépnek kell visszaadni a kérésre érkezett választ is.
Ezt a NAT-oló gépnek kell megoldania, ő fordít a publikus és privát háló között. (NAT/PAT)

Ha te be akarsz jönni kívülről, akkor a publikus címet tudod csak elérni.
Mivel a publikus cím mögött több gép van, alapvetően nincs egyértelmű hozzárendelés (melyiknek is kell küldeni a bejövő kérést).
Persze meg lehet oldani, hogy adott port adott belső IP-re érkezzen be, vagy az összes bejövő kérés egyetlen gépre fusson be, de ezzel molyolni kell és ugyanaz a port két géphez nem osztható ki.

Tehát kifelé tudsz menni a gépről, de bejönni csak akkor, ha el tudod intézni, hogy a publikus IP adott portjához intézett kérést a te géped adott portjára irányítsák.

NAT-olt hálón tehát nem nyilvános IP-t osztanak. Az viszont lehet, hogy a szolgáltatónak lehetősége van publikus IP-t osztani.

Mivel kifelé minden működik, ezért a reverse ssh tunneles megoldás is megy - ez a lényege.
Viszont érdemes átgondolni, hogy ha ezt beállítod, minden adatforgalom, amit kívülről intézel, a közbenső gépen át fog menni - duplán is (ki és be). Ha van rajt adatforgalmi korlát pl. ez gondot jelenthet nagyobb forgalomnál.

( ozs v | 2012. 03. 02., p – 06:20 )

Lehet, hogy en nem ertem teljesen a problemat, de - tobbek kozott - erre talaltak ki a dyndns, no-ip es egyeb szolgaltatokat.

Regisztralsz peldaul egy azengepem.dyndns.org host-ot a dyndns.org-on belul, aztan barmilyen cimet kaphat a tavoli geped, mivel a nevre fogsz hivatkozni kapcsolodaskor. A mostani soho router-ek szinte mindegyike tudja (tenyleg ritka, hogy nem), a kulonbozo op.rendszerekhez pedig letoltheto/telepitheto kliens (ha nem lenne router-ed).

Avagy annyira durvan tobbszoros NAT-olas van? Akkor viszont tenyleg valamilyen "belsoleg" kiepitett csatorna lesz a megoldas.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

Én olvastam amit leírtál ami azt sugallja, hogy ha egyszerű NAT van arra kitalálták a dyndns-t etc. Nos ez itt plusz 2 óra annak aki nem ért hozzá és utána akar menni a kijelentésednek. Nem kell ehhez durva többszörös NAT. Ettől akartam megóvni aki beleszalad az írásodba. Abszolút nem tartozik a témához a dyndns a no-ip és a társai.

Nem a névfeloldás a gondja, hanem az, hogy nincs publikus IP-címe. Tehát küldi a csomagot, a NAT-olós doboz meg tűnődik, melyik lyukán nyomja tovább azt. Aztán, mivel nincs szabálya arra, hogy az adott portra érkezett csomag a belső hálón melyik IP-re menjen, el is dobja iziben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bitvadasz | 2012. 03. 02., p – 06:41 )

A dyndns-en túl:
Ha skype-olsz, akkor az msn portját kell használnod: amelyik be van állítva hallgatózásra. Ezeket be szokták engedni a szolgáltatók.

A dyndns "free" most már $29.95/év - az új klienseknek.
Ez a pillanatnyi középárfolyamon 6500 Ft/év.
kb. 15 liter 95-ös benzint kapsz ennyi pénzért.

( freeoli v | 2012. 03. 02., p – 09:43 )

Hamachi vagy valami egyéb VPN, free vpn.

( Adamyno | 2012. 03. 02., p – 11:32 )

Találtam 2 esetleges lehetőséget...

1. IP over ICMP
2. IP over DNS

1. verzió azért necces, mert az ICMP-t sok helyen blokkoják
2. verzióhoz kell egy saját DNS szeró, de mivel balső hálón vagyok (NAT), így az nem valószínű, hogy működni fog. Még ilyet nem próbáltam.

De szerintem az 1. lehetőséget érdemes megpróbálni :)

( Fisher v | 2012. 03. 02., p – 11:50 )

Mindent meg lehet oldani.

Tehát a probléma az, hogy az elérni vágyott gép tűzfal, nat mögött van. Kívülről tehát nem érhető el. Pont. (Az, hogy másik porton futass ssh-t, és így érd el, nem megoldás, mert ki tudja, hogy milyen proxy, tűzfal van útközben.)

Mivel a géped, amit el akarsz érni, kívülről nem érhető el, ezért belülről kell okoskodni.

Az a géped, amiről el akarod érni a gépedet sose lesz natolva(*)? Ez utóbbi szerintem nem biztos, hogy vállalható, de te tudod.

Ha nem lesz natolva, akkor rém egyszerű a dolog:

- a gépedre szerkesztesz egy dyndns, no-ip, stb. accot
- teszel rá egy szolgáltatást, ami jelzi a távoli gépnek, hogy rá akarsz csatlakozni
- ezt a szolgáltatást a távoli gép percenként vagy óránként, ahogy kényelmesebb, ellenőrzi
- ha kapcsolódási igényt vél felfedezni, akkor nyit egy lyukat: ssh tunnel, vpn, bármi - talán egy OpenVPN lenne a legegyszerűbb és viszonylag biztonságosnak vélem.

Ha mindkét gép nat mögött van, akkor harmadik gépre lesz szükség, amit mindketten elérnek, és úgy mókolni valamit (az OpenVPN itt is barát lehet), de ehhez kell egy harmadik gép vagy szolgáltatás - PC Anywhere (eheh), TeamViewer, Hamachi, miegyéb.

Vagy ahogy írták lehet szórakozni a tor-ral is, nem lesz kábítóan gyors, de még akár működhet is.

*) vagy minimum legalább SSH-n mindig elérhető lesz?

Mondjuk a nat mögötti gépre egy tinc klienst feltenni, aki adott NEVŰ (dyndns pl.) "szerverre" akar csatlakozni. Ha kívánod az elérést, akkor tinc szerver indítása a dns szinkron után, oszt máris jön a tinc-es alháló. :)

Működik, csináltam ilyet számosan, több klienssel, több szerverrel stb. Én szeretni tinc. :DDD

"A lényeg annyi, hogy a kedves ISP-m nem képes nyilvános IP-t adni, végig NAT-ol Budapesttől legalább a Balaton déli partjáig"

"Az a géped(PC-A), amiről el akarod érni a gépedet(PC-B) sose lesz natolva"
De asszem közben egyébként megvilágodtam, csak belezavarodtam, hogy melyik gép hova/hol :) Szal jobban átolvasva nem a NAT-os ISP-s (otthoni) gépre menne a dyndns, ez esetben, így már érthető.

( djsilas | 2012. 03. 02., p – 13:26 )

Mivel otthon szülőknél ugyanez a helyzet, asszem elég [halál]közeli élményekkel szolgálhatok.

Hamachi
Teamviewer
+ 28x NAT ellenére sikerült Sixx IPv6 tunnel belövése is... ha tényleg csak egy SSH kell, akár ez is megfelelhet :P

( tovis v | 2012. 03. 02., p – 13:26 )

Nem tudom, ez hogy tetszik. Ha jól értem, nyilvános hálózatból, ohajtod elérni a távoli, gépedet egy olyan tűzfalon át amit nem tudsz befolyásolni (port forward és egyebek).
Mi lenne ha modemen keresztül vonalas telefonon át érnéd el, vagy némi bütykölés árán GSM és SMS küldéssel "ébresztenéd" fel a gépedet, hogy lépjen veled kapcsolatba a nyílt hálózatban?
Azért az interneten sincsenek csodák nincsenek, te kívülről nem érheted el akkor neki kell téged elérnie, úgy hogy valami módon megadod neki az elérhetőségedet és az igényt.
Aztán pedig jöhet a reverse ssh tunnel - stabil, egyszerű és titkosított megoldás.

* Én egy indián vagyok. Minden indián hazudik.

:D Úgy látom kreativitásból nincs hiány.

Mivel a külső gép mindig másik lesz (tehát bárhol leülök egy gép elé aminek van internet elérése) és arról el akarom érni az otthoni gépet, amin fut az ssh szerver, NAT, tűzfal mögött (amit én nem tudok befolyásolni).

Szóval akkor a leghatékonyabb megoldás ezek szerint a telefon lesz. Felhívom a szolgáltatót, hogy tud-e nekem ajánlani valamit a probléma orvoslására :D

Egyébként az ilyen nevezhető ISP-nek? Nem ezért, hogy kötekedjek... de előfizetni egy 100 megás netre bárki tud 1db nyilvános IP-vel, amit aztán úgy oszt ő NAT mögött ahogy akar, egy alsó közép kategóriás router már tud sávszélességet korlátozni akár ügyfélre lebontva is, lehet MAC cím szűrést végenzni (hogy csak az általam kiszotott végpontok tudjanak csatlakozni; nálunk így van megoldva, titkosítás hírből se létezik). Szóval ha én megosztom oitthon a teszkós routeremmel a netet akkor ISP Leszek? :D

Na ennek a szolgáltatásnak poén a színvonala. Úgy tudom, hogy Magyarországon minden internet előfizetőnek alanyi jogon jár a nyilvános IP, szóval ha nem kapok, akkor lehet igényelni elvileg ingyen. Hogy dinamikus vagy fix... na azért már kérhetnek pénzt.

Ha nem így van, javítsatok ki, de szerintem így lenne értelme, mert amúgy ez nem internet, hanem egy cső, amiben az adatok befelé jönnek, de kifele szinte semmi. Végülis egy nagy intranet, aminek egy pontja a netre van "tákolva" NAT-al :P

Az internet nem tartalomzabálás, hanem adatátvitel. Szerintem. Az nem baj, ha te nem így látod. Nekem konkrétan marhára fontos, hogy az ismerőseim gépét karbantarthassam, és az is, hogy ha hirtelen valakinek oda akarok adni egy file-t, akkor ezt megtehessem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

És ennek miért gátja a NAT? Azért mert megvédi az ismerősödet attól, hogy te kezdeményezd ezt a akart/nem akart karbantartást? A döntést pedig ráhagyja? Az internet adatátvitel. Régen úgy kapcsolódott sok egyetem főiskola hazánkban a hálózatra, hogy volt egy x25 betárcsázás és gopher és kész. A szerver szolgáltatás nem akart és nem hasznos része a felhasználói társadalomnak. E mellett rögtön, ha addig nem volt NAT, maga a felhasználó rak NAT készüléket az internetre (soho router).
Igen, adatátvitel. Pontosan.Ezt nem sérti a NAT. A címezhetőséget sérti. Ami egy gagyi kvázivédelmet is nyújt. Biztos rég volt már mikor a natívan internetre kötött xp átlagosan 21 percig volt vírusmentes...

no flame, de ezzel nem értek egyet.

"A döntést pedig ráhagyja?"

Egy publikus cím megfoszt a választás lehetőségétől?

"Az internet adatátvitel."

Ez egy szolgáltatás, aminek vannak minőségi jellemzői. Az egyik ilyen, hogy mire tudod felhasználni.

"Biztos rég volt már mikor a natívan internetre kötött xp átlagosan 21 percig volt vírusmentes..."

Nem tudom, hogy valóban volt-e ilyen, de kb. 2004 környékén jelent meg az SP2, immáron default bekapcsolt tűzfallal.
Előtte sem volt kötelező szétwarezolni és élből kikapcsolni a frissítést.

Az otthoni soho router annyiban más - ismerőseim többségénél van, egy gép van közvetlenül a neten -, hogy annak adminisztrációja a felhasználó lehetősége, így tud egy adott portot forwardolni a belső hálón adott IP-cím adott portjára. Ha a szolgáltató NAT-ol, ezt nem tudod megtenni. Tehát nem a NAT, mint technológia gátol, hanem az, ha a NAT-olós eszköz adminisztrációját a szolgáltató végzi.

A karbantartás nem akart/nem akart, hiszen így van megbeszélve, nem titokban, nem a gép gazdájának tudta nélkül történik. Mondhatnám, van jobb dolgom is, nem arra csorog a nyálam, hogy írogatom a yum update parancsokat, update-elem a rendszermagot, böngészőt, levelezőt, ha írnak mail-t, hogy valamit nem értenek, válaszolok, jelzem, ha közel televan valamelyik filerendszer, stb.

A szerver szolgáltatás nem akart és nem hasznos része a felhasználói társadalomnak.

Miért? Szerintem meg az autóval közlekedés nem hasznos része a társadalomnak, ugyanis a környezeti terhelés megrövidíti az életünket.

Ami egy gagyi kvázivédelmet is nyújt.

Igen. Az otthoni soho router NAT-ja is. Hagy döntse el a felhasználó, ne a torkán nyomják le kéretlenül.

Biztos rég volt már mikor a natívan internetre kötött xp átlagosan 21 percig volt vírusmentes...

Ez biztos nagyon érdekel a HUP-on, amikor Fedorát tartok karban ssh-n, bekapcsolt tűzfallal, normális jogosultságkezeléssel, bekapcsolt SELinux mellett, up to date oprendszerrel - épp erről beszélünk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( hzsolt94 v | 2012. 03. 02., p – 18:04 )

Tisztán építő jelleggel: Ha megteheted, akkor már csak elvből is ott kell hagyni a NAT-oló "szolgáltatót". Az ilyesmi az nem internet szolgáltatás. Minimum egy hosszas reklamációt megér. És egyébként az ilyen balatoni "volt a józsinak egy routere" szolgáltatóknál szokott a minőség is olyan lenni amilyen.

Annál is inkább nem szabad az ilyet engedni mert ha IPv6 helyett NAT-olgatás lesz, akkor leszünk csak igazán szarban.

Ui: Balaton, NAT, nem Kranet véletlenül? Náluk rosszabbat még nem láttam, menekülj ha tudsz. Sajnos volt szerencsém hozzájuk.

Már az sem derül ki hogy WiFi vagy mikróhullám.

A mikrohullám eleve drága, a sebesség mindig viszonylag alacsony, és csak profik tudják rendesen belőni (rálátás, stb). Igazából csak ott érdemes használni ahol valamiért nem lehet vagy szokatlanul drága kábelezni.

Ha meg WiFi akkor ez bűnözés. 1 km-es lefedettséget milyen barbár ír egy Acces-pointra? (Tudom, nem lehetetlen, de ez nem szolgáltatás hanem játék maximum.)
És egyébként árban is irreális, havi 3000 Ft-ért sokgigás mobilnet csomagot kapsz, ami azért korrektül 1-2 mb, IP címmel stb...

A mikrohullám és a wi-fi között mi a különbség?

Mert én amikor ezt tanultam, akkor mág így tanították: minden wifi mikrohullám, de nem minden mikrohullám wifi.

Magyarul a Wi-Fi technológia elektromágneses hullámokra, annak a mikrohullámú csoportjába sorolható, 2,4 és 5,0GHz-es frekvenciákra ültetett kommunikációs technológia. Egy szabvány.

Mivel pl. a látható fény is elektromágneses hullám (és részecske, de előállítható hullámképző módszerekkel), csak nem mikrohullám. Tehát az egy másik kategória. De nem akarom elmagyarázni, mert olyan pontosan úgysem tudnám mint akinek ez a dolga, szerintem nézz utána wikipédián vagy valami tankönyvbe. Mikrohullám van a "mikróban" is, meg a wifi antennában is. A rádió antennáján josszú, közepes és rövid, illetve ultra rövid hullám van. Ez mind-mind elektromágneses hullám. Mint ahogy a mikrohullám is.

Valóban pontatlan voltam, a mikrohullám alatt arra gondoltam amit irányított antennával fixen felszerelnek, és nem tudok rá egy sima laptoppal csatlakozni az utcáról.
(Ami ugye 2.4/5 Ghz-s is lehet, sőt akár WiFi szabványos, de nekem mégiscsak az a WiFi amire a laptopom/telefonom rákapcsolódik)

Az ilyenen mindig ki voltam akadva:

A Szolgáltató szűri és monitorozza a végpontok szerver üzemeltetési
célokra történő használatát. Ennek értelmében szűri a végpontok következő TCP portjait: 25, 80, 110, 3128, 8080. A Szolgáltató fenntartja magának a jogot, hogy amennyiben az előfizető végpontján szerver jellegű tevékenységet tapasztal, a kérdéses portot az előfizető értesítése mellett a továbbiakban blokkolja.

Ugye azért fizetek elő internetre, mert adatot akarok eljuttatni 'A' pontból 'B' pontba. Ha így nézzük, az ssh kapcsolat is szerver, de elemi igény. Hasonlóan az is, ha azt mondom, itt a gépemen 3 file, töltsd le, s ehhez egy httpd fut nálam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( lebowski71 | 2012. 03. 16., p – 22:41 )

Valamilyen tunnel-t kellene ehhez használni mindenképpen. pl a natolt gépről be kéne vpn-ezni egy publikus ip-n csücsülő vpn szerverre, oszt onnan már menne.
vagy fejleszteni egy a logmein-hez hasonló cuccot.
Esetleg megkérni a rendszergazdit, hogy natoljon már egy tcp portot neked legyen olyan szíves :)

( Adamyno | 2012. 03. 19., h – 19:43 )

Na, most ahogy haladok a CISCO Hálózati Akadémia programmal, folyamatosan tisztul a látóképem elég durván.

Közben csemegéztem kicsit az ÁFSZ-ből:
"Az Internet hozzáférési szolgáltatás alapvető használati célja az el őfizetői végberendezések és a
központi kiszolgáló berendezések közötti kapcsolat létrehozása WiFi alapú WLAN hálózaton
keresztül, és a kapcsolat ideje alatt a szolgáltatások által lehetővé tett protokollok szerinti
adatátvitel megvalósítása, vagyis adat, jel, kép, hang adott címre történő továbbítása az Internet hálózaton."

Hát engem korlátoznak ebben az adat továbbításban, mivel szűrik a forgalmat, holott én erre őket nem kértem. Tudom, hogy aggódnak a biztonságom miatt meg hasonlók, de hadd döntsem el én, hogy magamnak milyen védelmet szeretnék. Ehhez kapcsolódik a következő rész is:

"A szolgáltató üzemelteti a szolgáltatás elérését biztosító WiFi alapú WLAN hálózatot („hálózat”),
továbbá biztosítja az előfizetők részére a szükséges azonosítókat és jelszavakat, amelyek segítségével az előfizető végberendezések a hálózaton keresztül az Internet hálózathoz kapcsolódhatnak."

Ez a gyakorlatban úgy néz ki, hogy egy integrált forgalomirányítót (amiben irányított panel antenna van beépítve, azt hiszem MikroTik) kitesznek a ház falára, ami be van konfigolva és én attól kapom az IP-t (ami C osztályú, nem nyilvános IP). Egy traceroute paranccsal végigkövetve az ugrásokat, az derült ki, hogy az a kinti doboz egy nyilvános IP-vel rendelkező eszközhöz csatlakozik, és azzal az eszközzel egy alhálón van "az én nyilvános IP-m" is, ami statikus. Ezt nem tudom hogy csinálják, de mindegy. Az a lényeg, hogy a wifijükre MAC szűréssel mennek az eszközök. Egyszer megcsináltam, hogy leolvastam a matricáról a MAC címét és szoftveresen manipuláltam egy wifi kártyát ezzel a címmel. Csatlakoztam is a hálózathoz, de az internezetéshez egy felhasználói nevet és jelszót kért a böngészőben a szolgáltató. Amit én nem kaptam meg.

Ha "előfizetői végberendezésnek" számít az a doboz a falon, akkor elvileg az a kód az enyém. Egyszer volt egy balhé, mert valamitől resetelődött vagy elállítódott a router és nem akartak kijönni megnézni, pedig biztos voltam benne, hogy azzal van a baj, mert alapértelmezett jelszóval be tudtam lépni és be is tudtam volna konfigolni, de a jelszó abban van beállítva. Erre az eszközre én Kaukciót fizettem, tehát elvileg ez az én tulajdonom, én tartozom érte anyagi felelősséggel amíg a szerződést fel nem mondom. Ezek alapján pedig mindenféleképpen megillet a szükséges jelszó és felhasználói név.

Extraként annyit megemlítenék még, hogy a kinti "router" (én az ilyeneket tescos routernek szoktam hívni) hozzáférési jelszavát is módosították, így a konfig felületet sem érem el, (magyarul kitiltottak saját eszközömről) és a kapcsolat mindenféle titkosítás nélkül történik, bárki lehallgathatja. Szerintem csak az ismert portok vannak engedélyezve, ezeket jelszavas védelemmel ellátják (amit nemm akpok meg), a többi port tiltva, MAC szűrés van, titkosítás nincs és a saját eszközömhöz nem férek hozzá.

"A rendszer alaphálózata a felhasználói végpontok és az Internet publikus része között nem
tartalmaz forgalomszűrést" ... "Ennek értelmében szűri a végpontok következő TCP portjait: 25, 80, 110,3128, 8080. A Szolgáltató fenntartja magának a jogot, hogy amennyiben az előfizető végpontján
szerver jellegű tevékenységet tapasztal, a kérdéses portot az előfizető értesítése mellett a
továbbiakban blokkolja."

Na akkor most szűri vagy nem? Döntsék már el :P Egyébként meg alapból blokkolva van az összes port, így még csak próbálkozni sem tudok "szerver jellegű tevékynség"-et elkövetni, illetve erről a blokkolásról én semmilyen tájékoztatást soha nem kaptam.

"2.2. Kiegészítő szolgáltatások

A szolgáltató az előfizetők számára az Internet szolgáltatáshoz kapcsolódó kiegészítő
szolgáltatásokat is nyújt.
A következő kiegészítő szolgáltatásokat az Általános Szerződési Feltételek feltételei mellett lehet
igénybe venni:
•E-mail, mail alias, levelezőlista, csoportos e-mail (Mail Relay) szolgáltatások ;
•IP címkiosztás (a RIPE szabályai szerint);
•Statikus Real Audio/Video szolgáltatás és élő Real Audio/Video szolgáltatás;
•Titkosított adatátvitel megvalósítása;
•Egyéb, nem távközlési szolgáltatás. "

•E-mail címet nem kaptam a szolgáltatótól. Ezt nem is kommentálnám tovább.
•RIPE szabályai szerint? Ők elvileg nem szabályozzák a végfelhasználók címzési módját, tehát akkor milyen szabályok alapján is kapom én az IP-t? Ha jól tudom, ők csak vaállalatoknak és ISP-knek osztanak IP-cím tartományokat.
•számomra lényegtelen
•Na erre viszont kíváncsi lennék, hogy hol van titkosítva az adatátvitel és milyen módszerrel...
•aha... szóval ez az ingyenes tűzfal szolgáltatás xD

Szeretem az ilyen kedves, aranyos, gondoskodó és empatikus szolgáltatót. Csak azt nem értem miért önti el az agyamat a vér, nyílik a bicska a zsebemben. Ki ez az Orwellián nagytestvér? Ha nincs elegendő sávszélessége akkor minek száll be a versenybe? Ez az egész arról szól, hogy valójában nagyon korlátozott a sávszélessége, csak ilyen szigorításokkal tudja biztosítani a hozzáférést. Erre miért nincs törvény? Ez egy pompásan számítható mérhető adat, hogy hány fogyasztót lehet kiszolgálni egy adott sávszélességgel.

* Én egy indián vagyok. Minden indián hazudik.

"Az IP címem: 79.172.235.150", "ezek szerint (már) csak a fél falu kapja ugyanazt az IP-t?"
Na most ugye először azt állítod, hogy a 79.172.235.150 a nálad lévő eszköz IP-je, másodszor meg azt, hogy a faluban többeteknek is ugyanez? Hogy is van ez akkor?

"Egy traceroute paranccsal végigkövetve az ugrásokat, az derült ki, hogy az a kinti doboz egy nyilvános IP-vel rendelkező eszközhöz csatlakozik, és azzal az eszközzel egy alhálón van "az én nyilvános IP-m" is, ami statikus."
Tehát a 79.172.235.129 a szolgáltató, a 192.168.15.1 a szolgáltató által nálad elhelyezett router LAN oldala, a 192.168.1.1 pedig a saját routered LAN interfésze, és ezen lóg a géped?
 

"ahogy haladok a CISCO Hálózati Akadémia programmal, folyamatosan tisztul a látóképem elég durván."
Amiket itt felsoroltál, azok szinte egyáltalán nem hálózati témakörrel kapcsolatosak, hanem azzal a szerződéssel, amit aláírtál, illetve amely azóta bekövetkezett módosításait tudomásul vetted. Tehát nem Cisco kell ide, hanem értelmezni az írást.
 

"Kaukciót fizettem, tehát elvileg ez az én tulajdonom"
cautio, kaució... Ezért inkább használd az óvadék vagy biztosíték szót.
Ha megvetted volna, akkor a te saját tulajdonod lenne. De akkor miért fizetnél érte kauciót? (Ld.: V. sz. melléklet)
 

"E-mail címet nem kaptam a szolgáltatótól. Ezt nem is kommentálnám tovább."
Ha te ezt kifejezetten kérted, akkor erre hivatkozva reklamálni kell a szolgáltatónál; ha viszont ezt az igényedet nem nyilvánítottad ki külön, akkor - ahogy a bizonyára olvastad az ÁSZF-ben - nem adnak automatikusan.
Az írás:

2.2. Kiegészítő szolgáltatások
A 3 hónapos kártyás, illetve a határozott, valamint határozatlan időre kötött előfizetés esetén az alapszolgáltatáshoz előfizetői igény alapján kapcsolódhat egy email cím térítésmentes biztosítása az I. számú melléklet feltételei szerint. Az 1 hónapos kártyás előfizetés esetén az előfizető kérésére a szolgáltató térítésmentesen biztosít egy email címet a 3 hónapos kártyás előfizetés esetén irányadó feltételekkel. Az 1 hónapnál rövidebb idejű előfizetés esetén email címet a szolgáltató csak térítés ellenében biztosít, az I. számú melléklet szerinti feltételekkel.


I. számú melléklet: Szolgáltatások leírása
1 hónapos internet hozzáférés – az előfizető kérésére ingyen 1 db e-mail cím
3 hónapos internet hozzáférés – az előfizető kérésére ingyen 1 db e-mail cím

 

"Titkosított adatátvitel megvalósítása"
Ugyanaz a 2.2 pont, mivel ezt is kiegészítő szolgáltatásként adják.
 

"RIPE szabályai szerint? Ők elvileg nem szabályozzák a végfelhasználók címzési módját, tehát akkor milyen szabályok alapján is kapom én az IP-t?"
Feltételezem, hogy itt elsősorban a RIPE-488, RIPE-489 szellemében bekért információkra gondolnak. És igen, egy publikus címtartomány kiosztásának célja van, és szabályozva van.
 

"Először azt írják, hogy nem szűrnek semmit, egy mondattal lejjebb pedig sorolják a szűrt szolgáltatásokat/portokat."
Lehet, hogy szerencsétlen a megfogalmazás, de ha nem szűrnének, te akkor sem üzemeltetnél szervert ezen a hozzáférésen, mivel természetesen be szoktad tartani az általad kötött szerződésben foglaltakat. Ezért ez a probléma téged nem érint, csak azokat, akik mégis megkísérelnék.

"Szóval semmilyen szervert nem tudok üzemeltetni. SSH, FTP, HTTP, stb... kizárva."
Ezt már az ÁSZF elolvasása után a szerződés megkötése előtt is tudhattad. Elolvastad, megértetted, tudomásul vetted, aláírtad.

3.2.1. Műszaki feltételek
A Végfelhasználó WiFi képességgel (IEEE 802.11b, vagy IEEE 802.11a) rendelkező vezeték nélküli hozzáférést biztosító eszközzel (pl. személyi számítógép WiFi kártyával) férhet hozzá a hálózathoz a szolgáltatási területen. A szolgáltatás igénybevételéhez szükséges eszközöket az előfizető kérésére a szolgáltató kaució ellenében biztosítja. A kauciós megállapodást jelen ÁSZF V. sz. melléklete tartalmazza. A végberendezés beszerzését, a programok helyszíni installálását vagy egyéb szakmai támogatást a szolgáltató külön megállapodás alapján vállalja.

3.2.1. Műszaki feltételek
A szolgáltatás egyes típusainak igénybevételéhez szükséges interfészek meghatározását a jelen ÁSZF I. számú melléklete tartalmazza. Az előfizető a szolgáltatás hozzáférési ponthoz kizárólag megfelelőség-tanúsítással és megfelelő interfésszel rendelkező szabványos végberendezést csatlakoztathat.

I. számú melléklet: Szolgáltatások leírása
Router biztosítása nélkül:
fizikai interfész: IEE 802.11b
ethernet: IEE 802.3
enkapszuláció: ethernet II
adatkapcsolati protokol: TCP/IP

Ebből az következik, hogy nem szükséges a szolgáltató routerét igénybe venni, tehetsz rá saját eszközt is.

Tehát ha jól értem, te szolgáltatói menedzselésű routert kértél. A routered külső interfészén publikus IP lehet, különben nem sok értelme lenne a szerverüzemeltetés-tiltás kitételnek. Viszont szerverüzemeltetést bérelt vonalon, fix IP-vel végezhetsz. Elképzelhető, hogy a szolgáltatás vagy a szolgáltató nem tetszik, vagy a szerződés pontjaival nem értesz egyet, de a szerződéskötésre ezek tudatában került sor. Ha ettől el szeretnél térni, vagy módosítani akarsz, elsőként keresd a szolgáltató ügyfélszolgálatát, és kérdezd meg, hogy milyen lehetőségek vannak az igényeid megoldására. Ha a válaszuk részedről nem fogadható, akkor másik szolgáltatót kell keresni.
 

"alapból blokkolva van az összes port, így még csak próbálkozni sem tudok "szerver jellegű tevékynség"-et elkövetni, illetve erről a blokkolásról én semmilyen tájékoztatást soha nem kaptam."
Vélhetőleg eddig nem is kérted a routert üzemeltető szolgáltatótól, hogy a router publikus IP-jének TCP/54321 portját natolják be a 192.168.1.5-ös géped TCP/12345 portjára. A szolgáltató pedig magától nem tudja kitalálni, hogy te X kliensprogramot üzemeltetsz az Y gépeden, és ehhez Z protokoll és port kell neked. De továbbra is kliensjellegű felhasználásról van szó, a szerverüzemeltetést az általad megkötött szerződés tiltja.
 

Ismétlésként még egyszer: beszélj a szolgáltatóval, és tedd fel nekik a kérdéseid. Bár ezt már majdnem három hete igérted, hogy megteszed: "Felhívom a szolgáltatót, hogy tud-e nekem ajánlani valamit a probléma orvoslására". Lett valami eredmény?
 
 
Az eddig elhangzott javaslatokat sikerült már megnézni? Pl. a reverse SSH-ra írtad néhány hete, hogy "No ezt majd holnap kipróbálom...", vagy a tort.

Publikus IP-t adó vezetékes elérés biztos nincs a környéken? Például ADSL (esetleg VDSL) azért elég sok helyen elérhető, ha jól tippelek, Balatonboglár környékéről lenne szó. Az azért nem olyan eldugott hely. Ezzel megoldódna a TeamViewer sávszélességigényével szembeni kifogásod is.
 
Mindenesetre ritkán látni ilyen "rendkívül szép" traceroute-ot, ahol a BIX is 14. hop távolságra van - hozzátéve, hogy ez a szolgáltatás minőségével nem áll szoros összefüggésben.

1. Ez a nyilvános IP-m, ami NAT-olva van, méghozzá port alapú a fordítás, emiatt ugyanezt a nyilvános IP-t fogja kapni az ugyanerre a toronyra csatlakozó másik eszköz(ök) is.

2. Igen, így van.

3. Azért némi hálózati ismeret sem árt hozzá :D (Mivel ez segít az írást értelmezésében) De ettől függetlenül, ahogy végig néztem amit írtál, kiderült, hogy volt ami felett elsiklottam.

4.Oké, ez kiesett, de lényegtelen. Szerencsére nincs szükségem rá. Azért erre jó, hogy felhívtad a figyelmemet, így már pontosak az információim.

5.Na ez viszont érdekes... most így elgondolkodtam rajt, mert én alapból megkövetelném egy szolgáltatótól, de ha ilyen nincs, akkor hát ez van. Viszont arra kiváncsi lennék, ha csak én igényelném ezt a szolgáltatást, akkor azt hogyan valósítanák meg, illetve mennyibe kerülne, mert árat nem írnak. Vajon ingyenes?

6. Ezen utólag még gondolkodtam, érthető, csak nekem valami hiányzik... na mindegy.

7. Az oké, de úgy van megfogalmazva, hogy ha észlelik, akkor előzetes figyelmeztetés után szűrik. Hát engem nem figyelmeztettek soha. Na ez az egyik ami necces, meg ha VPN-t hozok létre és azon "üzemeltetek szervert" akkor az mi? Minek számít? Vagy ha Teamviewerrel megosztom a gépem asztalát és a rajta levő fájlokat. Vagy mondjuk Opera Unite-al (amivel akár streamelni is lehet) Vagy ha torrentezek. Ezek technikailag mind szerver-kliens alapú hálózatok. Akkor ezt miért nem szűrik? A másikat miért? (persze, ezt nem tőled kellene kérdezni)

8. "Ebből az következik, hogy nem szükséges a szolgáltató routerét igénybe venni, tehetsz rá saját eszközt is."

Köszönöm, hogy erre felhívtad a figyelmem! Mivel én nem kértem tőlük semmilyen eszközt, csak rám erőltették. Így akkor ez egy jó alap lehet nekem. Ha saját eszközöm van, akkor azt ugye én magam konfigolom. Ha tőlük bérlem, akkor is használatra bérlem, nem nézegetni. Ebbe a használatba a konfiguráció is beletartozik, illetve akkor már van alapom elkérni a felhasználónév/jelszó párost is, mert eddig azt sem kaptam meg. MAC szűrést meg vagy kinyomják, vagy megmondom nekik az eszközöm címét és felvesznek.

---

Na így mindenből levonva a következtetést, első lépés szerintem akkor az lesz, hogy beszélek a szolgáltatóval.

-elmondom neki mik a szükségleteim
-ő elmondja lehet-e orvosolni, ha lehet akkor hogyan (és mennyiért)
-ha sokallom akkor búcsúzunk egymástól...

Egyébként van másik szolgáltató mostmár, ADSL. Csak egy 5Mbit-es csomagjuk van, de hasonló áron. Az viszont tökéletes mindenre amire kéne, attól eltekintve, hogy dinamikus a nyilvános IP-m. És ha jól tudom, akkor 24 óránként is automatikusan frissül. Elvileg van régi dyndns regisztrációm, szóval még ingyen használhatnám. No majd ennek is utánajárok.

Köszi az észrevételeket, kicsit átrendezte az adatokat a fejemben :D

( Adamyno | 2012. 03. 20., k – 21:23 )

luser@pt-desktop ~ $ traceroute www.google.com

traceroute to www.google.com (74.125.232.243), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.256 ms 1.240 ms 1.227 ms
2 192.168.15.1 (192.168.15.1) 3.188 ms 3.193 ms 3.180 ms
3 79.172.235.129 (79.172.235.129) 10.140 ms 11.131 ms 11.126 ms
4 10.1.18.1 (10.1.18.1) 12.096 ms 12.095 ms 13.072 ms
5 10.1.17.1 (10.1.17.1) 14.056 ms 15.032 ms 16.013 ms
6 10.1.61.1 (10.1.61.1) 16.996 ms 11.934 ms 12.858 ms
7 10.1.13.10 (10.1.13.10) 13.839 ms 10.699 ms 13.656 ms
8 winettou-gw.wla.hu (84.21.22.50) 16.631 ms 17.614 ms 18.598 ms
9 87.229.27.58 (87.229.27.58) 18.587 ms 19.569 ms 19.559 ms
10 87.229.29.62 (87.229.29.62) 20.537 ms 20.527 ms 21.507 ms
11 84.21.25.30 (84.21.25.30) 24.491 ms 24.482 ms 26.636 ms
12 87.229.29.134 (87.229.29.134) 29.608 ms 29.612 ms 12.523 ms
13 87.229.29.106 (87.229.29.106) 20.467 ms 28.459 ms 29.439 ms
14 bix.wla.hu (217.113.61.41) 43.413 ms 43.414 ms 44.380 ms
15 193.188.137.163 (193.188.137.163) 44.369 ms 45.354 ms 46.333 ms
16 209.85.243.119 (209.85.243.119) 46.321 ms 47.303 ms 48.286 ms
17 216.239.46.50 (216.239.46.50) 15.478 ms 17.459 ms 17.430 ms
18 bud01s09-in-f19.1e100.net (74.125.232.243) 43.740 ms 41.709 ms 47.692 ms

Az IP címem: 79.172.235.150 /már hónapok óta ez van, ahogy emlékszem rá.../
Szerintem ez a traceroute listám alapján valahogy a 3. állomással lehet összefüggésben, ami azt jelenti, hogy a legelső torony amire csatlakozom. Akkor ezek szerint (már) csak a fél falu kapja ugyanazt az IP-t? :D

ez..lehetséges, hogy a harmadik hop után újból privát címtartomány újabb 4 ugrásig és csak utána ér el a winettou-gw -re? mi értelme egy public címet bekeverni a privát hálózat rútingjába? tudom, hogy lehet nekik ez a cím is "belháló", na de mégis.. ráadásul, ilyen rúting, ahol 8 ugrás csak a saját háló, szörnyű

--
"'The time has come,' the Walrus said"

Valahogy megcsinálták a nyilvános címet a hozzáférési pontomig. Nem tudom hogyan, de ki kéne próbálni hogyan működik. Elvileg van ilyen ingyenes próba 2 percig azt hiszem. Rácsatlakozok majd notival és kipróbálom, hogy mit enged át. Ha ugyanilyen sz@r lesz, akkor a tőlük kapott router konfigurációja felejtős :P

Nézd meg alaposan az ÁSZF-et/szerződést, abban ott kell (kéne) lenni, hogy "meddig tart" a szolgáltatói rész. Ha a szerződésedhez a szolgáltató biztosít általa felügyelt eszközt, amire a te végberendezésed csatlakozhat, akkor jó esély van arra, hogy a szolgáltatás átadási pontja mint minden rendes esetben a szolgáltató eszközének ügyfél felőli csatlakozója, illetve ha vezeték nélküli csatlakozással kapcsolódsz, akkor a vezeték nélküli hozzáférés.