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!
Hozzászólások
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.
A gond akkor van, ha subnet-utkozes van, pl. a mobilnet es a privat halo is a 10.42.0.0/16-ra hirdeti be magat, ilyenkor nem tud a telo kulonbseget tenni.
--
Blog | @hron84
Üzemeltető macik
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
4.x, 5.0s droidon betöltöm WiFi-n a "jelentkezz be, paraszt" oldalt, mellette, míg nem jelentkezek be, mobilnetről megy a Facebook chat.
egy ideje így megy ez, nekem, mint usernek meg kényelmes.
--
blogom
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
Én csak erre reagáltam:
> Hogy a náthásba tud egyszerre wifi-n és mobilneten lenni a kütyü?
szóval az Android tipikusan csinál ilyet, hogy egy WiFis belső hálón, s a mobilneten egyszerre kommunikál.
A többi részéhez nem értek.
--
blogom
Ok azt meg is értettem. és kifejtettem, hogy számomra nem olyan húdejó.
--
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
Ezt írtam én is, hogy csak az eszközön... De a kérdező szerint a hálózaton is probléma van.
--
openSUSE 13.1 x86_64
én azt nem értem, hogy jön ide a wifi
A kérdező írta:
"megszaporodtak az IP tartomány ütközésből eredő routing konfliktusok, főként, amióta megszaporodtak a mobil eszközök"
Illetve lentebb van szó róla, hogy behozzák a mobil kütyüvel a mobil netet. Tehát...
--
openSUSE 13.1 x86_64
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.
lehet nem értek hozzá eléggé, vagy nem teljesen értem a problémát, de ha VLAN-okra van osztva minden, akkor hogy tudnak ütközni?
Addig nincs gond, amíg nem kell a két hálózatnak egymással beszélgetni. Abban a pillanatban, amikor kell, akkor felmerül a kérdés, hogy a 10.1.2.3-a IP-cím hol van, ha mindkét oldalon lehet :-P
Szerintem a /16al ne cseszekedj, elég rég CIDR van még, és a kisebb maszkkal sokkal könnyebb nem ütközni.
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.
Köszönöm a megerősítést.
Eccer dolgoztam egy cegnek, ahol 192.1.2.0/24 volt:)
t
Szerintem annak a cégnek jó sokan dolgoznak ;)
Magas labda, de fc00::/7 szerintem elég nagy, hogy ne legyen ütközés:)
Nyugalom, a teljes adatforgalmunk több, mint 50%-a IPv6 felett megy. Oda viszont nem osztunk privát címeket, nyilván NAT sincs.
NAT lehetősége IPv6 esetén is megvan, annó teszteltem a Linux kernel IPv6 NAT-ját.
http://hup.hu/node/120706
Egyébként ebből a szolgáltatói 10.x.x.x -ből is jól látszik, hogy bár nem lesz zökkenőmentes, mégis az IPv6-ra ideje átállni a világnak.
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.
Hogy jonnek be a mobil eszkozzel?
(Nem biztos, hogy orulnek ha a belso halozatomat osszekotne a felhasznalo egy masik halozattal)
+1 hát vagy a mobilnetet használja, vagy a te hálózatodat. Egyszerre a kettőt miért? VPN?
Ezt kérdezd meg a júzertől, akinek a BYOD eszközét a maga fizikai valójában még sose láttam.
Ertem BYOD, de hogyan kapcsolodik? WiFi, VPN? Ha BYOD-kent hasznalja a halozatot, akkor a masikrol szakitasd le. Hasznalj VRF-et...
De komolyan, mi indokolja, hogy hirdesd az egész /8-at? így gyakorlatilag mindig szívni fogsz, ahelyett, hogy csak akkor, mikor ténylegesen ütközés van.
A '90-es évek közepén ez teljesen észszerűnek látszott. Akkoriban még nem lehetett "előregyártott" NAT-képes eszközöket kapni, azt pedig pláne nem gondoltuk, hogy az RFC ellenére egyszer a külvilágból is privát címek fognak beköszönni.
Ez nyilván önmagában nem megoldás, egyszerűen csak nem értem, minek hirdetni feleslegesen egy ekkorát. Ezzel csak tetézed.
"külvilágból is privát címek fognak beköszönni"
Hogyan?
> Hogyan?
Például így: (ez egy UPC netkapcsolat)
vagy így: (ez egy DIGI netkapcsolat)
Ez az eszkoz a tied? router.polihaz.hu (89.135.125.78) milyen route van benne?
Enyimé. A UPC kapcsolat egy 89.135.125.76/30 subneten érkezik, ahol 89.135.125.77 vagyok én, és 89.135.125.78 a gateway.
Meg mindig nem ertem ebben a peldaban nem kell hogy a 10.0.0.0/8-as tartomannyal problema legyen.
Sot meg a Digi-s peldanal sem.
10.0.0.0/8-as tartomanybol az eszkozodre a szolgaltato iranybol nem kene kapnod csomagot, ha kapsz akkor a szolgaltatot megkell bubolni.
+1
Akkor búbold meg nekem kérlek a DIGI-t.
Ez a DIGI PPPoE kapcsolat:
és az internet routerednek muszáj tudnia a belső hálózati címeidről?
(ha igen, akkor még mindig ott a lehetőség a routing domainok használatára, én 2 digis netet kezelek így egyetlen routerrel egyszerre, pedig mindkét digis netnek 10.0.0.1 a gw...)
+1 Routing domain ftw
Amikor felhuzod a ppp0 interfacet hogyan nez ki a route tabla?
Ilyen?
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default DIGIPUB-GW_IP 0.0.0.0 UG 0 0 0 ppp0
IP * 255.255.255.240 U 0 0 0 ppp0
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.
A problémafelvetés első és második pontja nem VPN-ről szól. Olvass.
Alkalmazz belso es kulso tuzfalat es a ketto kozott tranzitt vlant/zonat alakits ki.
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)
Please leave write only mode.
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
Ez ilyen álj át a sötét oldalra komment. :-D
Reménykedem benne hogy elterjed az IPv6 mielőtt széthullik az internet :-(
A jelenleg üzemelő, illetve a boltok polcain lévő SoHo cuccok hány százaléka képes natívan, eredeti firmware-rel IPv6-ra?
Az én polcaimon lévő eszközök 100%-a. Évek óta figyelek erre.
Inkább elkerülni a helyzetet DirectAccess-szel vagy alkalmazás-publikálással?
Üdv,
Marci
Ezek kozul melyik halozati megoldas, es melyik mukodik heterogen (nem kizarolag MS cuccokat tartalmazo) halozatokban? Also, melyik nem igenyel atalakitast a rendszerben (mert azt valoszinuleg vagy ido vagy penzugyi koltseg miatt nem fogjak engedni)?
--
Blog | @hron84
Üzemeltető macik
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
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..
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.
Miért nem segít? Használja Ő azt. Elvégre Ő is ISP, vagy nem? ;)
--
openSUSE 13.1 x86_64
Telekom 100-as IP-t ad NAT-kor nekem. Úgyhogy vagy Voda, vagy Telenor lesz a 10.
--
http://naszta.hu
Nekem Voda nyilvános IP-t ad. Marad a Telenor...
--
openSUSE 13.1 x86_64
feliratkozás
+1
+1
Lazán kapcsolódik: http://index.hu/tech/2015/10/19/vigyazzon_ha_a_telekom_privat_ip-re_rak…
Már nem csak mobil eszközök jelentenek gondot. Igaz, ez még otthoni felhasználókra vonatkozik. Nagyon fogynak a címek, és nem látom a megoldási hajlandóságot az ISP oldalon.
Miért, mi lenne a megoldás?
IPv6
Persze.
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?
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