Privat IP cimek az interneten (a szolgaltato halozataban?)

Hálózatok általános

Joreggelt! 


G:\>tracert 10.0.10.1

Útvonal követése a következőhöz: 10.0.10.1, legfeljebb 30 ugrással.

  1     1 ms     1 ms     1 ms  10.0.0.250
  2    18 ms    13 ms    12 ms  lo1.esr0-szekesfehervar.net.telekom.hu [145.236.238.182]
  3    13 ms    19 ms    14 ms  g2-18.osr0-szekesfehervar.net.telekom.hu [84.1.68.9]
  4     *        *        *     A kérésre nem érkezett válasz a határidőn belül.

  5     *     ^C
G:\>

A host 10.0.0.0/24 subneten, a target 10.0.10.0/24-en, a 10.0.10.1 elvileg egy switch lenne LAN-on, csak mas VLAN-ban, es mielott megcsinaltam volna a routingot probaltam belepni ra, nem igazan sikerult, viszont a ping visszajott, ami erdekes, a traceroute kimenete pedig lathato.
A 10.0.0.250 egy Cisco router (csak NAT, 0.0.0.0-ra gateway a WAN interface, ill. nehany 10.x.x.x subnetekre statikus route-tal vannak szetdobalva a csomagot, se EIGRP-t, se OSPF-et nem tud a szerencsetlen, ha tudna, akkor a problema elo sem jott volna), router nelkul, kozvetlenul internetre kapcsolodva (FreeBSD 8.0/SPARC64) ugyanez a helyzet, masik cickoval szinten.
A traceroute addig fut, amig a maximalis (30, fbsd-n 64) TTL-t el nem eri, vagy amig le nem lovom. Persze miutan a routingot megcsinalom a megfelelo iranyba onnantol mar ugy mennek a dolgok, ahogy szeretnem, de nem az volt, hogy a privat IP cimtartomanyok semmilyen korulmenyek kozott nem routolodnak interneten...?

Ize, kimaradt (bar szerintem a traceroute kimenetebol latszik:), hogy T-{Online|Home|mittomen} ADSL, 22-es korzet.

  • 4828 megtekintés

( janoszen v | 2010. 01. 12., k – 19:28 )

Ha jól tudom, a T*nál valami MPLS működik a 10es IPkkel és valszeg szűrik is, hogy ne menjen ki a hálózatukból ilyen csomag.

Nekem is dereng ilyesmi regebbrol, de mennyire uzemszeru, hogy sima vegfelhasznalo felol van 10.x.x.x iranyba akarmilyen routing (meg ha kozben meg is eszi valami tuzfal/ACL)? Nem ugy kene lennie, hogy mar maga az access server/akarmi elhajt a verbe ilyen IP-kkel?

A végfelhasználó publikus IP-t kap. Egyébként a mindenféle szerverek azzal hajtanak el a vérbe, amire konfigurálva vannak. Ez a T-nél sincs másképp, simán routolhatsz privát IP-t, csak konvenció, hogy nem routolsz és senki más sem fogja az ilyen IPjű forgalmadat routolni.

( suckit | 2010. 01. 12., k – 20:23 )

A szolgáltató hálózata azért még nem az "interneten route-olódnak". :)

Legkésőbb a határnál célszerű persze ezeket szűrni, de gyakori, hogy felmegy egészen magasra is. Sajnos a BIX felől/felé sem divat a szűrés, elég sok szolgáltatótól könnyű IP-t hamisítani...

suckIT szopás minden nap! IMAP szerver benchmark

"Sajnos a BIX felől/felé sem divat a szűrés, elég sok szolgáltatótól könnyű IP-t hamisítani..."

Noha a BIX szabályzat explicite kimondja, hogy csak olyan src címekkel küldhet a BIX-be be a szolgáltató packetot, amely címre a BIX szabályzat szerint hirdethet is route-ot (azaz saját vagy ügyfele regisztrált IP címeit)...

Ezen felül persze minden szolgáltató elemi érdeke, hogy minden ügyfelétől szintén csak olyan forráscímmel fogadjon el packetokat, amely címet az ügyfél jogosan használ.

( margera | 2010. 01. 12., k – 20:53 )

Nekem egyszer ilyet produkalt egy traceroute: WTF
Most pedig kiprobaltam enis egy tracert 10.0.0.1-et es ezt adta be: WTF2

( zitev v | 2010. 01. 12., k – 21:05 )

