Sulinetes cisco switch mögött 2 interface

Hálózatok egyéb

Sulinetes cisco switch mögött 2 interface

  • 1773 megtekintés

( sitya | 2006. 02. 02., cs – 10:39 )

Szia!

Nem tudom, hogy megoldódott-e már a problémád... Nekem is hasonló volt... A megoldás annyi lett, hogy csak a nyilvános portot használom, így nem beszél össze a két kártya, viszont a switch jóvoltából a belső szegmensek egymásközt névfordítás (portfordítás) nélkül megy a kommunikáció (ez az alapbeállítás), így gond nélkül címezhető.

Üdv,
S

( boobaa | 2006. 02. 02., cs – 10:52 )

[quote:cdb0da8026="sitya"](...)viszont a switch jóvoltából a belső szegmensek egymásközt névfordítás (portfordítás) nélkül megy a kommunikáció (...)

Halkan jegyzem meg, hogy nem a switch, hanem a router jóvoltából, így a szerver és a belső hálós gépek között csak 10Mbitet sikerült elérni (úgy tűnik, hogy a switch két szegmense között csak a routeren át vezet út).
Ez volt a másik ok, hogy inkább behajítottunk még egy NIC-et a szerverbe, belső, 100Mbites lábnak.

( lacmuch | 2006. 02. 02., cs – 11:01 )

Igen, én is azért dobtam bele még egy nic-et, hogy ne csak a routeren vezessen át az út + így ki tudom használni a switch 1000 mb-s portját befelé. De szenya módon a www.linuxforum.hu-n is elindítottam a témát és ott azt mondogatják, hogy ipforwardingal a külső interfacén megjelenő belső csomagokat irányítsam át a belső interfacére...helyi routolás...most ezzel küzdök épp ezt olvasgatom: http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Mi a véleményetek erről?

....amúgy etikátlan, hogy két fórumon is kérdezgetek???

( lacmuch | 2006. 02. 01., sze – 17:33 )

Sziasztok!!!

Egy számomra furcsa problémával fordulok hozzátok!
Egy sulinetes switch mögött van egy Debian serverem 2 hálózati kártyával. Az egyik a külső kéréseket intézi, külső IP címmel (195.199.....) a másik pedig a belső kéréseket (10.250.......). Mind a két kábel a sulinetes Cisco switchre van felkötve: a külső a külső szegmensbe amihez a külső ipcímek vannak hozzárendelve a belső meg a belső gépeket kiszolgáló DHCP-vel ellátott, internet megosztást is végző szegmensbe. A switch mögött természetesen egy Cisco router irányítgat.

NA! A problémám pedig az, hogyha a belső gépek a külső interfészt akarják elérni (tehát a külső 195.199-el kezdődő IP-t) akkor a server eldobja a kéréseket, természetesen a belső interfészt tökéletesen el tudják érni. Ha le ifdown-olom a belső interfacét akkor egyből el kezd működni a külső ip elérése, ha átrakom a belső interfacet más ipcím tartományba (tehát nem a router által kiosztott ip tartományba) akkor is elkezd működni.
A log fájlokból kiokumlálva megfejtettem, hogy :D az elérés a külső interfacen is belső címmel történik, tehát a router nem NAT-olja a belső gépek elérését.
Arra gyanakszom, hogy az okozza a csomagok elveszését, hogy a külső interfacen a belső interfészhez hálózatába tartozó csomagok jelennek meg és nem tud a kernel ezzel a "nap-hold" együttállássssssal mit kezdeni....
Érdekes módon az NT-sem és a SuSE linux sem csinálja ezt. Nekem amúgy egy Debian 3.1r1a Netinstall-om van 2.6-os kernellel.

Vajon hogy lehetne elérni, hogy mégiscsak el lehessen érni a külső interfacét belülről?

Üdvözlet!

( cruiser | 2006. 02. 01., sze – 18:46 )

Lehet, hogy félreértem, de nincs itt valami zavar? A belső gépek nem akarhatják elérni a külső interfészt, mert eleve nincsenek egy hálózatban. Ha hálózaton kívüli ip-t céloznak meg, akkor a gateway-nek küldik a csomagokat, az meg, gondolom, a szervered belső lába. A szervered meg elvégez egy NAT-ot. Nem ez van?

( boobaa | 2006. 02. 01., sze – 19:00 )

1. Miért nem használod a szervert a belső gépek átjárójának/tűzfalának/dhcp szerverének? Ja, ahhoz le kéne tiltatni a sunyinyetes dhcpt.
2. A belső gépeid miért a szerver külső lábát akarják elérni? Jahogy a sunyinyet oda old fel... Használj saját dhcp-t (a fentiek szerint), ami megadja a szervered belső lábát dns-nek, és természetesen a szervered csak befelé szolgáltasson dns-t, azt is csak a belső hálóra (vagy esetleg a külső cuccokat gyorstárazza).
3. @cruiser: láttál te már ilyen sunyinyetes default installt? Az minden, csak nem konfigolható a helyiek által, másrészt alapértelmezésben ofcoz _nem_ a szervert adja meg a sunyinyetes dhcp átjárónak, lévén nem is tud róla, hogy a szervernek van egyáltalán belső lába...
Na ezért volt az egyik első dolog a sunyinyetes dhcp leállíttatása, saját szerver normális konfigolása két lábbal úgy, hogy befelé ő osszon dhcp-vel ip-t/dns-t/átjárót, utóbbi kettőre saját magát, hogy ne kelljen minden aprósággal (amit fél perc alatt elintézel a szerveren) a forms.sulinet.hu-ra szaladgálni és várni (nem egyszer) napokat.

