T-Home NAT-ol?

 ( djpety | 2013. október 8., kedd - 11:56 )

Mai napon érdekes jelenséggel szembesültem. Adott egy ADSL kapcsolat, T-Home által adott Pirelli/ADB eszközzel. Gateway 10.x.x.x-es tartományból, IP cím 100.x.x.x-es tartományból, külsőleg meg egy 31.46.x.x-es tartományból.

Be kellett volna állítani a portforwardot a routeren, de jelzi a kolléga, hogy mást mutat a "whatismyip.com", mint amit a router ír. Ekkor lett gyanús, megnéztem mit is ír a router, és mit ír kívül. Megnéztem a belső IP egy privát tartomány, a külső pedig így néz ki: "T-Home, NAT clients (dynamic address pool)"

RIPE.net 31.46.248.0-31.46.255.255

Tapasztalt valaki ilyet, vagy bővebb infó erről esetleg van?


Update: Telefonon felhívva a Telekomot mondták, hogy megoldják a gondot, azóta láss csodát rendes publikus IP-t oszt az ADSL-es PPPoE kapcsolódáskor.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem csodálkoznék rajta! 2-3 hónapja katasztrofális a netjük (Kecskemét belváros). Magas pingek, loss, choke....ami kell minden van. Sok sz*jb*v*rt IP TV miatt este használhatatlan, tegnap este pl stream nézés is szaggatott...pedig savszél megvan...
Nagyon közel állok hozza hogy otthagyjam őket, pedig mindig megy a nyelvcsapdosás pl ha cc-vel beszélek, hogy "húúú maga 1998 óta internet előfizetőnk!".....

Hazaérek meg is nezem enyém is NAT-os ip cím e.

nem támasztom alá (legalábbis smokeping grafikon -külföldről-) teljesen mást mutat. helyszín azonos.

Az viszont igaz, h 120/50-es GPON esetén csak olyan CPE-t tudnak adni, ami NAT-ol. állítólag nem létezik olyan ami bridge-el. Mivel DMZ-be is tehetem a routerem, így kb mindegy.

Megnéztem itthon nem NAT-os ipm van.

Lehet, hogy csak nekem kusza, amit írsz, de pl. az 'IP cím 100.x.x.x-es', az minek a címe?

Azt az ADSL eszköznek osztja ki, míg a külső publikus IP a 31.x.x.x-es. Tehát egy privát IP-t oszt az eszköz felé.

Biztos, hogy 100.x.x.x -et kap netes külső lábra (nem kevertek bele véletlenül valami egyéb, pl. voip-os tartományt?) és ez miért privát ip?

Biztosan azt kapott, nem VOIP-es, simán a PPPoE kapcsolódáskor, az ADSL kapcsolatnál ilyen tartományból kapott: http://whois.arin.net/rest/nets;q=100.97.99.78?showDetails=true&showARIN=false&ext=netref2

Kívülről pedig ez a "NAT Clients" tartomány jött. Telefonált kolléga a Telekomnak, azt mondták megoldják és azóta jó is, már rendes publikus IP-t kap. Szóval itt biztosan megy az IP-vel a spórolás.

ok, thx.

-- deleted --

Gondolkoztam bedobjam-e, de azt hitem, hogy mindenki megkapta. Ezek szerint valakinek új:

KEDVES ÜGYFELÜNK!
Ezúton szeretnénk tájékoztatni, hogy műszaki fejlesztésünk eredményeként 2013. szeptember 30-ai hatállyal Önnek, még biztonságosabb internet hozzáférést biztosítunk.
Ez azt jelenti, hogy a publikus IP címe helyett privát IP címmel használhatja tovább hálózatunkat.

A privát IP cím előnye, hogy sokkal biztonságosabban internetezhet számítógépén.
Ugyanakkor szeretnénk felhívni figyelmét, hogy a privát IP címet használó számítógépek éppen a nagyobb védettség érdekében, biztonsági okokból semmiféle olyan alkalmazást nem használhatnak, amik a számítógépet „szerver” (kiszolgáló) szerepben igénylik.

Az átállással kapcsolatban Önnek további teendője nincsen!

Amennyiben mégsem kívánja a jövőben előfizetését privát IP címmel használni, kérjük, hívja ügyfélszolgálatunkat a Magyar Telekom hálózatából díjmentes 1412-es telefonszámon, vagy jelezze igényét a

e-mail címen MT azonosítójának vagy az internet szolgáltatás használatához szükséges bejelentkezési azonosítójának megadásával és ingyenesen visszaállítjuk jelenlegi publikus IP címét.

Reméljük a jövőben is elégedett lesz szolgáltatásunkkal!

Üdvözlettel:
Magyar Telekom Nyrt.

Budapest, 2013. szeptember

A privát IP cím előnye, hogy sokkal biztonságosabban internetezhet számítógépén.

Aham. Ez így sok volt reggel.

Hát nem semmi, ahogy előadják...

Eddig csak a kispiricsif0staligabéték falusiwifi szolgáltatás volt nat mögött, de úgy látszik a tré sem akar lemaradni mögöttük...
A "biztonságosabban"-ból max. annyi igaz, hogy a natolt tartományon kívülről közvetlenül nem támadható az illető gépe, de... Szóval pár brossúrával le vannak maradva - a direkt támadás szerintem arányaiban jóval kevesebb, mint a felhasználó aktív közreműködésével (preparált weboldal/levél) települő kártékony trutymók veszélye - az meg ki fog látni a naton keresztül, illetve a nat mögötti gépeket már jól be tudja támadni.

értsd: elfogyott az IPv4, 6to4 fordítás még nem tökéletes. Azon userek akiknek tényleg szükségük van a valós címre, majd szólnak.

:-)

Nyílván :) Mivel otthonról megy némi motyó, hamar meg is igényeltük. 1 napra rá jelezték, hogy rögzítve a publikus ip-m.
Szóval korrektek. Aki meg nem érti, annak úgy is mindegy. Otthoni böngészésre tényleg elég a NAT-olt net.
Irónia: Az más kérdés, ha kibannoltatja magát valahonnan, akkor fél megye szív?:)