t-nél is ez van, hatalmas packet lossal az alhálózati címtartományból kilépő routeren, nézzetek már egy mtr bix.hu-t, hátha nálatok is látszik...

( psc | 2010. 01. 12., k – 21:15 )

wtf:

pscs-MacBook-Pro-17:~ psc$ traceroute index.hu
traceroute to index.hu (217.20.130.97), 64 hops max, 52 byte packets
1 r2d2 (192.168.4.1) 1.551 ms 1.098 ms 1.017 ms
2 host-79-121-88-1.supraktv.hu (79.121.88.1) 551.228 ms 4603.982 ms 1841.049 ms
3 10.250.0.1 (10.250.0.1) 923.439 ms 920.392 ms 777.622 ms
4 84.1.98.193 (84.1.98.193) 757.359 ms 1023.399 ms 819.283 ms
5 81.183.245.18 (81.183.245.18) 612.369 ms * 1079.878 ms
6 vlan902.core0.interware.hu (217.20.137.41) 616.141 ms 616.325 ms 387.113 ms
7 sportgeza.hu (217.20.130.97) 971.468 ms 1054.803 ms 919.453 ms
pscs-MacBook-Pro-17:~ psc$

a 3. hop, a 10.250.0.1 is ilyen privat ip, ugye?
valaki traceroutolja le legyen szives a 79.121.88.1 -et!

traceroute 79.121.88.1
traceroute to 79.121.88.1 (79.121.88.1), 30 hops max, 40 byte packets
1 ROUTER.RADIO (192.168.100.1) 2.414 ms 2.532 ms 2.650 ms
2 10.224.192.1 (10.224.192.1) 15.138 ms 15.298 ms 15.340 ms
3 145.236.154.37 (145.236.154.37) 15.617 ms * *
4 84.1.98.194 (84.1.98.194) 23.020 ms 23.187 ms 27.348 ms
5 host-79-121-88-1.supraktv.hu (79.121.88.1) 29.289 ms 29.445 ms 29.608 ms

egyébként nekem is ott a privát...

erdekes...

amugy supraktv-nel valaki nagyon tud: :)
traceroute to 10.0.10.1 (10.0.10.1), 64 hops max, 52 byte packets
1 r2d2 (192.168.4.1) 3.646 ms 1.019 ms 1.193 ms
2 host-79-121-88-1.supraktv.hu (79.121.88.1) 806.179 ms 1229.567 ms 1149.479 ms
3 10.250.0.1 (10.250.0.1) 693.987 ms 509.308 ms 678.268 ms
4 10.250.0.4 (10.250.0.4) 613.168 ms 874.208 ms 614.420 ms
5 10.250.0.1 (10.250.0.1) 614.061 ms 613.723 ms 333.308 ms
6 10.250.0.4 (10.250.0.4) 403.096 ms 326.413 ms 302.714 ms
7 10.250.0.1 (10.250.0.1) 476.145 ms 412.789 ms 815.007 ms
8 10.250.0.4 (10.250.0.4) 921.965 ms 594.727 ms 940.411 ms
9 10.250.0.1 (10.250.0.1) 219.360 ms 701.743 ms 920.714 ms
10 10.250.0.4 (10.250.0.4) 392.500 ms 426.513 ms 421.079 ms
11 10.250.0.1 (10.250.0.1) 602.313 ms 330.326 ms 590.384 ms
12 10.250.0.4 (10.250.0.4) 448.479 ms 778.106 ms 287.639 ms
13 10.250.0.1 (10.250.0.1) 633.724 ms 920.746 ms 1226.670 ms
14 10.250.0.4 (10.250.0.4) 923.472 ms 921.288 ms 919.412 ms
15 10.250.0.1 (10.250.0.1) 491.503 ms 738.507 ms *
16 10.250.0.4 (10.250.0.4) 1127.557 ms 1243.895 ms 919.520 ms
17 10.250.0.1 (10.250.0.1) 616.262 ms 307.213 ms 613.414 ms
18 10.250.0.4 (10.250.0.4) 614.647 ms 613.323 ms 386.595 ms
19 10.250.0.1 (10.250.0.1) 418.229 ms 729.835 ms 614.603 ms
20 10.250.0.4 (10.250.0.4) 614.511 ms 1227.438 ms 924.369 ms
21 10.250.0.1 (10.250.0.1) 918.843 ms 920.097 ms 573.785 ms
22 10.250.0.4 (10.250.0.4) 477.772 ms 791.306 ms 614.447 ms
23 10.250.0.1 (10.250.0.1) 303.650 ms 616.430 ms 614.348 ms
24 10.250.0.4 (10.250.0.4) 337.261 ms 596.228 ms 602.023 ms
25 10.250.0.1 (10.250.0.1) 306.272 ms 921.196 ms 1228.757 ms
26 10.250.0.4 (10.250.0.4) 921.740 ms 921.189 ms 716.643 ms
27 10.250.0.1 (10.250.0.1) 819.011 ms 367.795 ms 552.819 ms
28 10.250.0.4 (10.250.0.4) 491.949 ms 736.930 ms 393.555 ms
29 10.250.0.1 (10.250.0.1) 527.291 ms 412.241 ms 815.464 ms
30 10.250.0.4 (10.250.0.4) 614.551 ms 1227.878 ms 921.518 ms