Összességében tehát: egyáltalán nem furcsa ez a dolog, épp ezért nem is nevezném problémának, csak egy kicsit utána kell nézni és át kell gondolni, hogy sunyinyeték hogyan oldják meg a hálózatosdit helyetted, és hogyan lehet mégis (amennyire lehetséges) saját kézbe venni (legalább a belső háló üzemeltetését).
@lacmuch: ha érdekel konkrét megoldás, küldj püt.

( lacmuch | 2006. 02. 01., sze – 19:21 )

A sunyinyetes :D :D cuccok végzik a dhcp-zést dns-ezést masquarédelést... és a belső gépek el tudják érni a külső interfacét mert a sunyinyetes router tudja, hogy mi van a saját hálózatán, ezért átroutolja oda... és a serverem külső interfészén meg tudnak jelenni a belső hálóról érkező csomagok...viszont valamiért a szerverem eldobja őket.

Köszönöm amúgy a hozzászólásaitokat, teljes elkeseredésemben fordultam a fórumhoz... Szeretném ha a szerverem nem végezne dhcp/dns/routing műveleteket, hogy minnél egyszerűbb dolgom legyen és ne kelljen arra is figyelnem...amúgy nem fontos nagyon a dolog csak azt szeretném elérni, hogyha pár "nemhozzáértőfelhasználó" meg akarja nézni belülről a sulis weblapot, akkor ne sírjon, hogy nem megy a "www.iskolámcíme.hu" a másik meg, hogy néhány PHP-s alkalmazás a cookie kezelése miatt, vagy csak egyszerű nemtörődömségből fakadó hibája miatt nem megy akkor, ha 2 címről is elérhetővé akarom tenni.

És azt esetleg megtudnátok nekem mondani, hogy milyen routolási parancsal lehet elérni, hogy az eth0-s interfacére érkező 10.xxx.xxx.xxx-es célcímű csomagokat átirányítsa az eth1-es interfacéra?

( boobaa | 2006. 02. 01., sze – 19:38 )

Ahogy gondolod. Nálunk gond nélkül működik minden általad említett dolog, igaz, a fentiek szerint (amit lehet, megcsinálunk házon belül, beleértve a dhcp/dns/NAT/routing adminisztrálását is).

( cruiser | 2006. 02. 01., sze – 19:42 )

az, hogy a külső lábra érkező belső csomagokat eldobja a géped, simán elvárandó, alapbeállítás egy csomagszűréskor, ha nem ez volna, az volna a baj. (vagy még mindig nem világos nekem a dolog. :) ) tedd csak azt, amit bobbbaa kolléga írt!

cruiser: láttál te már ilyen sunyinyetes default installt? Az minden, csak nem konfigolható a helyiek által
Na ezért volt az egyik első dolog a sunyinyetes dhcp leállíttatása, saját szerver normális konfigolása két lábbal

én értem, nálam is ez volt az első... :)

( covek v | 2006. 02. 01., sze – 20:14 )

[quote:71cb839e49="lacmuch"]Szeretném ha a szerverem nem végezne dhcp/dns/routing műveleteket, hogy minnél egyszerűbb dolgom legyen és ne kelljen arra is figyelnem...amúgy nem fontos nagyon a dolog csak azt szeretném elérni, hogyha pár "nemhozzáértőfelhasználó" meg akarja nézni belülről a sulis weblapot, akkor ne sírjon, hogy nem megy a "www.iskolámcíme.hu" a másik meg, hogy néhány PHP-s alkalmazás a cookie kezelése miatt, vagy csak egyszerű nemtörődömségből fakadó hibája miatt nem megy akkor, ha 2 címről is elérhetővé akarom tenni.

Egyértelműen DNS problémával van dolgunk. Hasonló volt a probléma egy környezetben. Az volt a megoldás, hogy a Szerver lett a DNS szervere a belső gépeknek és azt hazudta, hogy a www.szerver.hu az egy belső ip-vel rendelkező gép, történetesen a DNS szerver és így ment belülről és kivülről is a webszerver elérése név szerint. Minden további kérés forwardolásra került. Nem okozhat gondot egy ilyen belövése, ha én is meg tudtam csinálni. Ehhez persze a DHC szervernek meg kell mondani, hogy milyen DNS szervert osszon.

Na srácok! Megoldottam a saját problémámat :) szeretném felhívni mindenkinek a figyelmét a spoofprotection-ra, ami ezt okozza, ha be van kapcsolva. Debian alatt a /etc/networking/options fileban kell kikapcsolni (spoofprotect=no) és utána újra kell indítani a rendszert, hogy aktualizálódjon a beállítás. Üdv mindenkinek!