Idézet:
Irónia: Az más kérdés, ha kibannoltatja magát valahonnan, akkor fél megye szív?:)

Ez eddig is igy volt a dynamic pool-ozas miatt.

Igen, csak nem egyszerre...

azert ezt elkepzelem a regi teveklubbos IRC-s idokkel elegyitve, bannolnak valakit, masnapi BLikk focim : "Jasz-Nagykun-Szolnok megye utan BAZ megyeben is meghalnak a tevek" "Mar csak Budapesten es Zala magyeben lehet IRCelni"

Szép folyamatosan mindenkit tesznek át NAT mögé, aki nem szól, vagy ez kikre vonatkozik? Kábeles T-Home szolgáltatáson egyelőre publikus IP-nk van /21-es maszkkal. Várjam, amíg egyszer csak azt tapasztalom, nem megy az ssh, http befelé, vagy érdemes szólni már most, vagy ez csak az előfizetők egy csoportjára - pl. szőke kékszeműek - vonatkozik?


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

Passz. Nálam telefon vonalon működő ADSL van, szolgáltatáshoz adott @t-online.hu mailben jött.

Jó, köszönöm, akkor majd kiderül. Vagy írhatnék nekik mailt, ha nem lennék lusta. :)


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

Egyelőre vezetékesen csak az ADSL.
Alacsony a vissza irány , így kevesen használják kiajánlott tartalmakra.
Idő kérdése és a VDSL-re is sor kerül.
Egyébként akit érintett azt értesítették.

Miért ezt csinálják, s miért nem inkább IPv6-ot?


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

IPv6 is van, párhuzamosan

És hány soho/home eszköz (router, hálózati nyomtató, nas), illetve mobilkészülék tudja használni natívan az ipv6-ot bekapcs-next-next-finish módon?

Nagyon sok tartalom nem érhető el IPv6-on.
A transzláció teljes hálózati szinten nagyon drága ,és ha már átálltál akkor ez egy hasztalan beruházás lenne.
Van mellette IPv6 is.
Első körben a mobil telefonok , kerültek NAT mögé.
Ez egy egyensúlyozás , míg az összes tartalom szolgáltató át nem áll.

Ha tippelhetek, akkor a 6to4 transzláció még mindíg olcsóbb mint az IPv4 cím. (mivel utóbbi elfogyott)

Van azért még a szolgáltatóknál , csak most már spórolni kell vele.

igen, és van ahol nincs, máris küldözgetik a leveleket, hogy van-e valakinek eladó...

Miért , neked van ?

szabad blokk van, eladó kevésbé.

De nem olcsóbb mint a Carrier-Grade NAT, amit bevezettek.

http://www.tolaris.com/2013/08/01/ipv4-space-resale-and-so-it-begins/
----------
[GB ≠ GiB] [MB ≠ MiB] [kB ≠ kiB] [1000 ≠ 1024] [Giga ≠ gram] [Mega ≠ milli] [Kelvin ≠ kilo] [Byte ≠ bit]

Nálam ADSL van, még egyelőre semmi jele a 10-es NAT-nak.

Megj, ha ad absurdum lenne egy SIP tel. kliensem, akkor a NAT révén az gondolom hívhatatlan lenne, nemde ? (Meg talán a skype is ? Sajna annak nem ismerem a belsejét.)
Egy IP tel. klienst pedig nem illik szervernek minősíteni, még ha protokoll szinten az is, mivel figyel egy TCP porton.

Ugyanez sshd-vel. Protokoll szinten szerver az, de a célja nem boldog-boldogtalan kiszolgálása nagy mennyiségű adattal, hanem a gép távoli karbantartása, elérése. Én talán egy hete vesztettem el így egy gépet, s nem tudom, én zártam-e ki magam, vagy NAT mögé tették. El kell menjek a helyszínre, csak még nem volt rá időm. :(


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

Én beállítottam a routert, hogy dyndns-ben regisztráljon, mikor kapcsolódik az ADSL-hez. Ilyen esetben nslookup-pal távolról ellenőrizhető, hogy publikus címet kapott-e a router. (Gondolom, a regisztrációs protokoll átmegy a NAT-on is.)

(Aztán a dolog ott van limitálva, hogy pl. a TPlink router csak néhány dyndns szolgáltatót támogat, pl. dydns meg no-ip, és sajna a free változatban mindegyik havonta megerősítős lett mostanság, de hát ez ugye csak a mezitlábas ingyen user problémája. Vagyis az enyém :))

a regisztrációs protokoll HTTP, az táncsak átmegy...

a havonta megerõsítõs dologra meg csinálj egy beCURLozós crontabot, mit én :D

~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1

Már 12 éve is úgy állítottam be ezeket a DSL/dialup/KTV/stb-n lógó gépeket, hogy ők "jelentkezzenek" be hozzám, nem pedig fordítva.
Volt olyan gép, ami megjárta szinte az összes nagyobb ISP-t, de nekem sosem kellett feltennem azt a kérdést senkinek, hogy mi az IP címe.
Az egyik még mindig próbálkozik, de már ki van tiltva. :)
--
zsebHUP-ot használok!

Es melyik az a program amelyik *megbizhatoan* mukodik fel-egy ev utan is? Win+linux

linuxnal a sima wget mukodik cronbol, kb igy:
wget -O /dev/null -q "http://www.myserver.hu/updateip/username";

winnel nemtom hogy mit erdemes.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Megfelelő beállításokkal simán működik a SIP NAT-olt hálózaton (feltéve, hogy a SIP conntrack is jól működik), viszont belső telefonközpont külső, közvetlen elérése problémás lesz.
Skype-hívás szintén működik NAT mögött.

Tehát önmagában ettől még nem lesz hívhatatlan egyik sem.