ez megy addig, amig a TTL le nem jar. :D

Ja, a pingek is eleg jok:D

Mondjuk zitevnel az a 10.224.192.x az gondolom a szolgaltato NAT poolja akar lenni, legalabbis nekem gyanus:)

Az eredeti temahoz:

Ugy latom, hogy ezek szerint kb. szolgaltatoi gyakorlat, hogy az ISP halozataban levo privat cimek tobbe-kevesbe latszodnak, igazabol ez lett volna az, amiert az egesz threadet inditottam.
Szamomra tovabbra is furcsa/szokatlan egy kicsit ez a dolog (lehet, hogy ez is jelzi, hogy kisse fogytan vannak a publikus IPv4 cimek), de ez az en bajom:)

Ez a hozzászólás engem megvilágosított:
http://hup.hu/node/81447#comment-929974

A hint: MPLS

http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
https://nws.niif.hu/ncd2001/docs/eloadas/98/index.htm
http://feczo.nmi.rulez.org/vpn/szakdolgozat/node13.html

Ha tényleg így működik a T hálózata, akkor érthető.

( KoGa v | 2010. 01. 12., k – 21:40 )

Ooo.. nem ismerem a traceroute mukodeset annyira, de szerintem siman latszodhat kulso IP-n az eszkoz a halozat fele attol meg hogy privat ip-vel megy vissza a traceroutera. De szoljatok ha tevedek.

( lacika v | 2010. 01. 13., sze – 21:52 )

Shorewall logban egy adatközpontban lévő gépről:
Shorewall:rfc1918:DROP:IN=eth1 OUT= MAC=00:e0:81:5d:eb:c3:00:1b:2b:f7:5d:00:08:00 SRC=192.168.106.163 DST=PUBLIKUS_IPm LEN=909 TOS=0x00 PREC=0x00 TTL=60 ID=39771 DF PROTO=TCP SPT=1255 DPT=80 WINDOW=64240 RES=0x00 ACK PSH URGP=0
Ebből van bőven, meg udp/53-ra is próbálkozik.

--
http://laszlo.co.hu/

( hg2ebh | 2010. 01. 21., cs – 17:51 )

Miért ne lehetne a szolgáltató hálózatában a route-olást végző eszközökön privát IP cím? :)

Lehet, feltéve, hogy az eszközből a route-olás során keletkező ICMP csomagokra "valaki" automágikus módon korrekt src címet varázsol később. Ennek hiányában ugyanis jó eséllyel az a csomag nem fog visszajutni az eredeti küldőnek, aki így az őt jogosan megillető ICMP üzenetet nem fogja megkapni, és pl. nem értesül róla, hogy a csomagjai eldobálásra kerültek.

Bizonyos esetekben ez akár a kommunikáció ellehetetlenüléséhez is vezethet (lásd ICMP Fragmentation Needed).

( willy v | 2010. 01. 23., szo – 06:39 )

Minden valószínűség szerint level3 (ip) szolgáltatást kapsz, minimum illik megbeszélni, ha akarsz valamit módosítani, de inkább nem tenni semmit illik. A privát hálózatot nem routoljuk interneten, a szolgáltató hálózata jelenleg annak minősül. Mi lenne a cél?
Ha pedig arra célzol a szolgáltató miért csinál ezen valamit, mivel neki a saját belső hálózata az (level2) és néhány dologra nem pazarol ip-t, ahol kell megszünteti a routolást.
Ettől függetlenül, nem biztos, hogy ez jó, és szándékos.

