Hozzászólások
-
SzerzőBejegyzés
-
Sziasztok ismét!
Hát nem SOHO switch, hanem egy Cisco Catalyst 2950-es. Én már nagyon sok mindent kipróbáltam, és arra jutottam, hogy feladom… Igazából másképpen is meg lehet oldani, mégpedig úgy, hogy marad a gépben egy interfész, azon fog futni a samba is a belső háló felé, mivel közvetlenül eléri a belső háló ezt az interfészt. A netre nem kerül ki a szolgáltatás, mert a netről befelé jövő forgalom teljes egészében le van tiltva, az összes port zárva van kifelé, kivéve a 80; 443; 20; 21; 22.
Így gondolom nem vet fel nagyobb biztonsági aggályokat annál, mintha két interfész lenne a gépben, külön publikus és külön privát?!KÖSZÖNÖK MINDEN SEGÍTSÉGET!!!
Üdv., ismét!
No, kipróbáltam mindent, amit mondtatok, de nem ment, viszont bekukkantottam a rack szekrénybe. Háááát… érdekes dolgot tapasztaltam: a szóban forgó gép mindkét hálókártyája egyazon switch-re van dugva fizikailag, DE logikailag nem. Ezalatt azt értem, hogy a switch portjai szegmensekre van osztva VLAN segítségével, így külön alhálózat, illetve teljesen külön IP tartományba esnek az egyes szegmensek portjai. Ez látható is az ifconfig kimenetén.
Kérdezem én az okosabbaktól, mivel már másra nem tudok gondolni, ez lehet a hiba?? Hogy emiatt egyáltalán meg sem oldható ilyen felállásban?
Ja, azt elfelejtettem, hogy az IP spoofing protection kikapcsolásával a belső szegmensről „elértem” mindkét IP címet, de kívülről a külső nem látszik, ha mindkét interfész áll, tehát ez így nem nyerő…
gendelider wrote:– (Legalább) a pirossal jelzett két sor nagyon gyanús, 2 db 0.0.0.0 genmaskkal, mindkettö gateway.
– nincs default gatewayed. (javítottam, véletlenül routert írtam)Ha csak az eth0 interfész aktív, akkor ez van a route táblában, és így működik:
195.199.xxx.104 0.0.0.0 255.255.255.248 U 0 0 0 eth0
0.0.0.0 195.199.xxx.110 0.0.0.0 UG 0 0 0 eth0Eddig is így ment.
Hmm… Most tűnt fel egy furcsa dolog. Ha a route is first-fit módszerrel működik, akkor meg lehet a hiba oka.
Ugye az eth1 lett utoljára aktiválva.
Az eth1 route-ja, itt megelőzi az eth0-t:0.0.0.0 10.251.190.254 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 195.199.xxx.110 0.0.0.0 UG 0 0 0 eth0így lehet, hogy csak és kizárólag a 10.251.190.254 gateway-en keresztül közlekednek a csomagok…
Talán a default route lehet a megoldás? De mit adjak meg default route-nak? Az eth0 interfész átjáróját?
Mellesleg a route táblához sem nyúltam azt kizárólag a kernel konfigurálta…
tovis wrote:Te, ezeket a 0.0.0.0 -ás címeket honnan szedi a route? – ilyet még nem láttam;x
Állítsd le atűzfalat és nézd meg mi van az /etc/interfaces/if-up részekben, ill. ha nem itt van akkor valamelyik (szerintem általad) megbuherált scriptum produkál ilyen csodákat.
Pingelni lehet a 0.0.0.0 címet? – és ki válaszol.Gőzöm sincs, hogy honnan szedi… A /etc/networks fájlban csak az egyik hálózati cím van felvéve, localnet névvel, mégpedig a külső. De én csak azt nem értem, hogy hogyhogy egyszer az egyik, másszor a másik megy, attól függően, hogy melyiket indítottam el később… if-up, stb. minden üres, az iptables init scriptként indul. Semmi mást nem buheráltam. De az iptables táblák ürítése után sem megy!! Pingelni lehet a 0.0.0.0-t, és helyette, érdekes? módon a 127.0.0.1 válaszol!
Sztem csak a route táblában lehet a hiba, de gőzöm sincs, hogy mi…
Szerintem valami kimarad a sztoridból. Nekem úgy tűnik hogy tűzfallal játszol;o)
Tűzfal beállításai:
iptables -A INPUT -i eth0 -p tcp -s 195.199.xxx.xxx –dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -s 195.56.0.0/16 –dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp –dport 22 -j DROP1. Honnan tudja a kernel melyik interfész melyik?
Így van, amelyiket a kernel előbb észleli, ami pedig az eth0 (Realtek RTL8029), illetve utána észleli az eth1-et, ami egy integrált VIA Rhine II-es…
Tehát nem ugyanolyan típusú a két kártya, illetve mindig az eth0 modulja kerül először betöltésre.2. Ha rendben mükszik az eth1 -ed akkor mi van az eth0 -val, azaz mit mutat az
kisbetu wrote:Biztos, ami biztos, meg kéne vizsgálni a zinterfészkek címeit.
Mert ha netán egy csoportba címeztetted őket, akkor csak a Megváltóban bízhatsz.Csoport alatt alhálózatot értesz? Az eth0 publikus fix ip címmel rendelkezik a sulinet pool-ból, azt eth1 pedig privát, dhcp által kiosztott címet kap.
Én valamiféle route tábla problémára gyanakszom, vagy nem tudom…
razoli wrote:Mi szerepel abban az interfaces file-ban?
Csomagszűrést állítottál be? Működött már korábban ez a felállás?interfaces tartalma:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).# The loopback network interface
auto lo
iface lo inet loopback# The primary network interface
auto eth0
iface eth0 inet static
address 195.199.xxx.xxx
netmask 255.255.255.248
network 195.199.xxx.xxx
broadcast 195.199.xxx.xxx
gateway 195.199.xxx.xxx
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 195.199.255.4 195.199.255.57 195.199.255.58
dns-search x.sulinet.huauto eth1
iface eth1 inet dhcpComagszűrés van az eth0-ra, de ez nem befolyásolja. Kiürített iptables táblákkal sem megy sajnos… Nem, eddig még nem volt ilyen felállás.
No, és ha az interfaces fájlban az eth1 bejegyzései az eth0 előtt vannak, akkor csak az eth0-on működik a kapcsolat, így pedig csak az eth1-en. Tehát mindig csak az utolsó bejegyzésen hajlandó működni…
-
SzerzőBejegyzés
legutóbbi hsz