T-Home NAT-ol?

Hálózatok általános

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.

  • 42686 megtekintés

( Seaweed | 2013. 10. 08., k – 12:11 )

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.

( Skuzzy | 2013. 10. 08., k – 12:14 )

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

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&showARI…

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.

( Proci85 v | 2013. 10. 09., sze – 07:52 )

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 nat@telekom.hu 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

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.

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?:)

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

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.

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

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

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.

( wladek1 | 2013. 10. 09., sze – 18:21 )

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

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

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.

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)

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

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

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.

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

( secretx v | 2013. 10. 09., sze – 21:09 )

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"

( hnsz2002 v | 2013. 10. 09., sze – 21:48 )

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

( Zs | 2013. 10. 10., cs – 12:44 )

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

( djsilas | 2013. 11. 10., v – 16:41 )

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

( azbest | 2013. 11. 18., h – 01:27 )

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.

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.

( apal v | 2013. 11. 25., h – 10:24 )

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?

( bitumen | 2013. 12. 05., cs – 10:28 )

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)

( uid_6201 v | 2015. 11. 11., sze – 20:44 )

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.

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

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.

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.

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-po…

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.

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'

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.

( uid_4263 v | 2015. 11. 12., cs – 09:18 )

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

( mauzi v | 2015. 11. 12., cs – 10:14 )

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

( attilav2 | 2016. 02. 25., cs – 21:14 )

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.

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

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

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

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.

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.

( mark7 | 2016. 02. 26., p – 12:57 )

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