Ezt most annyira nem vagom.
Konkretan mit jelent a 'level3 (ip) szolgáltatás'? Ha aka'r egy mezei ADSL-t, akkor igen, azt kapok, ha mast, akkor nem:) Nalam az egesz mindenseg NAT mogott van, nem teljesen ertem, hogy mit kene a szolgaltatoval megbeszelni.
A cel kb. az, hogy szetdobtam a LAN-on a klf halozatokat/szolgaltatasokat kulon VLAN-okba, es az egyes VLAN-ok kozott az igenyeknek megfeleloen csinaltam routingot, ill. mindenfele ACL-eket. Aztan az egyik eszkozon, amin ideiglenesen statikus routeot kellett (volna; ahogy az indito postban is irtam) csinalni, amit elfelejtettem, igy aztan a 10.0.10.0/24 subnetbe cimzett csomagok a megfelelo (belso halon, NAT mogott levo) host helyett elindultak a nagyvilagba a DSL routeren (ami ugye 0.0.0.0-ra hirdeti magat routernek) keresztul, en pedig meglepodtem, hogy ping reply van, login prompt nincs, aztan traceroute utan megjobban meglepodtem:)
Kb. ennyi a tortenet, lehet, hogy a kulso routeren gyartok valami ACL-t, es akkor tobb privat IP-s csomag nem fog kitalalni az ISP fele, bar szerintem alapbol nem lett volna szabad az ISP eszkozeinek ilyen cimekre barmit is tovabbitani.

ADSL: a legjobb példa az IPonly felhasználásra.
A hálózat a szolgáltató tulajdona ő szervizeli, és osztja a hozzáférést, nem drótot, és nem hozzáférés protokoll hozzáférést vettél, hanem IP feletti kommunikációt. Az IP feletti kommunikáció azt jelenti, hogy a végponton nincs jogod beavatkozni az ip kiosztásába, konfigurálásába.
Nem volt érthető, hogy miért próbáltál tracelni az otthon biztosan fel nem lelhető, és a NAT eszközön túli hálózatra.
A másik, hogy a NAT eszközödbe végződő hálózata neki saját layer2 hálózata, ahol nem mindig hiba, ha ez nincs szűrve.

Valoszinuleg bennem van a hiba, de tovabbra sem teljesen ertem, hogy mire gondolsz. Az layer3 szolgaltatas mar tiszta, ellenben a sehol nem avatkoztam bele a szolgaltato ip konfigjaba; a szolgaltatotol kapcsolodaskor kapok egy publikus IP-t, mogotte NAT, es jonapot, legalabb a juzerek fele igy hasznalja a szolgaltatast. A tracelt host az itthoni halozatomon fellelheto, es oda akartam kapcsolodni, bar a felrekonfiguralt routing (eppen kicsit keplekeny allapotban van/volt az itthoni halozatom, a jelenlegi kaoszt probalom valami ertelemesebb rendszerbe atszervezni) miatt kiment az ISP fele, es -- amire nem szamitottam -- volt is ilyen host az ISP-nel. Ezert indult ez a topic, hogy mennyire bevett szokas az ilyesmi, es a hozzaszolasokbol az derult ki, hogy elegge.
Szoval a router kulso interface-ere gyartok valami ACL-t, hogy dobja azokat a csomagokat, ahol a cimzett privat tartomanyban van es innentol nincs ilyen gond.

Meglátásom szerint semmi gond nincs azzal, hogy az ISP-k privát címeket használnak belső eszközeiken. (Publikus ip spórolás)

Ahogy te is írtad, miután megmondtad a routerednek, hogy merre keresse az adott privát tartományt a probléma megoldódott.

Willy, szerintem arra gondolt, te mint végfelhasználó csak a publikus címedet használhatnád (elméletileg ugye tiltott a NAT :) ), ezáltal nem is fordulhatott volna elő a topic indító probléma. Ha meg használsz belső címeket, akkor figyelni kell merre route-olod azokat.

> Meglátásom szerint semmi gond nincs azzal, hogy az ISP-k privát címeket használnak belső eszközeiken. (Publikus ip spórolás)

Ez rendben, ugyis keves IPv4 cim maradt, de egy juzer hogyan jut el a belso eszkozokig? Nem csak kb. 1 hop-ot kene latnia az egeszbol? (Azert megjegyeznem, hogy nem sok kozom van az MPLS-hez, gondolom latszik:)

> (elméletileg ugye tiltott a NAT :) )

Ez mennyire biztos? Regebbrol olyasmi dereng, hogy haztartason belul engedelyezett a megosztas (bar mondjuk NAT-on kivul van mas lehetoseg is:), ill. IPv6-on sajat /56-os tartomanyt is adnak, ha DHCPv6-ot akarsz a T-* ADSL mogott levo otthoni halozatodon:>