Ellenben a távoli ssh-elérés, amiről szó esett, nem kellene, hogy luxus kategóriába essen.
Persze lehet ahhoz is reverse tunnelt létrehozni, de azért ez elég csúnya kényszermegoldásnak...

Másfelől, ha az ember saját adatait el szeretné érni távolról (ergo kiszolgálni), az ugyan szerver jellegű szolgáltatásként fut, mégsem feltétlenül szerver hétköznapi értelemben... és ettől még jogos igény lehet.
(Tudom, "cloud", de oda nem biztos, hogy mindennek fel kell kerülnie - mármint idegen kezekbe...)

Saját adat vs. cloud...


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

Mármint azt szándékoztam írni, hogy saját adataim nem adnám egy divatos néven cloud-ként emlegetett szolgáltató/szolgáltatás kezébe, ahogy azt sokan elképzelik...

"Szép folyamatosan mindenkit tesznek át NAT mögé, "

Most, hog X év után a mobilnetezők végre publikus címet kapnak..

jajj - sub!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Tényleg szükség van JS eval-ra az e-mail címeken? Feltételezem a drupal műve és a Snort-nak nem tetszik.
Egy write(decode('asd')) bőven elég lenne...

Elküldtem nekik a bejelentkezési azonosítókat amikkel gondok voltak, erre kaptam egy ilyen levelet:

"A megkeresése MT azonosítók nélkül érkezett, így az előfizetéseket nem tudtuk beazonosítani.

Amennyiben megszeretné tartani ügyfelei publikus IP címeit, kérjük, hogy válaszlevelében küldje el nekünk MT azonosítókat vagy az internet szolgáltatáshoz használat bejelentkezési azonosítókat."

Amiben újra azt írják, hogy küldjem el az azonosítókat, VAGY az MT azonosíkat. Persze az MT azonosítókkal együtt.
Na ebből a logikai katyvaszból menjen ki valaki.
Első körben pppoe azonosítókkal megoldották a dolgot. Ez nekem inkább már szőrszálhasogatásnak tűnik.

A felhasználók döntő többségének igazából ez nem is probléma...
Ami érdekesebb, hogy szerveroldalon az ipszűrés/ip alapu ban kb. felejtős...

Dehogy felejtős... /valami a nat-os tartományra, oszt' jónapot... :-P

http://forum.t-home.hu/mvnforum/viewthread_thread,13786

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

Most az komoly, hogy a T-Home álláspontja az, hogy ha meg tudsz nézni egy weblapot, akkor internetet szolgáltat? Mert gondolom, internet elérésre fizettél elő, nem pedig az index.hu olvasgatására...


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

Nem mindegy hogy pontosan mi van a szerződésben. Régen volt olyan szolgáltató, aki kikötötte, hogy nem futtathatsz szerver jellegű dolgokat. Nem tudom hogy mostanában mi a helyzet, illetve hogy ki mit írt alá.

Ha hamar megtalálom az UPC szerződést, akkor megnézem, hogy én mit :D

Én azt, hogy publikus IP-t kapok, de szerverszolgáltatásra nincs lehetőség.

Jó, csak eléggé egyoldalú ez így. Nincs valódi verseny, mert az efféle dolgokat jellemzően az összes szolgáltató beleírja. Az összes bank, az összes közműcég, az összes teló cég szerződése hasonló. Úgy értem, szektoronként hasonló. Szerintem az lenne a valóban jogállami helyzet, ha én is írhatnék egy szerződés tervezetet, s reális esélyem lenne arra, hogy azt a szolgáltató el is fogadja, legalább is közelítjük az álláspontjainkat, s kialakul egy mindkét fél számára kedvező állapot.

Mert nem akarok szervert üzemeltetni a gépemen abban az értelemben, hogy sok kliens felé nem akarok sok adatot kiszolgálni. Ugyanakkor az a legtermészetesebb dolog szerintem, hogy ssh-n el tudjam érni a gépemet, vagy például sörözésről készűlt képeket mondjuk 10-15 kollégám le tudjon tölteni a gépemről. Hasonlóképpen szükségem van arra, hogy b2bua-t futtassak, s két gép között esetleg VoIP kapcsolatot építsek fel. SIP, RTP, ilyesmi.

Netkapcsolat kell, nem kattintgatós TV-nek akarom használni a gépemet.


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

Annak idején olvastam. Jellemzően ez is csak véletlen, ha úgy tetszik, tévedés, s nem gyakorlat.


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

A zembereknek (sic!) kattintgatós tévé kell. Ha a mainstream-től eltérő igényeid vannak, akkor oldd meg vagy fizess. Vagy lásd be, hogy a szolgáltatónak nem éri meg az egyéni problémákkal foglalkoznia.

A másik oldala a dolognak, hogy a szolgáltatók igyekszenek mindenből pénzt csinálni, de ez meg a tulajdonosok érdeke, a piac idővel beáll egy normális állapotra.

Remélem, nem eszik ilyen forrón a kását!


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

És lassan eljutunk odáig, hogy az internet előfizetés nem lesz más, mint hogy le tudsz tölteni weblapokat...

2004 óta IPv4 NAT mögött "élek", azért ez még messze van ettől.

--
zsebHUP-ot használok!

Ha te managelheted az eszközt, oldhatod meg a portforward-ot, akkor nincs baj. Gond akkor van, ha a szolgáltató által managelt NAT mögött vagy, s el akarod érni kívülről a géped.


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

Akkor VPN. Kulon elony, hogy jol el is rejti, hogy kis is vagy.

Érdekel a megvalósítás mikéntje. Nem használok VPN-t, nem ismerem a technológiát, így nem tudom elképzelni, hogyan szédeleg oda a NAT-olt hálózatba kívülről az adatcsomag akkor, ha nincs portforward.


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

