Kérdésem, hogy ki használja a shorewallt?
Nem ismertem eddig. A múltkorában viszont muszáj volt belemélyednem. Röviden: örököltem egy rendszert egyik ügyfélnél, az a helyzet volt, hogy áramszünet volt, megállt a tűzfal. Majd elindult, de nem megy a net. Én voltam a szerencsés, akinek ki kellett menni megnézni. Akkor láttam először shorewallt. Elvileg az ég világon senki nem nyúlt hozzá hetek óta (gyakorlatilag sem, se login nem volt azóta, se a konfig fájl módosítási dátuma nem változott), tegnap még ment, most elindulás után nem. Guzgliztam, néztem manualt, fórumokat, példa tűzfal konfigokat, hogy mit hogy kell, elvileg minden rendben találtam, mégse megy. Teljesen tanácstalanul elkezdtem random átírni, illetve kikapcsolni dolgokat, interfészeket megfordítani, semmi. Az OS Ubuntu 10.04 volt. Többször rebootoltam, semmi. Kb. 2 óra helyszíni mókolás után széttártam a kezem, visszatettem egy az egybe azt a konfigot, amit lementettem még azelőtt, hogy belenyúltam volna, shorewall restart, és megy... Nah mondom itt megyek nyugdíjba. Otthagytam.
Két nap múlva reggelre úgy sikerült, hogy ugyanebben a gépben a már amúgy is féllábú raid1-ből megdöglött a másik diszk is. Abszolút semmit nem lehetett a diszkről menteni. Na "hálistennek" akkor újratelepíthetem, rakhatok rá centost ubuntu helyett. (Egyébként pont aznap reggel hozta meg a futár a megrendelt új diszkeket... :) A két nappal ezelőtti kinlódást meg betudtam annak, hogy már biztos akkor is szar volt a diszk.) Egy NAS-ra volt mentés, onnan lett visszaállítva az előző nap éjszakai. Az új diszkekre új rendszert, a mentésből a konfigok egy-az-egyben vissza lettek másolva, néhány apró módosítás kellett ubuntu-centos különbségek miatt. Minden megy, a shorewall nem. start OK, minden fasza, logba hiba nincs, mégse natolja a v4-et. Megint elkezdtem szórakozni, hogy kivettem dolgokat, interfészeket piszkáltam, semmi. Reboot megvolt hatszor, semmi. Szintén kb. 1,5 óra után OK, akkor kezdjük előről. Kipucultam mindent, elkezdtem újra kézzel megcsinálni. Alap szabályok, teszt a szerverről, megy a net. Hozzáadtam a maszkolást, teszt egyik kliensről, megy a net. Visszatettem egyesével a port forwardokat, teszt, az is megy. Nah minden megy. Ekkor kiváncsiságképp megnéztem, hogy miben sikerült mást csinálni, mint a NAS-on lévő, egyébként működő mentés: SEMMIBEN. Tabulátorokat, újsorokat, megy egy-két (működés szempontjából jelentéktelen port forward) szabály sorrendjét leszámítva tök ugyanaz. Hihi, akkor kimásoltam amit gyártottam izzadságos manual és doksi olvasgatás árán (ekkor ismerkedtem meg vele jobban), visszatettem a NAS-on lévő mentést egy az egybe, restart... Mostmár az is megy. Ilyen nincs, le***pom magam...
Mindegy, működik ez is, minden megy az újratelepített gépen. Bye-bye, tűz a következő helyre... Bár a napirendemnek már rég lőttek.
Gondoltam jó lesz ez, kipróbálom pár helyen, ahol kicsit komplexebb tűzfal kell, mert a centos alap tűzfalával, vagy susen a susefirewall-al ha egy kicsit bonyolultabb dolgot kell megcsinálni, az nem olyan egyszerű már. :)
Múlt héten telepítettem egy kis tűzfalat (szintén centos), mögötte 3 kliens (fedora). Teljesen jól működött. Simán NAT-ol a klienseknek, van 3 port forward a három SSH-hoz, meg annyi, hogy a tűzfal külső lábán az SSH-k és ping kivételével minden DROP szabály.
Ma szólnak, hogy nem érik el a klienseket... Belépek a szerverre, tovább a kliensre, megy. Lépek közvetlen az egyik kliensre.... Rohadt lassan, de bement. Lépnék a másikra, nem megy. Lépnék megint az elsőre, mostmár az se megy. SSH szerverre, ssh tovább kliensre, pingelek kifele, nem megy, nincs válasz a külső NS-től... Az mondom mi. Nézem a bind logot, nem is jut el oda a query... Nézem a szerveren a logokat, semmi. shorewall restart, semmi. Konfighoz a kutya hozzá nem nyúlt. Rebootolom, megint megy... Ehhez mit szóljak? Ez egy hulladék ganéj...
- 11949 megtekintés
Hozzászólások
clearos.
nagyon bevállt, több helyen is.
- A hozzászóláshoz be kell jelentkezni
Én pár éve használtam shorewall-t Debian alatt. Hiba nélkül, jól működött.
Restart előtt mindig lefuttattam a "shorewall check"-et, ami hamar kidobta a konfig hibákat.
A fentiek alapján nem lehet, hogy bootoláskor az ethernet interfészek más sorrendben lettek beszámozva? Ez megmagyarázná, hogy az egyik induláskor minden jó, a másik esetben semmi sem működik.
Ezzel az interfész átszámozással viszont már szívtam Ubuntu alatt, amit végül kézzel kellet fixálni, valahogy így: https://help.ubuntu.com/10.04/serverguide/network-configuration.html
- A hozzászóláshoz be kell jelentkezni
Nincs konfig hiba, mert akkor a restart is sikertelen.
Nem cserélődnek az interfészek, az kéne még...
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
+1 az ethernetek sorrendjére.
Igen alattomos tud lenni, mert ha az ethernet kártyák kb ugyanolyan gyorsan élednek (pl mert ugyanaz a típus) akkor bootról bootra változhat a kártyák logikai neve.
A megoldás a /etc/udev/rules.d/ könyvtárban levő persistent-netrules.conf megfelelő megváltoztatása ahogy az kolléga által linkelt lapon is van írva.
- A hozzászóláshoz be kell jelentkezni
Hogy változna már, amikor UUID-hez és/vagy MAC-hez van kötve a hálókártya neve? (centoson alapból mindkettőhöz)
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Ez eltűnt debian-ból (persistent-netrules.conf ), tudod mi az új módszer erre?
- A hozzászóláshoz be kell jelentkezni
létrehozni próbáltad?
- A hozzászóláshoz be kell jelentkezni
Én használok shorewallt több helyen is, van ahol két tucat lába van a tűzfalnak, de mindenhol minimum 5. Soha semmi gondon nem volt vele, ipset is szépen megy vele.
Annak van nyoma logokban, hogy a nem működő állapotban eldobja-e a csomagokat?
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Eddig nem láttam.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Gondolom itt azt lenne érdemes kideríteni, hogy iptables, routing, stb. szinten (amihez a shorewall hozzányúl) mi történik.
Iptables save, meg routing táblát egy fájlba menteni, stb.
Így gyorsan kiderülne, hogy mi is itt pontosan a helyzet, mi változik.
Én egyébként egyszerű konfignál használtam Debian alatt, évekkel ezelőtt és még most is fut hibamentesen.
Nekem tetszett, de azért foglalkozni kell vele, nem olyan egyszerű mint mondjuk az ufw.
♲♻♲
- A hozzászóláshoz be kell jelentkezni
Igazad van, ez nem jutott eszembe, legközelebb lementem és megnézem hogy van-e diff az aktuális és működő állapot között.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Legalább 10-15 gépen használom folyamatosan 5+ éve, soha semmi bajom nem volt vele még.
- A hozzászóláshoz be kell jelentkezni
Van akinél valamilyen csoda folytán az ubuntu is ilyen... :)
Nekem a múltkor már nyelvválasztásnál kifagyott a telepítő. Aztán következő nekifutásra végigment, a telepítés végén még valamit csinált telepítés befejezése, beállítások véglegesítése vagy valami hasonló címszó alatt, kb. 1,5-2 órája "állt" itt a telepítő, közben folyamatosan tekerte a diszket, ekkor meguntam és RESET... Mintha valahogy érezné, hogy utálom. :) És ez csak a legutóbbi élmény az ubuntuval.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
shorewall compile /etc/shorewall testscript
ebben lesz a vegeredmeny, ez egy bash script, ezt futtatja le, regiment iptables sorral.
onmagaban ez a script is futtathato (start, stop)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Esetleg átírnád a címet?
Cím alapján sebezhetőségre vagy valami komoly bajra gondoltam, de valójában ez egy kérdést tettél fel. Meg aztán amíg nem biztos hogy a shorewall a hibás ne riogassuk az embereket.
- A hozzászóláshoz be kell jelentkezni
Hálókártya csere elsőkörben. Szerintem a log tele van hányva eth down/up sorokkal.
--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!
- A hozzászóláshoz be kell jelentkezni
Nincs semmi ilyen. Illetve két, független gépen is produkált már ilyeneket. Amit múlt héten csináltam, az zsír új.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Szia!
Remélem jól értettelek.
Ha igen akkor ez esetben a nem maradtak ki véletlenül ezek:
/etc/default/shorewall-ban startup=0 csere startup=1
Illetve:
/etc/shorewall/shorewall.conf-ban IP_FORWARDING=Keep csere IP_FORWARDING=Yes
Cs
- A hozzászóláshoz be kell jelentkezni
startup egyesen van, anélkül shorewall start se menne.
ip_forwarding is on természetesen.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Szia!
Bocsáss meg kérlek!
A shorewall össze kapcsolója, közte a start is megy a "startup egyesen"nélkül is.
Azt csak az init-script vizsgálja.
Igy nem menne: # service shorewall start de igy igen: # shorewall start
Cs
- A hozzászóláshoz be kell jelentkezni
Szerencsere a shorewall.conf -ban is van egy STARTUP_ENABLED=Yes, ami viszont beblokkolhat startup egyesnel is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
En is interfesz-mizeriara gyanakszok, bar igy utolag mar kiderithetetlen, mi tortent.
Ami biztos: a shorewall csak akkor indul el, ha engedve van neki (ket helyen lehet, az /etc/default/shorewall startup=1, es a /etc/shorewall/shorewall.conf -ban is van egy hasonlo valtozo, most nem tudom a nevet), es ha a konfiggal szintaktikailag minden OK. minden mas esetben coki van, tuzfal meg nincs, de pont ezert erdemes monitorozni is az indulasat, a /var/lib/shorewall alatt frissit fajlokat sikeres indulasnal, ezt kell nagios-sal monitorozni.
A shorewall parancsnak amugy eleg sok alparancsa van, erdemes egy helpet kerni tole. Akar dinamikusan is allitgathatsz benne dolgokat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Sokadik ember írja, de értsétek meg, hogy nem az indulásával van baj. [OK], status RUNNING, log szerint start rendben volt, de mégse ment.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Igen, ezt mind megertettem en is, meg a tobbiek is, csak mivel nem ismered a Shorewall mukodeset, leirtam, hogy hogyan mukdik.
Azt is leirtam, hogy mire gyanakszom: en is az interfesz-atszamozodast tippelem problemanak. Egy fixen jo shorewall konfigot csak ez az egy dolog tud elrontani, ha maga a konfig nem valtozik erdemben.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Szar halokartya. Shorewall stabil, ha megy, akkor megy, menet kozben nem fog meghulyulni.
tshark-kal nezd a forgalmat.
- A hozzászóláshoz be kell jelentkezni
És azelőtt nem volt szar, meg azóta nem szar?
Illetve az új gépben is szar mindkettő?
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Nem tudom, en sose talalkoztam olyan halokartyaval, amelyik 15 nappal elotte bejelentette volna, hoyg be fog dogleni. Olyannal mar sokszor, amelyik neha ment, neha nem. Ez egy szerver volt es nem indexlampa, szoval csereltem.
Nezd azert meg a kernel logot, nem ugral-e a device pl. De hasznalhatsz tsharkot is, pl valamit pingelve.
- A hozzászóláshoz be kell jelentkezni
amugymeg "iptables -L", oszt' rogton latod, hogy van-e tuzfal vagy nincs
- A hozzászóláshoz be kell jelentkezni
Néztem én, ránézésre minden rendben volt.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Visszatérve a témára, ez a shorewall jó cucc, azóta több helyen is használom, de nem egy stabil jószág, vannak stiklijei. A sok reload/restarttól is meghülyül egy idő után. Nem veszi be a konfigból az új dolgokat, elmegy a nat, vagy a port forward... Hiába restart, stop+start. Gép restart megoldja.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Ezt en IPtables nyugnek erzem, ezen belul kernelproblemanak. Mivel a shorewall gyakorlatilag egy IPtables rule generator, szinte biztos vagyok benne, hogy e teren a shorewall nem bugos, raadasul a tapasztalatok is azt mutatjak, hogy akarhany restart/reload ciklust jol bir, kulonosen, mert en automatikus konfigmenedzsmentbol is hasznaltam sokat, es amig ra nem jottem, hogy hogy lehet kikuszobolni, addig minden futasnal (akkor is, ha nem valtozott semmi) restartolta a tuzfalat, ezt kb. 1000 futas utan tudtam megszuntetni. Mivel tesztgep volt, igy nem volt issue, hogy restartolgat a tuzfal rajta.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg nem iptables, mert más tűzfallal nem tapasztalta ilyet. Illetve a shorewall valahogy próbál sakkozni, hogy megnézi szerinte mi változott, és szerintem csak azt tölti újra, illetve a kapcsolatokat sem dobja el restartkor. Úgy gondolom itt megy félre valami. Nem néztem részletesebben utána, mert egyrészt ha megáll, akkor erre nem nagyon van idő, másrészt a legenerált mindenféle rule-okból meg táblákból 6-7 interfész esetén már nem piskóta kibogarászni, hogy akkor most mivan, több interfészes gépnél meg mégdurvább.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Restart eseten, foleg ha stop + start -tal is probalkoztatok, akkor egeszen biztosan nem akar okoskodni. Esetleg reloadnal.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Nincsen reload.
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni
Ja. Disztroja valogatja egyebkent, van, ahol a restart = stop + start, es reloadnal refreshelnek.
Mindenesetre en megtanultam a shorewallnal, hogy ha nem megy az /etc/init.d/shorewall restart, akkor stop + iptables -F + start biztosan megoldja (mondjuk nekem ilyen bajom csak iptables modul betoltessel volt, elsore nem tudta betolteni a szukseges modulokat).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Hmm ez a kézi flush eszembe se jutott, legközelebb megpróbálom... :)
--
The Community ENTerprise Operating System
- A hozzászóláshoz be kell jelentkezni