Valami ASZF-eket gyorsan atfutottam, de ilyen kitetelt nem talaltam sehol.

"elméletileg ugye tiltott a NAT"

Ez biztos? Konkrétan, hogy a suprakft-nél maradjunk, amikor előfizettem, két kérdésem volt: "tényleg korlátlan, mindenféle trükk nélkül?" és "háztartáson belül szabadon továbboszthatom a kapcsolatot?"
Minkét kérdésre "igen" választ kaptam.

Lehet hogy elavultak információim, amikor ÁSZF-eket olvasgattam (a szuprakft biztos nem volt köztük), akkor mindegyikben benne volt,
a szolgáltatást csak egyetlen végponton lehet igénybe venni (nem megosztható).

"elméletileg ugye tiltott a NAT" = "elméletileg ugye tiltott a szolgáltatás megosztása több számítógépre"

Hát, szerintem ma már nem tiltják.
Régebben én is emlészem, hogy kb. minden szolgáltatónál tiltva volt a megosztás, ma már szerintem változtattak ezen.
De majd utána nézek, nem akarok hülyeségeket állítani, de 99% biztos vagyok benne, hogy manapság már nem tiltanak ilyet a szolgáltatók.

Ma mar a hazon belululi megosztas nem erdekli egyik szolgaltatot sem. Eletszerutlen is lenne a mai vilagban. T pl a kombinalt szolgaltatasaihoz maga adja a wifi router.
Privat cimek is azert vannak a halozatan, mert hasznalja oket pl az iptv es az egyeb szolgaltatasaihoz. A vegponton kulso ip-nek tunnek, de gyakorlaban persze a T halozatabol nem mennek ki, azon belul belsok.
Mondjuk az teny, hogy szolhatna roluk, egyszer meglepett, hogy sikerult a VPN-emet abba a taromanyba tenni, aztan fura volt, hogy akkor is ping a VPN-bol ip, mikor ki van kapcsolva:-) Bar nyilvan a felhasznalok toredeket erinti ez csak.

( NEUROFiRE | 2010. 02. 22., h – 21:13 )

Kicsit off, de... 


C:\>tracert hwsw.hu

Tracing route to hwsw.hu [62.112.195.203]
over a maximum of 30 hops:

  1     2 ms     2 ms     2 ms  10.0.5.254
  2     2 ms     2 ms     2 ms  10.0.4.2
  3   124 ms   127 ms    95 ms  lo1.rsr0-ip3.net.telekom.hu [145.236.238.254]
  4   115 ms   127 ms   117 ms  t3-2-2103.osr1-ip3.net.telekom.hu [84.1.94.110]

  5   159 ms   159 ms   107 ms  81.183.243.166
  6    94 ms   106 ms    97 ms  www.hwsw.hu [62.112.195.203]

Trace complete.

Kezdjuk ott, hogy mi a kolera az az RSR? (a korabbi OSR-t, asszem sikerult megfejteni, Optical Service Router lesz talan)
Ma delelott megfott a DSL link, hibabejelentes utan valami tortent (ufsz elmondasa alapjan port ujrainditas), de a 16M+/1M-bol lett 1M/128k, a 12-15msec-es pingbol (elso hop a szolgaltatonal) pedig a tizszerese, szoval ha azt vesszuk, akkor nem valtozott semmi (ugye 0.1*10=1, szoval...:) SNR margin 8-9dB-rol felugrott 30dB fole, szoval a vonal birna boven, nem ertem, de sebaj. Igazabol az a furcsa, hogy valtozott az elso hop (port ujrainditasnal gondolom nem illene), meg a 4. hopnal az a t3-* is gyanus nekem (34Mbps?:)

Na, ezt a hozzaszolast nem tudom minek irtam meg:)

ps. oooo, a nagy ping nem az Ericsson-fele mini-DSLAM-okra jellemzo?

A t3-2-2103 az a tengigabitethernet a 3-as slotban, rajta a 2-es port, azon belül a 2103-as VLAN.
A matáv jelenlegi hálózatában az ADSL koncentrátor és az első IP-t beszélő eszköz között van még egy-két helyen talán STM1-es ATM (ezeket is váltják szépen lefelé), de jellemzően szinte mindenhol már csak ethernet. Az első IP-t beszélő eszköztől felfelé (aki a next hop IP szinten) pedig csak >=1Gbps interfészekkel találkozhatsz, mert ethernet-alapú gerinchálózatra kapcsolódnak a routerek.