Egy felépített kapcsolat kétirányú is lehet. A NAT gondoskodik róla, hogy egy random magas portot egy adott belső IP címhez köt a session idejére, ha ezt kezdeményezi valami. Természetesen a VPN szervernek kell egy publikus IP cím, bár megoldható NAT-NAT tunnel is, ha van egy 3. fél a kapcsolat felállításához. Innentől pedig van egy virtuális belső hálózatod, ami vagy egy egyszerű IP (protokoll) tunnel vagy egy ethernet bridge.
@see OpenVPN

Ha jól értelek, az a helyzet, hogy közvetlenül nem lehet megcsinálni, mert kell egy 3., publikusan elérhető fél. Úgy könnyű, ha csak az egyik fél van NAT mögött, s ez a fél kezdeményezi a kapcsolat felépítését. Ilyen otthoni viszonyok között viszont éppen az a probléma azzal, ha a szolgáltató NAT-ol, hogy a NAT mögötti gép elérhetetlenné válik. Nekem erre szükségem van, mert ismerősök gépét ssh eléréssel szoktam karbantartani. Igaz, eddig senkit sem zavartak NAT mögé, de van, akinek ADSL-je van T-Online hálózaton - a szolgáltató GTS Datanet -, az ő esetében aggódom, nehogy elbújtassák.


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

Elég ha van egy nem NAT-olt géped, ahova felrakhatsz egy VPN szervert és az ismerőseid gépén beállítod a VPN klienseket. Akár a kliensek egymással is kommunikálhatnak, ha úgy állítod be. [Howto]
Ha nem fix IP címed van, akkor kelleni fog egy dinamikus DNS szolgáltatás is. (dyndns, no-ip, stb)

Idézet:
megoldható NAT-NAT tunnel is, ha van egy 3. fél a kapcsolat felállításához

sõt nagyon elvetemült hálózati trükkel az se szükséges hogy a 3. fél egy hálózati végpont legyen, hanem magát a layer 3-as közeget lehet használni a két NAT összekötésére!

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

Nice! Ha jól látom ő az, aki mókás előadást tartott egy irányított támadásról valamelyik DEF CON-on, ahol az alap PHP session kezelést támadta, illetve javascripttel otthoni routert. Ez már nagyon mélyvíz. :)

"megoldható NAT-NAT tunnel is, ha van egy 3. fél a kapcsolat felállításához"

Ehhez van bevált leírásod?
Pont ez kellene most nekem. Van egy 3. félnek számító fix IP-s hely (VPS), amin keresztül 2 hálózatot kellene összekötni. Több kört futottam már vele, de szerintem valahol a route-nál csúszhattam el.

Ajánlom a pFsense-t (http://www.pfsense.org/) routernek.

Ezzel keztük (na jó, monowall-al) - utána miktotik - majd vissza a pFsense.
---
Repeat after me: I Will Use Google Before Asking Stupid Questions...

Mit szeretnél? Azt ha a két kliens (IP-cím és portcsere után) összecsatlakozna, vagy ha átmenne a forgalom a 3. félen?
Egyébként vannak elvetemült megoldások pwnat volt feljebb, de álljon itt a chownat is (http://samy.pl/chownat/) Ezt az eljárást egyébként nem csak network-hack-re használják, hanem pl a skype server is kapcsol össze így NAT-NAT klienseket.

Idocsapdaba kerultel? :D

szerverszolgáltatásra nincs lehetőség

Persze, mert nem akkora a sávszélesség, és dinamikus IP-címet kapsz. Viszont ami ezen kényelmetlenségbe belefér, azt lehessen már.


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

Nem szervert akarok üzemeltetni, hanem azt várom el, hogy egy korrekten összerakott SYN csomag eltaláljon a gépemhez :-P

Nos, ebbe a kényelmetlenségbe sok minden belefér. Pl. fog működni a hamachi meg a skype meg egy rakat dolog. Viszont alighanem nem működik pár játék, olyanok, amelyek egy-egy klienst választanak ki szervernek, ők ugye kaphatnak továbbra is publikus IP-t. Gyanítom, hogy az előfizetők bő felének fel se tűnt a címváltás, a maradékot meg visszarakják a publikus tartományba.

A linken ugye az alapvető probléma az volt, hogy nem is volt netje, csak IPTV-je, ezért nem meglepő, hogy privát tartományból kapott címet. Május óta nincs rá egyéb reagálás, gyanítom, hogy megoldódott neki, esetleg csak várni kellett egy kicsit. Bár ha az ottani bandie91 az itteni bandie91, akkor nyilatkozhatna :D

Azt teljesen korrekt dolognak érzem, ha a szolgáltató publikus IP-t ad azoknak, akiknek ez fontos, kérik ezt, s NAT mögé bújtatják azokat, akiknek mindegy, s azt sem tudják, miről van szó. Sőt, ez utóbbiaknak lehet, valóban jobb, ha nem közvetlenül érhető el kívülről a gépük.

Problémát akkor érzek, ha a szolgáltató erőből kommunikál, cselekszik.


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

>amelyek egy-egy klienst választanak ki szervernek
>Torchlight 2 Strict NAT detected error otthol, másutt OK
Na bazz, még ha lassan is, de kezd már összeállni a kép, hogy miért is szopok ezzel vagy egy éve...

>Régen volt olyan szolgáltató, aki kikötötte, hogy nem futtathatsz szerver jellegű dolgokat.
Szegény Xserver... =(
Most szedhetem le a GUI-t.

--
[ feliratkozás ]

Valami nagy csalafintaság van a dologban, ugyanis ha dmz-t állítok, a router publikus címen elérem a szolgáltatásaimat, de ha traceroutolok kifelé akkor az első hop egy ismeretlen privát ipcím :O

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

nem láttál még privát tartományon keresztül routeolt public címkiosztást? :P
--
>'The time has come,' the Walrus said<

Szép... De azért szarakodnak még a v6-tal... Nevetséges.
"Hálistennek" egyik új ügyfélnél T-s net és telefon lesz. Nem tudtam mi hiányzott... Örültem hogy végre mindenhol megszabadultam tőle. Volt ahol ezt 2 évig kellett mondogatni a vezetésnek.
--
The Community ENTerprise Operating System

Nekem még megvan a publikus IP címem - kár, hogy a kis routert nem tehetem transzparnes módba, mert akkor repül az IPTV stream. Bár DMZ állítással valamelyest használható a dolog - de azért így is vannak problémák: pl. ha egy kapcsolaton 5 percig nincs forgalom, akkor az automatikusan eldobódik a kis eszközön. :-|
Ellenben határozottan gondolkodom azon, hogy akkor legyen IPv6 címem is, így ha mást nem, akkor azon elérhetem a masinámat. Na de a nagy fene átállás keretén belül a kis router nem beszélni IPv6! Persze, tunelezzünk. Csak ezzel meg pont az elhagyni kívánt IPv4 felé kell megint visszalépni.

ha egy kapcsolaton 5 percig nincs forgalom, akkor az automatikusan eldobódik a kis eszközön

Ez milyen kapcsolat? Ssh? Mert NAT mögött ssh-nál természetes, a daemon szokta a kapcsolatot fenntartani, úgy emlékszem. Éppen ezért nekem a ~/.ssh/config file-ban van egy ilyen:

ServerAliveInterval 20

Ez már a kliensnek szól.


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

Idézet:
nem tehetem transzparnes módba, mert akkor repül az IPTV

+1

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

Nem szorosan csatlakozik a témához, de érdekesség képpen múltkor a T-s mobil netemre kaptam egy x.x.x.0 -s IP címet :) Egy pöttyet meglepődtem :P

/25 vagy rövidebb maszkkal teljesen normális cím

~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1

23?

Na ez inkább...

igen, inkább ez :)
Sőt, talán még más megfejtés is lenne rá - de egyszerűen csak meglepő volt, azért ilyet nem minden nap lát az ember ;)

