Új hozzászólás Aktív témák
-
brd
nagyúr
válasz adamka16 #7710 üzenetére
Pl. ha nincsen DNS (esetleg WINS) servered, akkor az egyik gépet (praktikusan az lenne jó, amelyik a legtöbbet működik, de legalábbis biztosan fut, amikor a megosztásokat használnád) ki kellene nevezned hálózatlista-nyilvántartónak (ez nem konkrét beállítás, csak elméletben gondold ki), a többin pedig a tallózás szolgáltatást állítsd le és tedd kézi indításra/letiltvára.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz MasterDeeJay #7753 üzenetére
Nem, mert az a helyi filerendszer szintjén működik, a hálóra küldésnél már a kitömörített adatot küldi.
Viszont a leírásod alapján szerintem nem is a háló a lassú, hanem a serverben a meghajtó. Ezen talán segít kicsit a tömörítés, kipróbálhatod.The only real valuable thing is intuition.
-
brd
nagyúr
válasz MasterDeeJay #7762 üzenetére
Nem biztos, hogy gyorsabb, ill. szekvenciálisan egyértelműen az, de több konkurrens hozzáférésnél én a SCSI-ra fogadnék egy asztali vezérlő+HDD párossal szemben. A háló meg olyan, amilyen, de a serveren meg tudod nézni, hogy amikor lassú, akkor mennyire terhelt. Persze ha 10-en megtámadják, az is lassúnak tűnhet egy-egy felhasználónak, de egy asztali HDD nem viseli túl jól a 10 egyidejű hozzáférést, ott nem lehet úgy számolni, hogy oké, 100MB/s-t tud, akkor 10/MB/s jut egy felhasználóra, mert ilyen terhelésnél jó, ha 5-10MB/s-t ki tud préselni magából. A hálózatnál nincsen (ill. elenyésző mértékű) ilyen jellegű probléma, ott esetleg a switch belső sávszélessége lehet a szűk keresztmetszet, lehet, hogy 24 portja van, de belül nem tud 24*100MB/s-t, hanem mondjuk csak 8*100MB/s-t.
Snoop-y: Pont annyira biztonságos, mint 40 éve. Amire annak tudatában használható volt, hogy titkosítás nélkül utazik az össze tartalom, beleértve az azonosítást is, arra most is pont ugyanolyan jó. Egyébként lehet TLS/SSL FTP-t is használni, nincs megtiltva. Mondjuk ott meg a tűzfallal lehet némi probléma.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz moha bácsi #7988 üzenetére
Ahogyan a topictárs írja, kell a másik serverre is DHCP, és valamilyen arányban fel kell osztani az IP tartományt köztük, bár szerintem nem is annyira favágó módszer, teljesen jól működik, csak nagyobb IP tartomány kell, és nagyon oda kell figyelni, hogy ugyanazt állítsd be a két DHCP-n, ill. ha vannak fenntartások beállítva, akkor több időt vesz el ezek beállítása, mert mindkettőn be kell ugyanazt, bár PS-ből, vagy batch-ből egyszerűen lehet, ha kicsit értesz hozzá.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz VeryByte #7999 üzenetére
Maintenance: parancssorból/scriptből vezérelve gyakorlatilag kizárható a tévedés, ill. sokkal nagyobb időigénye sincsen így a kezelésnek. A különböző range-et talán én pontatlanul írtam, hogy félreérthető lett. Úgy értettem, hogy a netmask és a hálózat ugyanaz, csak kiosztható a IP-tartomány nincsen fedésben egymással, azaz amit az egyik kioszthat, az a másikon ki van zárva az osztható tartományból, így bátran működhet egymás mellett a kettő, mert ugyanazt az IP-t nem osztja ki egyik sem, viszont minden más kiosztott érték megegyezik. Az azonos IP-tartomány miatt a kizárások sem probléma (nyilván mindkettőn fel kell venni ugyanazt). Ehhez semmi extra okosság nem kell, már az első DHCP óta működik.
[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz bugizozi #8113 üzenetére
Bejövő szabály nem kell, azt a NAT kezeli (ha úgy van beállítva a TMG, hogy NAT-oljon). Egyszerűen egy Internal to External szabály kell, az adott portra vonatkozó protokollal (TCP, a direction outbound legyen). Így persze bármilyen IP-re ki van engedve az adott port, ha ez így nem jó, akkor az External helyett az adott IP, vagy domain legyen megadva.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz sanzi89 #8145 üzenetére
Nincs hálózata a gépnek (vagy valami biztonsági megoldás - pl. tűzfal, vagy rosszul beállított switch - van a server és a kliens között, vagy egyszerűen rossz a hálókártya, vagy a drivere, esetleg valami kártevő tanyázik a gépen), a "kiosztott" IP meg gondolom 169-cel kezdődik, ezt a Windows adja magának, ha DHCP-sre van állítva, de nem látja a DHCP servert.
[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
Csinált már innen valaki MS SQL-lel Log Shippinget? Hogyan lehet kikapcsolni az Event Log/Application-ba kerülő, ezzel kapcsolatos bejegyzéseket? A primary oldalon ki tudtam a /T3226 flag-gel, de a a secondary oldalon ettől még jönnek a "Recovery is writing a checkpoint in database 'blabla' (5). This is an informational message only. No user action is required.", "The database 'blabla' is marked RESTORING and is in a state that does not allow recovery to be run.", és "Starting up database 'blabla'."
The only real valuable thing is intuition.
-
brd
nagyúr
Akkor másik kérdés: ingyenes syslog server windowsra létezik? Semmi extrát nem kell tudnia, bejön a log, lementi txt-be (esetleg az eszközöket IP/név alapján külön file-ba, de enélkül is ellennék, elég, ha a sor elejére írja).
The only real valuable thing is intuition.
-
brd
nagyúr
válasz gaborbol #8248 üzenetére
Valamiért az alsó rész (a feature-ök felsorolása alatti rész) konkrétan hiányzott az oldalból, az általánosan használt böngészőmben. Furcsálltam is, hogy nem tolják a free verzióban az arcomba a vásárlási lehetőséget... Elnézést kérek, hogy túráztattalak.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz InfiniteReality #8372 üzenetére
Ugyanaz a kernel van benne, mint a server OS-ben, mitől ne futhatna 7/24-ben?
[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz gaborbol #8390 üzenetére
Azt sem tudom, hogyan lehetne blokkolni, mert a PDF-et nem lehet, annyira gyakori file.
Igazából sehogy, ha dolgoznia is kell ilyen file-okkal (pláne, ha pl. a PDF Reader hibáján keresztül támad valami), de legalább egy normális vírusirtó kellene, ami frissül is, és nyivákol valakinek, aki olvassa is, ha talál valamit/nem tud frissülni/lejárt a licence, tovább a PDF megjelenítőnek is magától, lelőhetetlenül frissülnie kellene, de itt kezdődik a fasizmusba hajlás a korlátozás terén. Amennyibe nem kell ilyenekkel dolgoznia, és nem kell admin legyen a saját gépén, akkor azért vannak lehetőségek a group policy-n keresztül.
Viszont lehet nekik ajánlani jó kis mentési/archiválási technikákat. A mentés helyén VSC/snapshot rendesen beállítva, felügyelve (lefut-e rendesen, elég-e a hely az archiválásig, ilyesmik), hogy ha ilyen titkosítós varázslat történik, akkor vissza lehessen pakolni az előző állapotot, archiválás kidolgozása (hova, mire, megoldani, hogy az törölhetetlen legyen software-esen, ha azt a hardware nem biztosítja), ilyesmik.The only real valuable thing is intuition.
-
brd
nagyúr
válasz gaborbol #8521 üzenetére
Meg kellene nézni a nyomtató felé menő csomagokat, pl. egy Wireshark használatával. Én pl. olyan Konica-val találkoztam már, ami minden multicastos csomagot magához rántott, emiatt halt szét ugyanígy napközben (a switch bírta, a Konica nem). Azon egy firmware-frissítés segített. Ha külön VLAN-ba teszed a Konica-t és egy klienst a HP switchen, akkor is van packet loss?
The only real valuable thing is intuition.
-
brd
nagyúr
Hogy lehet azt megmondani egy Windows-nak, hogy a domain controllert ne keresse az egyik beállított DNS server-nél? Pl. ha be van neki állítva a 8.8.8.8 is másodlagosnak, akkor attól ne próbálja megkérdezni, hogy mi a _LDAP._TCP.dc._msdcs.domainname, vagy, hogy a "nem létezik"-et ne fogadja el, és kérdezze meg a másik DNS serverektől is?
The only real valuable thing is intuition.
-
brd
nagyúr
válasz NEOSIGNAL #8685 üzenetére
...a tanárom azt mondta hogy nem fogunk hyper v-t gyakorolni mert nem tudunk virtualizácóban virtualizációt csinálni
Rosszul tudja, pl. a VMware bizonyos termékei (ESX, Workstation 8) alatt van lehetőség "továbbadni" (nested virtualization) azt a CPU feature-t, ami ahhoz kell, hogy a Hyper-V tudjon futni alatta. Ahhoz, hogy otthon játssz vele, sok RAM kell, és AMD-V/VT-x-képes CPU, de a plusz háttértároló sem árt.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz E.Kaufmann #8691 üzenetére
Válassz ki néhány szolgáltatót, amit utálsz, és pingeltesd a weboldalukat (én pl. a UPC és a T-csoport oldalát szoktam választani Mo-n). Ha nem őrült módjára pingeled (nem másodpercenként 100 ping), nem fogják letiltani. Egy IP szerintem nem elég, mert az is lehet, hogy pont az szünteti be a szolgáltatást egy kicsit, vagy akár végleg? Vagy azt is lehet, hogy a saját szolgáltatónál megnézed, hogy a router IP-je után milyen publikus IP-vel bíró gateway szokott jönni, és annak az IP-jét pingelteted, bár ez nem mindig jó, mert olyan is lehet, hogy az elérhető, de mégis, az Internet nem működik azon a kapcsolaton, a szolgáltató hibájából.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz PumpkinSeed #8831 üzenetére
Az egyik helyen van ilyen ügyfelünk, sok röhögés, és azmeg elmorzsolása tartozik hozzá.
The only real valuable thing is intuition.
-
brd
nagyúr
Mi csinálja a RAID-et? A Windows, vagy az alaplapi vezérlő? Ha előbbi, akkor a tükör törése nélkül nem tudsz növelni, utóbbi esetben vezérlőfüggő, hogy lehet-e. Milyen vezérlő van az alaplapon?
A beépített eszközzel nem tudsz eltolni partíciókat, így a másodikat vagy külső programmal kell megoldani, vagy átmásolni máshová, törölni a partíciót, majd visszamásolni az új helyre.The only real valuable thing is intuition.
-
-
brd
nagyúr
Olyan régi programmal nézed, ami azt nem látja. Nyisd meg sima intézőből, vagy a c:\windows\sysnative\drivers-t nyisd meg. Ez utóbbit intézőből ne próbáld, nem fogja látni. Röviden arról van szó, hogy a 64 bites rendszerre teljeskörűen nem felkészített 32 bites programok a \windows\system32 helyett valójában a \windows\syswow64 foldert látják (ott nincsen ilyen könyvtár, amit te keresel), ezért számukra lett egy hivatkozás készítve, ami a sysnative, ezzel a valódi system32-t látják. Viszont a 64 bites (vagy direkt úgy készített) programok ezt a sysnative foldert nem fogják látni (ami nem is folder, csak egy átirányítás igazából).
Ha szerkeszteni akarod a file-t, azt rendszergazda jogú (mármint amit nála emelt jogosultsággal indítottál, nem csak rendszergazda kell legyen) userrel tedd (tehát az intézőből jobbgomb-szerkesztés nem pálya), mert csak az tudja írni.[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz SityiSXT #9030 üzenetére
Azért működik egy ideig, mert a switch, vagy helyi hálón a küldő gép (utóbbi akkor, ha -hibásan- IP-t is megadsz valahogyan a küldéskor; mert ennek csak ott/akkor van értelme, ha több kártya van egy gépben, ilyenkor megmondható, melyiket használva küldje a csomagot) megjegyzi a MAC-jét a kártyának, és a neki szóló csomagokat arra a portra küldi. Viszont amikor kikerül az ARP cache-ből, akkor csak broadcastként küldve kapná meg, amit az Internet felől annyira nem egyszerű megoldani. Alapvetően kettő lehetőséged van:
1. A NAT-ot intéző eszközön valamilyen daemon használata, amit máshogyan meg tudsz támadni kívülről, hogy bentre WOL csomagot küldjön, vagy a Webes felületéről felkeltés.
2. Megoldod, hogy legyen egy olyan virtuális IP a NAT eszköz számára, amihez hozzá van rendelve a broadcast MAC. Az IP azért kell, hogy az Internet felől címezni tudd portforwarddal, a broadcast MAC pedig azért, hogy megkapja minden port a switch-en. Pl. arp -i br0 -s 192.168.1.100 FF:FF:FF:FF:FF:FF, ezzel felveszel a br0 nevű kártyához egy statikus bejegyzést a routeren, és az erre az IP-re küldött bármilyen csomag (mármint ami a routerről indul, vagy azon megy át, ezzel a cél IP-vel) broadcastként lesz küldve.A route-nak ehhez semmi köze, az egy magasabb hálózati rétegben működik, továbbá ezzel a céllal a fix IP is felesleges, a WOL móka egy alsóbb rétegben működik, IP csak azért kell a történethez, mert az Internet felől, csak azzal tudod címezni azt a hálózatot, ahol a felkeltendő gép van. Belső hálón nem kellene gondot okozzon, hogy kikerül az ARP cache-ből a MAC. Milyen programmal, hogyan küldöd a WOL csomagot a hálózatnak?
[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz SityiSXT #9048 üzenetére
Van még egy olyan lehetőség is, ha nagyon kényelmes akarsz lenni, hogy ha a router képes rá, akkor pl. OpenVPN-t használsz, ezzel megoldható, hogy az ARP csomagok is átjussanak a VPN-en, így nem kell a routerbe bejelentkezni, csak a VPN-re. Bár nem biztos, hogy csak ezért érdemes bekonfigurálni egy OpenVPN servert+klienst.
The only real valuable thing is intuition.
-
brd
nagyúr
Egyrészt van valami bug, ami most nem ugrik be, hogy mitől, de valami olyasmiről szól, hogy a grafikus felületen beállítva nem lépnek életbe a hálózati beállítások (ip, átjáró, ilyesmi), majd talán holnapra, bár addig úgyis kigúglizod. Másrészt nem lehet, hogy valamiért alacsonyabb a defgw metricje, mint a felvett route-é? Harmadrészt, ha hozzáadod a route végére az interface számát (pl. if 5, a számokat a "route print" elejéről tudod kilesni), akkor sem azt csinálja, amit szeretnél? Negyedrészt, nincsen valamilyen routing/firewall software telepítve a gépre, vagy korábbinak nem maradhatott valamilyen komponense a gépen?
The only real valuable thing is intuition.
-
brd
nagyúr
Valamit itt nagyon össze van kócolva. Az első sor egy default gw, de ilyen tartományú IP-t nem is írtál az előző hozzászólásodban. A második sor pedig miért default Metric-kel van felvéve? Az egész route táblát be tudod másolni, vagy titkos? Ha titkos, akkor a Active Routes alatt a Metric oszlopot nézd, szerintem ott bújt el az ördög. Bár gondolom, tudod, de a Metric az az út ún. költsége, minél magasabb, annál inkább nem arra akarja küldeni a csomagot, ha van másik, alacsonyabb értékű, akkor inkább arra küldi. Vagy tekintheted fordított prioritásnak is: aminek alacsonyabb a Metric-je, annak magasabb a prioritása, vagyis az kerül először sorra, ha egy csomag többre is tud illeszkedni.
The only real valuable thing is intuition.
-
brd
nagyúr
Ha jól csinálod, sehogy, működnek tovább. Csak csináld jól, pl. IP címek/maskok beállítása, ill. a (routing) szabályoké is, ha úgy vannak megvalósítva. Ill. ha VPN-t az ISA (vagy talán a TMG is bír ezzel a korláttal, de az most nem rémlik) ad úgy, hogy a belső hálóról van a címtartomány, akkor a netmask átjuttatása a klienseknek kissé problémás, DHCP Relay-t kell használnod (vagy más megoldással kell kiváltanod/megtámogatnod).
The only real valuable thing is intuition.
-
brd
nagyúr
válasz balaaa88 #9177 üzenetére
Az az érdekes, hogy az Interneten ki találkozik a levelekkel, mint fogadó SMTP, ill. hogy az milyen IP-t lát, mert annak a PTR-je kell stimmeljen (ez a MAIL lesz nálad a szöveg alapján). Az MX rekordo(ka)t pedig úgy érdemes beállítani, hogy egy A rekordra (vagy rekordokra, ha terheléselosztás, vagy backup MX is van) mutasson, és az A rekord mutasson az IP-re. Technikailag az MX IP-re mutató formában is megfelelő, de egyes mailserverrek ezt is figyelik, és ha nem is utasítják el a levelet emiatt, lepontozzák.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz balaaa88 #9182 üzenetére
Erre az a megoldás, hogy felvetetsz (pontosabban kijavíttatod, mert a hibaüzenet alapján mintha már lenne valamilyen, csak ez az IP nem szerepel benne) a küldő domain dns-ébe pl. egy ilyen txt rekordot:
"v=spf1 ip4:1.2.3.4/32 -all" (ha több IP van, akkor így: "v=spf1 ip4:1.2.3.4/32 ip4:5.6.7.8/32 -all")
Ezzel azt mondod meg, hogy az adott domain-ű feladók címével jogosult küldeni az 1.2.3.4-es IP-jű SMTP server. Ha így nem elég szexi neked a rekord, akkor itt találod a részletes szintaxist.The only real valuable thing is intuition.
-
brd
nagyúr
válasz balaaa88 #9183 üzenetére
Az a baj, hogy a küldő gép (SMTP server) DNS-ben szereplő A rekordja nem ugyanaz, mint amit az IP PTR-jének lekérdezésére visszakapnak. Tehát pl. a mail.valami.com feloldódik a blabla.175-re, akkor a blabla.175 PTR-je a mail.valami.com legyen. Ennek nem kell egyeznie a feladó e-mail címében (pl. info@akarmi.hu) szereplő domainnevével (de érdemes az akarmi.hu DNS rekordjai közé SPF-nek - vagy TXT-nek, ha a regisztrátor csak olyat tud - felvenni az előbb írt módon pl. az IP-t).
[ Szerkesztve ]
The only real valuable thing is intuition.
Új hozzászólás Aktív témák
- iPad Air 10.9" - 2022, M1, Apple garancia, doboz, kék
- iPad Air 10.9" - 2022, M1, nanoSIM, Apple garancia, doboz, szürke
- Macbook Pro 16" - i9 és i7, 32/512GB, 4GB Radeon, touchbar, garancia, szürke
- Macbook Pro 15" - 2018, 6 mag i7, 16/256 GB, 4GB Radeon, 83 ciklus, garancia, ezüst (02)
- Macbook Pro 15" - 2017, 4 mag i7, 16/256 GB, 4GB Radeon, 99%, garancia, doboz, szürke