Milyen privát tartományt?

Hálózatok általános

Sziasztok,

van egy ~1000 gépes hálózat, ahol az IP NAT technológia hajnalán (közel 20 éve) 10.0.0.0/8-as privát tartományt állítottam be.

Az utóbbi időben azonban megszaporodtak az IP tartomány ütközésből eredő routing konfliktusok, főként, amióta megszaporodtak a mobil eszközök, ahol a mobilnet-szolgáltató NAT-olt címet ad.

Most éppen fel kellene routeolnom két DIGI WAN kapcsolatot, ahol "szerencsére" a PPPoE gateway IP 10.0.0.1, akárcsak nálam az egyik szerver.

Mivel vannak olyan subnetek, ahol 253-nál több gép van, ezért leginkább a 172.16.0.0/16 - 172.31.0.0/16 tartományok közül szeretnék választani. (Az egyes subneteknek /23 is elég volna, de a /16 használata áttekinthetőbb, és "szabványosabb" ebben a prefix mezőben)

Próbálok minél egzotikusabb prefixet választani, például 172.28.0.0/16-tól fölfelé.

Kérdés az, hogy ismertek-e olyan szolgáltatót/publikus szolgáltatást, ami házon belül ebből a tartományból dolgozik - magyarul problémát jelenthet VPN, BYOD, vagy bármi más szempontból?

Kösz!

  • 5630 megtekintés

( battila | 2015. 10. 09., p – 13:25 )

Ezek a kapcsoaltok mind 10.0.0.0/8-as halozatot akarnak?
Mert ha nem, akkor valassz a 10.42.0.0/16-ot, vagy valami random magas szamot.

Ahogy azt te elképzeled. Szinte nincs olyan 10-zel kezdődő tartomány, amit nem hoztak még be mobilnettel. Az biztos, hogy tömegével jelent az arpwatch az alábbi tartományokból címeket:

10.1.x.y - 10.10.x.y
10.40.x.y - 10.70.x.y
10.100.x.y - 10.110.x.y
10.200.x.y - 10.220.x.y

Persze, ezek csak feltételezett tól-ig határok, nem tudom, ki milyen netmaskot használ.

És ekkor mi van? A saját hálózatodba "kintről" ezek a mobil kütyük nem ezen a címen látszanak, ha meg mobilnetre és a saját 10-es hálódra is felcuppannak, akkor meg a saját vlan-t (meg amit odd dhcp-n hirdetsz subnetet) a belső, a 10/8 többi részét meg a mobilnet felé fogja keresni.

A külső partnerek felé kapcsolódva a címütközést vagy ipv6-on, vagy ipv4+nat megoldással tudod megoldani. Kijelölsz mondjuk egy /23-at ilyen célra, és partnerenként /24-eket hasynálva csinálod meg a natolást. Az átcímzésnél ez még mindig kisebb fájdalom/költség.

Nevezzetek hülyének, de ezt nem értem. Hogy a náthásba tud egyszerre wifi-n és mobilneten lenni a kütyü? Windóz?... Az még a 2.1-es droidnál is megoldott, hogy ha wifire kapcsolódok, akkor a mobilnet lekapcsol. Ha nem vagyok wifi ap-n, de a wifi antenna maga be van kapcsolva, akkor feljön a mobilnet.

Én tippem inkább az lenne, hogy -mivel írtad valahol, hogy a konkrét eszköz még nincs meg- valaki ezzel direkt "játszik"... Mert még ha egyszerre is lenne fent, miért routolná a mobilnetet a wifi-re? Annak csak adott eszközön kéne gondot okoznia, nem a komplett hálózaton.

upd: rossz helyre ment a reply...
Amúgy még azt nem értem, hogy akkor minek szeparálni vlanokba, ha utána kommunikálni akar?

--
openSUSE 13.1 x86_64

Amíg nincs internet wifi-n, addig aktív a mobilnet? Annak van ám értelme...

De ettől még ugyanúgy nem kéne megborítania a hálózatot. Legfeljebb elkezd a wifis belső hálóra is kommunikálni az eszköz. Ott az eszköz konfiggal van hiba, vagy szándékos szopatás.

--
openSUSE 13.1 x86_64

Ha ugyanolyan halo ugyanolyan netmaskkal kerul fel, akkor megborulhat az eszkoz, mert nem tudja, melyik interfeszen kommunikaljon. A halozatot nyilvan nem boritja meg, de az eszkoz sajat internetelerese elmehet, es ezt a user ugy erzekelheti, hogy elment a zinternet.
--
Blog | @hron84
Üzemeltető macik

( Proci85 v | 2015. 10. 09., p – 13:46 )