ja de igazad van
másik irányba számoltam :)

~~~~~~~~
Linux 3.2.0-4-486
Debian 7.1

Én is láttam már ilyet, de nem mobil nettel.


Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

31.46.x.x tartományból kapok címet, ha nem a régi gép mac címével kapcsolódom. A kisebb csomagnál a modem mögé kötött gép kapta közvetlenül, most a nagy csomagnál modem-router eszköz kapja. Persze ez a d-link dcm-704 natot csinál, hisz router is egyben, de gyakorlatilag teljesen a felhasználó által kontrollálható. Egy nagy hibája van, hogy a dhcp cím kiosztásnál nem lehet fix címet hozzárendelni eszközökhöz, ami miatt bizonytalan lenne a port átirányítás például egy áramszünet után megváltozó kiosztás miatt. A manual szerint a fix címet a hálózaton lévő eszközön kéne megadni és nem a routeren. No sebaj, a régi openwrt rendszerű routerem lett a dhcp szerver, persze az átjáró és a dns címek megfelelően beállítva rajta. Btw a router felületén, nem megszokott helyen van egy bridge kapcsoló, de ismeretlen módra vált át, úgy leszakad a netről és csak a ráirt mac címet a számítógépnek megadva lehet vele kommunikálni, belső nem netes ip tartományból oszt címet.

A manual szerint a fix címet a hálózaton lévő eszközön kéne megadni és nem a routeren.

És ezzel mi a probléma? Éppen így csinálom.


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

Sokkal kényelmesebb egy központi helyen, a dhcp szerveren címet rendelni a mac-ekhez, hiszen a port átirányítást is ott szabályozhatom. Szeretem, ha a különböző eszközeim mindig ugyanazt a címet használják. Azok is amelyeken nem triviális megadni az, például telefon. Ha cserélgetem a kártyákat a raspi-kben akkor is a hardverhez rendelt címet kapja, nem pedig a kártyán lévő beállítás szerintit. Ez alapszolgáltatás az olcsó tplink routereknél gyári szoftverrel is. Sőt az egyszerűbb dlinkeknél is. Úgy látszik a komolyabb eszközeiknél használnak csak fapados megoldást.

Nem akarok uj temat kezdeni de 1-2 oraja kerult be egy apache log-ba (ami csak es kizarolag a 157.181.x.x/26-os neten log rajta), hogy:

10.10.20.108 - - [25/Nov/2013:09:45:38 +0100] "GET / HTTP/1.1" 200 13147 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0"

(stbstb, egy teljesen szabalyos oldalletoltes, semmi extra).

Szokasos kerdes: ezt igy hogy? Lehet ko"ze ehhez a t-home natola'shoz?

Persze. Simán lehet, hogy ami T->T irányba megy forgalom, azt a privát címet nem is natolják publikus címre...
--
The Community ENTerprise Operating System

jaja, kozben kiderult hogy valiban ez, csak T -> T helyett elte -> elte ;] csak vmiert ez a forumte'ma ugrott be mikor lattam a logban hogy ize...

Helló!

Azt tudja valaki, hogy a Telenor típusu mobilinternet NAT mögött van, vagy sem? (beszerzés tervezve, külső elérhetőség MUST)

Publikus IP-ket kapok. Azt viszont észrevettem, hogy nem mindegy, hogy APN-ként "net" vagy "online" van beállítva. Az előbbivel nincs probléma, az utóbbinál sokszor probléma van a GRE csomagokkal. Ami PPTP-nél viszont szívás.

--
trey @ gépház

Tökéletes. Köszönöm.

Helyesbítek: "net"-nél kapsz publikus IP-t, "online"-nál NAT-oltat. Most próbáltam ki, hogy ezt olvastam. :)

Na a szívás engem is utolért. Ismerősöm UPC hálózaton 10.60.xx.xx címet kapott. Persze a családi ház kamerarendszerére távolról nem tudott rátekinteni. Aztán távgyógyászkodhattam az UPC ügyfélszolgálatával kardozva.

