Sziasztok!
Egy suliban szerettem volna lecserélni, az elavult, szarrá bonyolított tűzfalat egy pfsense tűzfalra.
Egy frissen telepített pfsense tűzfalon beállítottam a NET-et a suli szubnetjére, az egyik WAN-t pedig DHCP-vel a helyi (nem a sulié!) net-re, hogy elérje az internetet. A web-es felület elérhető, beállítottam a másik WAN-t (két kijárata van a sulinek), frissítettem, feltettem pár csomagot. A kliens gép itt még közvetlenül volt a tűzfallal összekötve (egy szimpla kábellel).
A helyszínen kicseréltük a tűzfalat, és sehogy sem lehetett elérni a tűzfalat, senkit nem lehetett pingelni a tűzfalról, miközben a tűzfalon indított tcpdump-al látható volt a NET-en a forgalom (a broadcast a switch miatt), de semmi más. Az is látszódott, hogy jó VLAN-on vagyok, nincs címkézés, összhangban a switch port beállításával. Csináltam egy reset-et, újra konfig, de továbbra sem lehetett pingelni senkit, és a tűzfalat se (a tűzfal saját magát igen, a tcpdump szerint látszik a NET).
Itthon csináltam egy VLAN-t a tűzfal NET-jének, és a web-es felület elérhető, rá sem kellet rakni monitort a tűzfalra.
Végignéztem a switch (Zixel GS1900-24) beállításait, nincs benne semmilyen olyan beállítás (szerintem) ami ezt a jelenséget okozhatja.
Ezek után nincs olyan érzésem, hogy újra kicserélve a tűzfalat a suliban, akkor menni fog a dolog.
Mi a frászkarika történik itt? Számomra értelmezhetetlen a jelenség.
- 789 megtekintés
Hozzászólások
KIFÜ-s intézmény? Amióta a KIFÜ átvette a sulinet-et vannak érdekes jelenségek, ha vki saját router-t szeretne a KIFÜ-s router mögé rakni. Sokaknak nem is tetszik ez a a fajta nyomulás/gyarmatosítás a KIFÜ-től. Teljesen meggátolják/hátráltatják az informatikusokat. Mi volt a régi router? Milyen eszköz?
- A hozzászóláshoz be kell jelentkezni
Nem hiszem, hogy a KIFÜ-nek ehhez köze lenne, a sulinet-es számára a NET NAT mögött van.
A régi tűzfal egy Ubuntu 14.04, amiben két virtuális szintén Ubuntu 14.04 routol a két WAN felé (sulinet, UPC), 3 db fizikai ethernet: 2 WAN, egy NET + a NET interfészen néhány VLAN.
Az új pfsense tűzfalban van 3 ethernet port a NET, és két WAN felé. Fekete doboz szintjén ugyan az a felállás (Cser úgy történt, hogy átdugtuk a 3 patch kábelt). (A régin volt még 3 VLAN a WiFi AP-khez, meg egy VPN, de azt akkor akartam beállítani, ha a helyszínen elérem a Web-es felületet, ami ugye nem ment.)
- A hozzászóláshoz be kell jelentkezni
Pedig ha fix it álítasz sulineten , anélkül , hogy a kifü dashboardon nem rendeled össze a Mac címmel hasonló dolog történik . ;)
- A hozzászóláshoz be kell jelentkezni
És hogy a túróban bászeli meg a sulinet pfsense-vel, a WAN portján keresztül, hogy a NET-porton lévő belső hálózatán ne kommunikáljon senkivel?
- A hozzászóláshoz be kell jelentkezni
Default gateway.? Sokáig használtam pfSense-t, nekem nagyon bejött..
- A hozzászóláshoz be kell jelentkezni
A kliens kitől kapja az IP-t? Maszk, gw rendben?
( •̀ᴗ•́)╭∩╮
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek
Ha meg akarod nevettetni Istent, készíts tervet!
- A hozzászóláshoz be kell jelentkezni
A kliensek egy belső Windows Server 2012-től kapják a címeket, DHCP-n keresztül, az új tűzfalra ugyan azon a fix IP címek lettek beállítva, amik a régiben is be voltak állítva. A NET-en csak egy subnet volt beállítva (még), és ebben a subnet-ben volt a kliens is (illetve több klienssel is próbálkoztam, de hiába). A GW az ebben a felállásban lényegtelen (vagy annak kéne lennie), mivel a kliens, és az egymással (nem) kommunikáló felek ugyanabban az alhálózatban vannak, és éppen a GW-t cseréltem le, bár a címek változatlanok. Egy egyszerű tipikusnak mondható belső alhálózat 192.168.60.0/24 tartomány, viszonylag nehéz elszúrni (még nekem is).
- A hozzászóláshoz be kell jelentkezni
Mi a frászkarika történik itt?
Az általad 'NET'-ként hivatkozott hálózatról van rajzod?
- milyen egyéb eszközök vannak ott?
- van-e további szeparáció?
- swich(ek) pl biztos vannak, port security azokon esetleg nem volt beállítva?
- A hozzászóláshoz be kell jelentkezni
Nem leszek nepszeru errefele ezzel, de en azt a "szarra bonyolitott" tuzfalat eloszor is atelemeznem, hogy mi mit csinal benne, lehet, hogy okkal van annyira szetbonyolitva. Utana kellene jarni, hogy mi miert alakult ugy, ahogy, esetleg felderiteni, hogy milyen eszkozok es azon belul milyen szabalyozasok vannak elotted/mogotted, es csak akkor donteni a tuzfal lecsereleserol, ha mar erted, mi tortenik a halozatodban. Az alapjan, amit leirtal, ez a lepes nagyon kimaradt, es amint latod, szivsz is eleg rendesen.
Szoval most en visszakotnem azt a "szarra bonyolitott" tuzfalat, es raszannek egy olyan ket hetet a megertesere, hogy mit miert csinal pontosan.
En is nehezen ertettem meg, de sokszor keves az, hogy odarakok egy jol beallitott default gateway-jel rendelkezo masik gepet oszt csokolom.
- A hozzászóláshoz be kell jelentkezni
A másik tűzfalat is én csináltam, jó régen, és vissza lett kötve. A szarrá bonyolítás oka a hozzá nem értés volt, és pontosan tudom mit csinál. A túlbonyolítás a megvalósításra vonatkozik.. Mindkét WAN kijáratra van egy (virtuális) tűzfal. A fizikai gép pedig kapcsolgat a WAN-ok között, ill. csekkolgatja melyik él. Valószínűleg rosszul fogalmaztam, nem túlbonyolított, hanem körülményes, rosszul kezelhető, főleg összehasonlítva egy pfsense-vel. Az, hogy a régi tűzfalban, a virtuális gépek okán van egy rakat interfész, és bridge, az ha fekete dobozként tekintünk a tűzfalra, érdektelen, csak a kezelését teszi nehézkessé.
A switch-et (mint fentebb írtam, még a témanyitás előtt) átnéztem, nincs semmilyen biztonsági beállítás, vagy mac szűrés. (a loop védelem van bekapcsolva, és jelszóval védett, mielőtt valaki beleköt). A tűzfal és azok a gépek, amivel a Web-es felületet el akartam érni, mind ugyanarra a switch-re csatlakoztak.
- A hozzászóláshoz be kell jelentkezni
De a switch csak egy buta L2 eszkoz, mi van meg elorebb? Valahol van egy router, amiben lehetnek szabalyok.
- A hozzászóláshoz be kell jelentkezni
NINCS! Ok., a két WAN irányban van egy-egy router, a szolgáltatóé. De a saját router NET interfésze és a kliensek között csak egyetlen egy L2 switch van, és ugyanabban a alhálózatban van a kliens és a router/tűzfal NET-je. De ezt már leírtam egy párszor. Ez a hálózat tényleg olyan egyszerű, mint ahogy leírtam, van (volt/lesz) ugyan egy pár VPN, de azok nem játszanak még, a be nem állított VPN, ami a felhasználók hozzáférését, meg a hálózati megosztást ad egy közeli óvodának, miben befolyásolná ezt a jelenséget?
Off: Nem vagyok egy router guru, a programozás közelebb áll hozzám, de kb. azóta foglalkozom (főállásban, vagy mellékesen) hálózatokkal, amióta azok vannak Magyarországon. Sok teljesen érthetetlen jelenséggel összefutottam ez alatt, volt hogy a supportnak az volt a végső válasza, na ezt ők is megnéznék, mert nem értik, és volt, hogy én csesztem el valamit, (esetenként triviálisat), csak nem vettem észre.
Off: A legemlékezetesebb érthetetlen fícsör az volt, jó 10 éve, hogy egy hálózatfelújításkor a központi ProCurve switch-nek (5304) volt valami hibája. A jelenség az volt, hogy a központi switch-en nem volt semmilyen hibajelenség, viszont a rá csatlakozó szintén ProCurve (2650) switch-nek a kliensek felé lehaltak a portjai. A 2650-est lecserélve ugyan ez a jelenség, Központi swich csere után minden Ok. Nem volt vicces. Ugyan ezen swich-eknél volt egy port forward probléma, amire a support válasza : "Ezt mi is szívesen megnéznénk.". Csak kerülő megoldás volt.
- A hozzászóláshoz be kell jelentkezni
Nincs bepipálva valamelyik interface-en a "Block bogon networks".?
- A hozzászóláshoz be kell jelentkezni
Nincs. Ha jól látom a default a nem. Volt egy default reset, és utána sem lehetett elérni a web menedzsment felületet. Most ki van kapcsolva, biztos nem itthon kapcsoltam ki, hanem be sem kapcsoltam a tetthelyen.
- A hozzászóláshoz be kell jelentkezni
Ugye a DHCP nem aktív a pfsense-en!?
Ez a bejegyzés meg nem aktív a pfsense DHCP alatt... "Only the clients defined below will get DHCP leases from this server."
Ez egyszer csúnyán szivatott, pár órát.
( •̀ᴗ•́)╭∩╮
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek
Ha meg akarod nevettetni Istent, készíts tervet!
- A hozzászóláshoz be kell jelentkezni
A DHCP szolgáltatás egyetlen interfészre sincs volt engedélyezve. Mikor kipróbáltam, nem a helyszínen, akkor bekapcsoltam a NET-re a DHCP szolgáltatást, de mielőtt összepakoltam a gépet, kikapcsoltam. A helyszínen pedig a full reset után nem kapcsoltam be.
- A hozzászóláshoz be kell jelentkezni
Biztos,hogy full resete eseten a DHCP szolgaltatas allapota a disabled? En megneznem a helyedben, biztos ami biztos.
- A hozzászóláshoz be kell jelentkezni
NEM VOLT BEKAPCSOLVA!
De tegyük fel egy pillanatra, hogy be volt kapcsolva. Kérdez a kliens, és válaszol az egyik DHCP kiszolgáló. Kap egy címet, ami ugyan az a tartomány, maszk, és GW (bár most a GW irreleváns). Ezek után, lehet cím ütközés. Ha ez az eset van, akkor ezt elvileg észreveszi a kliens, nem? Láttam már címütközést, nem az volt a jelenség, hogy nem lehetett pingelni, hanem hogy több válasz érkezett. Ha valamelyik szereplő ezt észrevette, és blokkolt, annak nem kellet volna valahol log-ban status-ban megjelennie? Az egész hálózatban max. 2 db. DHCP kliens volt.
- A hozzászóláshoz be kell jelentkezni
Ebben igazad van, de a "NEM VOLT BEKAPCSOLVA!"-tól függetlenül a DHCP szerver beállítólapján még tényleg lábon lőheted magad pl. az "Enable Static ARP entries" opcióval (help írja is, hogy akkor is megmarad a beállítás, ha letiltod a DHCP szervert, attól az interfészen megtartja a noarp-ot).
Szerk.: lemaradt záró zárójel, és lehet, hogy pfsense-nél az Enable statis ARP entries az az, amit agostonl fentebb írt (egy opnsense-re néztem rá hirtelen)
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
Erre a noarp-ra nem emlékszem/nem néztem. És a tapasztaltak se mondanak ellent, kivéve, hogy itthon simán működött, fix IP címet állítottam be a kliensen, és egyből elértem a webes felületet (mint azt írtam fentebb).
(A noarp megtartása a DHCP kikapcsolás után, igen bölcs dolog, ha szívatni akarjuk a kedves kezdő felhasználót. Bár lehet, hogy voltak más szempontok is.)
- A hozzászóláshoz be kell jelentkezni
(A noarp megtartása a DHCP kikapcsolás után, igen bölcs dolog, ha szívatni akarjuk a kedves kezdő felhasználót. Bár lehet, hogy voltak más szempontok is.)
Gondolom nem akartak két felületet csinálni a MAC - IP párok felvitelére (valahol jogos is, azzal még jobban meg lehetne zavarni az admint és felesleges plusz munkát csinálni)
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
A belső hálózat (LAN) forgalma engedélyezve van kifele?
- A hozzászóláshoz be kell jelentkezni
A default reset után, a konzolról beállítva a NET-et (cím,DHCP nem bekapcsol) a NET forgalma nincs alapértelmezetten engedélyezve? Nem emlékszem (de majd megnézem) a konzolon ilyen beállításra, a WEB-en meg nem lehet addig semmit csinálni (engedélyezni), amíg nem elérhető (22-es csapdája).
További ellentmondás: hazahozva a gépet, ha ki volt kapcsolva a NET forgalma, ki kapcsolta be? Én nem lehettem, mert monitort és klaviatúrát sem tettem rá, egyből elértem a webes felületet.
Szerintem ezt a forum témát akár le is zárhatjuk. Leszögezhetjük, hogy a franc se tudja mi történt. Vagy nagyon benéztem valamit, vagy csak furmányosan szívatott valamelyik komponens. Újra meg kell kísérelni a tűzfal cserét, de most már viszem a laptopomat, így nem kell a tököm tudja milyen ottani windows kliensekre szorítkozni, és végső esetben közvetlenül csatlakozhatok a tűzfalra (csak egy patch kábellel, úgy ment).
- A hozzászóláshoz be kell jelentkezni