Lehet, hogy félreértettem valamit, de a 192.168.0.0/16-ból nem szerencsésebb osztani? Abból csak nincs képe egyik szolgáltatónak sem osztani.
A mai agyon NAT-olt szolgáltatóknál minden más csak rizikót hordoz magában, ahogy most a 10.x.x.x tartománnyal jártál.

> Lehet, hogy félreértettem valamit, de a 192.168.0/16-ból nem szerencsésebb osztani?

Nem. Jelenleg kb. 50 VLAN van forgalomban. (Minden irodaházi bérlőnek/cégnek saját VLAN-ja van)

Az egyik (legnagyobb és legrégebbi) VLAN-ban van a 10.0.0.0/8. A többi VLAN-ban 192.168.x.0/24 tartományok vannak, és már most komoly küzdelem nem beletrafálni valamelyikbe, ha valaki VPN-ezni akar akár kifelé, akár befelé.

A 192.168.0.0/16 a legrosszabb ilyen szempontból, talán még a szomszéd anyósának a mikrósütője is ilyen tartományban van.

( kroozo v | 2015. 10. 09., p – 13:44 )

Szerintem a /16al ne cseszekedj, elég rég CIDR van még, és a kisebb maszkkal sokkal könnyebb nem ütközni.

( fraque | 2015. 10. 09., p – 14:38 )

a 172.16/12 nagyobbacska kozintezmenyeknel, egyetemeknel gyakori, de meg mindig a legbiztosabb valasztas.
ezek a helyek altalaban hasznaljak es szetfarigcsaljak az egesz tartomanyt (nalunk legalabb /27-ig), emiatt nem hiszem, hogy lenyeges, hogy te pont a 172.28-ra gondoltal, gondoltak meg arra elegen, oszt vagy belelepsz, vagy nem.

( tompos v | 2015. 10. 09., p – 14:42 )

Eccer dolgoztam egy cegnek, ahol 192.1.2.0/24 volt:)

t

( PunishR v | 2015. 10. 09., p – 14:50 )

Magas labda, de fc00::/7 szerintem elég nagy, hogy ne legyen ütközés:)

( answ | 2015. 10. 10., szo – 10:57 )

Ezt policy based routinggal nem probaltad megoldani?

Ha a 10.0.0.0/8 subnetembe bejön a júzer a mobileszközével, majd ugyanazon az eszközön felmászik egyidejűleg mobilnetre is, ami szintén 10.0.0.0/8-as tartományból ad neki IP címet, akkor baszhatom a bármilyen routingomat, mert a subneten IP ütközés lesz, és a forgalom el sem jut a gateway-ig, hogy bármit is tudjak vele kezdeni.

> Hogyan?

Például így: (ez egy UPC netkapcsolat) 


traceroute to hup.hu (195.228.252.138), 30 hops max, 60 byte packets
 1  router.polihaz.hu (89.135.125.78)  0.163 ms  0.173 ms  0.193 ms
 2  10.8.13.254 (10.8.13.254)  8.048 ms  8.097 ms  8.146 ms
 3  catv-89-135-220-93.catv.broadband.hu (89.135.220.93)  8.579 ms  9.124 ms  9.027 ms
 4  84.116.241.38 (84.116.241.38)  7.925 ms  7.899 ms  7.916 ms
 5  ae1.ic1-dplex.net.telekom.hu (81.183.2.212)  8.348 ms  8.354 ms  8.346 ms
 6  81.183.2.210 (81.183.2.210)  8.913 ms  11.249 ms  11.235 ms

vagy így: (ez egy DIGI netkapcsolat) 


traceroute to ftp.fsn.hu (195.228.252.133), 30 hops max, 60 byte packets
 1  92.249.173.61  1.315 ms  1.318 ms  1.276 ms
 2  10.0.0.1  1.415 ms  1.484 ms  1.454 ms
 3  10.1.128.161 (10.1.128.161)  1.689 ms  1.737 ms  1.635 ms
 4  ae-3.cr01.budapest.digicable.hu (78.131.4.105)  1.887 ms  1.977 ms  1.837 ms
 5  te-0-1-0-2.xr01.budapest.digicable.hu (94.21.3.73)  1.957 ms te-0-2-0-2.xr01.budapest.digicable.hu (94.21.3.57)  2.244 ms  2.028 ms
 6  ae1.ic1-vhugo.net.telekom.hu (81.183.2.160)  1.739 ms  1.708 ms  1.824 ms
 7  xe-8-3-1.ic0-ip2.net.telekom.hu (81.183.0.166)  1.922 ms 81.183.0.176 (81.183.0.176)  1.073 ms 81.183.0.174 (81.183.0.174)  1.324 ms
 8  81.183.0.237 (81.183.0.237)  1.379 ms xe-1-1-0.ic1-dplex.net.telekom.hu (81.183.0.239)  1.319 ms xe-1-1-0.ic0-dplex.net.telekom.hu (81.183.0.243)  1.294 ms
 9  81.183.2.192 (81.183.2.192)  1.586 ms  2.683 ms 81.183.2.210 (81.183.2.210)  2.644 ms
 10  ftp.freepark.org (195.228.252.133)  2.258 ms  2.233 ms  2.210 ms