Tudom, kevés az IPv4 cím, az ügyfélkör pedig bővül. Az IPv6-ot amíg csak lehet, a szolgáltatók nem merik bevállalni. De meddig mehet ez így?
Egyre többünknek van kellemetlensége a nem publikus IP címmel hírdetett internetszolgáltatással.

Náluk nincs nat[at]upc.hu email ? :(

Amúgy meg:

whois -h whois.ripe.net POEM-RIPE55-SONG | more

natkukac-rol nem tudok, de az ipv6-ot keresre bekapcsoljak.

Hogy?

Erre a válaszra én is beneveznék. Amikor kérdeztem, akkor csak pislogott az illető a túlvégen...

--
openSUSE 13.1 x86_64

Az ismerosom kb 1 hete intezte el maganak, az UPC Magyarorszag FB fiokra irt, hogy szeretne ipv6-ot.

Viccesen hangzik, de kipróbáltam és írtam nekik én is:)

Ha bejön az adás légyszi írj ide, én is ugrok rá azonnal.

Megjött a válasz,

"Informatikus kollégáknál utánajártunk a kérdéskörnek, és az alábbi információt szeretnénk átadni. Az IPV6-os címmel a modem külső publikus IP címe lesz IPV6-os, a belső hálózata továbbra is IPV4-es marad. Levenni le tudjuk, ha pl. hibát okoz, de az aktiválása nem manuálisan, hanem automatikusan megtörténik ott, ahol a hálózatot már felkészítették erre."

Ez elég bizarrul hangzik
--
>'The time has come,' the Walrus said<

Kicsit hunyorítva messziről azt mondanám DS-Lite.
http://www.nic.cz/files/nic/img/Martin_Krautwurst_Panelova_diskuse.pdf

https://www.upc.hu/pdf/Ubee_EVW3226_UserManual-HU.pdf

83. oldal: "A DSLite menü"

Hümm.

Az mondjuk szopó, ha tényleg csak LSN mellett adnak IPv6-ot, valódi dual stack megoldás nem lesz.
Az kicsit korrektebb lenne, ha a júzer alapból privát IP-t kapna, kérésre visszaállítanák neki a publikus IP-t (lásd: Telekom és társai) és mindezektől függetlenül az IPv6 pedig mindig elérhető lenne.

Persze, a szolgáltató oldaláról nyilván egyszerűbb teljesen IPv6 infrastruktúrát kiépíteni, mint dual stack-eset. A (NAT-olt privát) IPv4 címet meg egyszerűen vagy kitolják a júzernek egy tunnelen, vagy NAT64, aztán legyen vele boldog.

Őszintén szólva én még azt se bánnám ha IPv6 only lennék, csak szóljanak előre, hogy fel tudjak készülni rá.

Akkor ugy latszik nem mindegy ki adja a valaszt :)

Az ismerosomnel kicsereltek a Cisco-t Ubee-re + fw upgrade, /64-et allokalnak es slaac van lan oldalon.

Tehát az Ubee router módban van, nem pedig bridge módban?

Router módban arra gondolnék, hogy az endjúzer közvetlenül csatlakoztatott pécéire számítanak, tehát az SLAAC okés. Viszont, bridge módban elkélne egy prefix delegáció, mondjuk legalább /56-tal, hogy lehessen subnetelni.

és legalább a prefix statikus?

Köszi!

A UPC-nél én két dolgot nem értettem:

1.) az átlag dinamikus IP-s végfelhasználónak (a jófejségen kívül) miért adnak 3 azaz három publikus IP-t? Mindenki más 1-et ad. Ha a végfelhasználó több eszközt szeretne, akkor NAT-oljon magának, nem 1995-öt írunk.

2.) az átlag fix IP-s végfelhasználónak miért egy route-olt /30-on adják ki a kért 1 darab fix IP címet? Ez végfelhasználónként 4 darab IP cím elpusztítását jelenti, holott adhatnák ugyanúgy bridge-elt subnetben, mint a dinamikus IP-t. Én is preferrálom a L3 route-olt hálózatot az L2 bridge-elttel szemben, de ez a mai világban óriási pazarlás. (Ha a dinamikus IP-s ügyfélnek jó, akkor a fix IP-snek miért nem? A fix IP felárában jobb topológia is jár?)

1, anno volt megkötés, hogy hivatalosan 1 előfizetés 1 eszköz(akkoriban pc), és talán a "gold" csomaggal bejött, hogy 1 előfizetés 3 eszköz, így kaptál is szépen 3 pub IP-t
persze soha nem vontak senkit sem felelősségre mert betett egy natoló linuxot és TTL limit sem volt, mint más kis ISP-knél

2, Gondolom nincs diff a között aki csak 1 fix címet kér, mint a között, aki kér mondjuk egy /24-et amit szintén egy ilyen /30-as kapcsolaton át tolnak neked. Persze lehetne akár egy /31 is:) http://packetlife.net/blog/2008/jun/18/using-31-bit-subnets-on-point-point-links/

sub a packetkife-os nagyaeazatra
--
WP8.x kritika: http://goo.gl/udShvC

Pedig nem bonyolult. Az ÁSZF szerint a 60Mb/s szerződés esetén 3 számítógépet dughatsz be. Ehhez 3 IP címet biztosítanak. (Figyeled: a T-nél egyet se.)

A fenti cím ún. DHCP-vel kiosztott fix IP cím. (Írják: szerver üzemeltetése nem lehetséges.) Általában a következő hálózatfejlesztésig a MAC-hez rendelve ugyanazt a címet kapod. Eleinte "újra kellett regisztrálni" pl. hálózati kártya csere esetén. Jelenleg - vagy 10 éve - intenzív "Who has this IP address?" ARP kérdésekkel ellenőrzik a címeket és regisztrálják a szabaddá válást. Ez lehetővé teszi a regisztráció nélküli MAC váltást, vagyis a három csatlakoztatott gép bármelyikét lecserélheted és kapsz címet. Persze egy újat.

Szóval ez az egész nem akkora pazarlás, mert a felhasználók java része nem használja ki a 3 címet. Viszont a szerződést teljesítik, ha igény van rá.

A megoldás roppant kényelmes, mert pl. egy ssh kapcsolat több napon keresztül fenntartható. Ugyanekkor a T-nél használt módszer - a naponta akár többszöri cím csere - elég kellemetlen egy hosszabb távoli munkavégzésnél.

A 2. kérdéshez sajnos nem értek.

> Ugyanekkor a T-nél használt módszer - a naponta akár többszöri cím csere - elég
> kellemetlen egy hosszabb távoli munkavégzésnél.

Nekem otthon T- van, de nem tapasztalok ilyet. Ugyan minden PPPoE sessionban garantáltan más IP-t kapok, de a PPPoE session-ök csak úgy nem szoktak naponta többször megszakadni.

A log alapján az aktuális PPPoE session október 31. óta van becsatlakozva. Ez a 13. nap azóta.

Az ADSL hőskorában volt a kötelező 24 óránkénti bontás, de az manapság megszűnt. Akkoriban jól lehetett ütemezni a bontás idejét éjszakára egy szándékos bontással éjjel 2-kor.

Mondjuk, ez GPON. Ha neked ADSL van, és a rossz jel-zaj arány miatt rendszeresen berohad a session, az egy másik témakör.

Való igaz, régen volt, nem is az enyém volt.
Amit írtam - UPC vs. ADSL - az viszont egyidejű tapasztalat.
Ráadásul UPC van már vagy 15 éve.

Most megnéztem én is, nekem 10.7.x.x belső IP-t adtak. Sikerült már valakinek kikapcsoltatnia a NAT-ot? A hivatalos oldalon semmit nem találtam.

Most köttettem 4-én, direkt rákérdeztem a NAT-ra, az ügyfélszolgálatos nem tudott róla semmit.

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

1412 felhívod, hibabejelentésre kapcsolsz, és ők készségesen segítenek benn! Érdemes azt mondanod,hogy kamera rendszered van, és szeretnéd a telefonodról is nyomon követni.

Köszi!
Bocs, hogy nem írtam, a UPC-nél vagyok. Náluk is működik?

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

Töprengek, miről is írkáltok.
A kábelmodem IP címe tényleg a 10.x.x.x tartományban van, de ennek semmi köze a publikus címhez.
Konkrétan
1) Cisco EPC3212 - ez csak bridge - 192.168.100.1
2) Ubee EVW3226 - bridge módban - 192.168.100.1, de Rendszer->Állapot szerint 10.4.x.x - tán a WiFree címe? Ebben az esetben nem célszerű a 10.x.x.x subnetet belül használni!

A mögöttük levő routeren mindkét esetben van publikus IP cím, a 176.63.x.x és a 80.99.x.x tartományban.

És tényleg. Nagyon szépen köszönöm!
Csak azt nem értem, hogy miért ilyen félre vezetően írja a router felületén. Ill a publikus IP-t se találom, hol írja.

Szerk.: Közben megtaláltam másik oldalon.

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

T sem natol koaxon, legjobb tudomásom szerint.

A T elkezdte szórni az ügyfeleket privát IP címekre, erről voltak hírek. Hivatalosan a security miatt, de mindenki sejti, hogy azért, mert drága az IPv4.
Én írtam egy emailt az MT azonosítómmal hogy nem kérek belőle, válaszoltak hogy rendben, maradok publikus címen (mezei otthoni adsl).

--
arch,debian,openelec,android

Valaki próbáljon már meg ilyet írni nekik: feladom az IPv4 címemet, ha adnak egy rendes IPv6-ost :) (és szégyelljék magukat, ha ez nem lehetséges)

--

Az új home gatewayeik tudnák, de nekem a teszt üzemes már nem megy. :(

dupla

Arra egyébként van valakinek tippje, hogy az egyes szolgáltatók hány privát IP-t NAT-olnak egy publikus IP-re? Nyilván mindenki, aki NAT-ot csinál, azzal kezdi, hogy megbecsüli, hány egyidejű TCP/UDP kapcsolat várható...

Nem fogadnék rá hogy az ISP-knél ilyen van, de rendezvényeken láttam már olyan NAT-ot ami egy poolból mindig a szükséges mennyiségű címet használja.

Az rendben van, hogy odaadsz egy pool-t, de a kérdés az, hogy mekkorát?:)

8-10 előfizető jut egy publikus IP-re.

Vajon TCP/UDP kapcsolatonként kell egy-egy IP cím? Vagy valamit rosszul tudok?
De még az előfizetők száma sem tökéletes mérőszám. Inkább a hálózatra kötött eszközök számát szokták figyelembe venni.
A NAT meg több féle lehet. Tehát már a kérdés sem jó. :(

Szerintem a digi is NATol egy jó ideje, legalábbis nálam.
A torrentnek már jóideje nem tudok portot nyitni, akkor is zártnak mutatja a portokat amikor közvetlenül a gépbe dugom a kábelt.

Lehet hogy csak portszurest vegez.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Igen, Digi NAT-ol már IPv4-en

1.) nézd meg a router wan interfészét
2.) http://test-ipv6.com/

Esetemben:
root@OpenWrt:~# ifconfig | grep -A1 ppp
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:100.65.5.185 P-t-P:10.0.0.1 Mask:255.255.255.255

És a test-ipv6.com szerint:

Your IPv4 address on the public Internet appears to be 94.21.112.110
Your IPv6 address on the public Internet appears to be 2a01:36d:103:252c:842e:9609:2670:54f

Utóbbi tényleg a laptopom IPv6 címe, az IPv4 cím viszont nem a routerem WAN címe.

És ismét tanultam: mi a 100.64.0.0/10 IP tartomány?
4 milliós "Private network", amely "Used for communications between a service provider and its subscribers when using a Carrier-grade NAT, as specified by RFC 6598"