Akkor búbold meg nekem kérlek a DIGI-t.

Ez a DIGI PPPoE kapcsolat: 


ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr: 92.249.173.61  P-t-P:10.0.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:63 (63.0 B)  TX bytes:69 (69.0 B)

( pike.killer v | 2015. 10. 10., szo – 13:07 )

Milyert nem csinalsz egy uj halozati szegemnest melynek a tartomany a pl 172.22.10.0/24 ide erkeznek a VPNnel? Ha belso szervert kell elerni DNAT-olsz, ha kifele kell akkor SNAT-olsz.

( sj | 2015. 10. 10., szo – 21:03 )

Nem tudsz kerni a szolgaltatodtol (mondvan, hogy egy ceg haloja van mogotte) normalis, publikus ip-cimet?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( Atis89 v | 2015. 10. 10., szo – 22:10 )

Ha most találunk is olyan privát címtartományokat, amiket éppen még nem használnak a szolgáltatók, mi a garancia, hogy 2-3 hónap múlva nem fogják e azokat is használni?

Elvileg vannak olyan publikus IP címtartományok, amiket megvásároltak maguknak cégek, de szándékosan soha nem hirdették, mert csak a saját belső hálózatukban vagy egyéb célokra használnak. Esetleg utána kellene nézni néhány ilyen tartománynak és azokból kellene használnod (mivel senki se forgalmaz azon keresztül az Internet felé, nem kellene, hogy ütközés legyen).

Plan B: nézz ki egy kínai ADSL szolgáltató IP címtartományát, ami felé vélhetően soha nem akarsz majd forgalmazni és ossz abból

( mrceeka v | 2015. 10. 11., v – 11:18 )

Inkább elkerülni a helyzetet DirectAccess-szel vagy alkalmazás-publikálással?

Üdv,
Marci

Gyanúm, hogy némileg félreolvastam a feladatot, mert én csak a végponti eszközök routing problémáinak megoldását értettem feladatnak.
Azokra továbbra is tartom, hogy jobb elkerülni a problémát, például a fenti technológiákkal.
Válaszolva kérdésedre: mindkettő hálózati megoldás, a DirectAccess működik heterogén szerverkörnyezettel, az alkalmazás-publikálás pedig teljesen heterogén környezettel is.
"melyik nem igenyel atalakitast a rendszerben" - az, amikor nem csinálsz semmit.

A network-to-network routingra már lent több válasz érkezett.

Üdv,
Marci

( answ | 2015. 10. 13., k – 21:21 )

Halozati namespacek?

wan namespace-be berakod a wan-t es itt inditod a pppoe kapcsolatot. Aztan letrohozol a globalis es a wan namespace kozott egy veth pairt. Erre felhuzol ket db publikus te altalad birtokolt (de nem hasznalt) ip cimet (igy biztos nem lesz utkozes se wan tartomannyal, se lokalisan). A globalis namespaceben default route a veth wan-ban levo ip cime fele. wan namespace-ben NAT a pppoe kapcsolat fele.

Igy belso halon es VPN-en is barmilyen halozat lehet, nem fog a wan halozat bekavarni.

Legalabbis azt hiszem.. de fix me..

( hzsolt94 v | 2015. 10. 14., sze – 00:06 )

Bár ez rajtad nem segít, de a szolgáltatóknak 100.64.0.0/10 -et kellene használni, ha már NAT, nem pedig a 10.0.0.0/8-at.

Ez akkor is elodázása a problémának. Nekik így kényelmesebb, olcsóbb, az ügyfél meg kit érdekel? Majd panaszkodik, ha éppen tudja, hogy miért szív bizonyos eszközökkel. Vajon hány ügyfél képes arra saját erőből, hogy kiderítse, hogy a szolgáltatója miatt lettek gondjai, mert kommunikáció nélkül privát tartományba rakták?

( hrgy84 | 2015. 10. 21., sze – 09:38 )

Figyelj csak, egy kerdes. Tudom, hogy elegge drasztikus megoldas, de azt nem lehetne csinalni, hogy megszunteted a 10.0.0.0/8 hirdeteset es felvagdosod a halot perhuszonnegyekre, majd ujraosztod az IP-ket? Sokkal kevesebb problemad lenne, bar nyilvan kiallas...
--
Blog | @hron84
Üzemeltető macik