És gyakorlatilag 4 éve regisztrálták ezt erre.

NetRange: 100.64.0.0 - 100.127.255.255
CIDR: 100.64.0.0/10
NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle: NET-100-64-0-0-1
Parent: NET100 (NET-100-0-0-0-0)
NetType: IANA Special Use
OriginAS:
Organization: Internet Assigned Numbers Authority (IANA)
RegDate: 2012-03-13
Updated: 2012-04-23
Comment: This block is used as Shared Address Space. Traffic from these addresses does not come from IANA. IANA has simply reserved these numbers in its database and does not use or operate them. We are not the source of activity you may see on logs or in e-mail records. Please refer to http://www.iana.org/abuse/
Comment:
Comment: Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when addresses are identical on two different interfaces.
Comment:
Comment: This block was assigned by the IETF in the Best Current Practice document,
Comment: RFC 6598 which can be found at:
Comment: http://tools.ietf.org/html/rfc6598

Akkor ez ilyen hírportál olvasgató, cicás videó nézegető szolgáltatás internet helyett?


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

a digi már csak azért sem internetet szolgáltat, amiért a ppp koncentrátorok privát IP-címekről küldenek kifelé ICMP fragmentation needed üzeneteket. 1492-es mtu miatt ez ugye kellemetlen (PMTUD-t megölheti), főleg ott, ahol a bejövő rfc1918-as című csomagokat szűrik is (hol nem?).

Gondolom, ha szólna, h neki kell a "rendes" ipv4, azért kapna. Most kapott ipv6-ot, megy azon. Nálam rendes ipv4 van, még lusta voltam a linuxomat ipv6-ra beconfigolni...

Ez probléma, mert egy ismerősömnél kellene a publikus cím, azt is mondták, hogy az lesz. Még nem létesítették, mert hálózatbővítés kell, és lassúak.

Ezek szerint szemrebbenés nélkül átvertek, mondván, szó elszáll? Csak mert kifejezetten rákérdeztem.


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

Mit érdemes mondani a diginek ha visszakérem a publikus IP-t, mi az az otthon is végezhető legális tevékenység amihez elengedhetetlen a publikus IP? VPN? SIP telefon?
Az is elég indok hogy távolról adminolni szeretném a gépet? Pl a tunerkártyával fel akarok vetetni egy műsort, és erre távolról szeretném kiadni az utasítást? A SIP telefon ugye nem működik NAT mögül, ha nem tudok portot nyitni? (Márpedig a digi szerverein nyilván nem tudok).

Biztonsági kamera elég indoknak tűnik ...

A kínaiakhoz a backdooron kívül jár autonat is. :)

Nem hinném, h indokolni kellene.

"A SIP telefon ugye nem működik NAT mögül, ha nem tudok portot nyitni?"

Ha nem te vagy a SIP szerver, hanem csak egy kliens (telefon, SoftPhone alkalmazás), akkor gond nélkül megy NAT mögött.

Nem tudom, de most megijedtem, hiszen azon vagyunk, hogy legyen Digi az említett helyen, viszont szükségem van arra, hogy tudjak ssh-zni a gépre, továbbá portot nyitni peer to peer VoIP miatt.


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

IPv6, oszt' jónapot :-P

Van egy TP-Link router a gép előtt, szerintem az csak v4-et tud. Kell, hogy legyen WiFi is egy másik notebook-hoz. Manapság már nem az oprendszerek miatt gond, mert mindegyik tudja a v6-ot, de közte. A másik, amihez meg hülye vagyok, hogy nem tudom, melyik rétegtől fedődik ez el. Teszem azt, a p2p VoIP kliensnek kell erről tudnia? Gyanítom, mert még a névfeloldást is ő intézi. Meg aztán v4 és v6-os gép közti kapcsolat? Vagy ez csak legalul érdekes? Tényleg homály van bennem ezzel kapcsolatban, nem foglalkoztam még v6-tal.


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

A TP-Link router nem kizáró ok, ha az OpenWRT legfrissebb stabil verzióját (15.05) fel tudod rakni rá.
A nagyobb baj, hogy nem oldja meg maradéktalanul a problémád, mivel gondoskodnod kell arról, hogy ha más hálózatról akarsz hazamenni ahol még nincs IPv6, akor legyen valahogy IPv6 hálózatod, például tunnelezett IPv6.

... ha majd a többi szolgáltató is adni fog IPv6-ot (vezetékesek és mobilszolgáltatók), akkor már ez sem lesz kérdés.

Addig viszont marad a könnyebb útnak a NAT kikapcsolásának kérése.

Ezt úgy szoktam elintézni, hogy a router folyamatosan fent lóg egy fix IP-vel rendelkező OpenVPN szerveren, mint kliens.
Kapott néhány push route -ot, hogy mely hostok elérésekor zavarjon be a VPN-be, pl. távoli VoIP szerver, dedikált IP-ről elérhető menedzsment felüeltek.
Ha el akarom érni az otthoni hálót/távoli menedzsmentet, fellépek szintén erre az OpenVPN szerverre egy kliens programmal.

Na jó, de ehhez kell egy szervered valahol a világban.


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

Vagy fix publikus IP-d valahol a világban. Végül is ha már van egy ilyen helyed, egy Rpi-vel megoldható a dolog, de akár egy Tomato firmware-s routerrel is. Ha szétnéz az ember, hamar találhat. Pl. egy ismerős cége, rokonnál, akárhol.

Felhívsz, nat kikapcsolást kérsz. Én meg eldöntöm, hogy kikattintom, vagy nem.
Furcsa is lenne. :D

Nem a diginél dolgozom, de sosem kérdezem senkitől, igazából semmi közöm hozzá.
Fenntartom, ha nekem lenne egyszer ilyen problémám, én sem biztos, hogy részletezném az operátornak.

Volt róla itt is cikk hogy a T már legalább fél éve NAT-ol, helyszíne válogatja.
Talán elfogytak az IPv4 címeik