Mit tehetek azért, hogy elkerüljem az egységes árvizet?

ember, végül is

A kiszolgáló leállításakor az árvíz Unicast-árvízre változik, és a kiszolgáló összes virtuális interfészére, esetenként az egész vlanra terjed. Ha jól értem, akkor ismeretlen unicast árvizet jelent.







További tanácsok, nem ismerik a hálózat topológiáját, nehéz adni.

UPD:
A példában ez azt jelentette, hogy a 109.XX.XX.XX egy IP, az 53 port, Sajnálom, figyelmen kívül hagyva. Ezért nem kedvelem a tcpdump kimenetét, és inkább a dapát a pcap-fájlok formájában kezelik.

Két problémát tapasztalok:
1) szemétszállítás az egyik gazda számára
2) a forgalom áradása (sokszorosítása) az összes virtuális szerverre

Ami az első problémát illeti, vannak kérdések. Hogyan használsz DNS-kiszolgálót? Hogyan szűrhető meg a hozzáférés? Ha nem, miért? Rekurzív lekérdezések engedélyezettek? Ha igen, akkor célszerű lezárni a kezelés, kivéve abban az esetben, ha pontosan tudja, mit csinál. Gyanítom, ebben az esetben arra törekszik, hogy 94.41.XX.XX támadás segítségével a szerver (DNS visszaverődés támadás, vagy inkább akkor lehet mondani, ha a forgalmat, billenő .pcap méret, tcpdump -i -s 65535 -w). Ha a hipotézis helyes, akkor lehetőség van arra, hogy az ilyen hulladékot a forgalom megáll egy idő után kikapcsolása után feldolgozását rekurzív lekérdezések.






Általánosságban elmondható, hogy azt a helyet volna tiltani minden forgalmat, kivéve a szolgáltató és a forgalomirányítás (ssh, SNMP, stb) forgalmat hozzáférés-vezérlési listák (ACL) az aktív berendezések (egy legközelebb-L3 eszközök, berendezések, valószínűleg két van)

Összegezve, a helyedben:
1) kitalálta a dumpban felsorolt ​​forgalmat, a DNS-kiszolgáló beállításaival
2) lehetővé tenné az ACL DC-berendezéseken keresztüli projektmunkához szükséges forgalmat
3) állítsa be a szerver egyértelmű felügyeletét
Biztos vagyok benne, hogy a pp. 1), 2) a megfigyelt probléma eltűnik. Még ha nem is - megadtam az opciókat (a DC berendezés L2 beállításainak megváltoztatása, a kapcsolódási séma megváltoztatása)

UPD2:
A forgalom szűrése azért lehetetlen, mert nem a forgalomunk, hanem a VDS-t bérlő ügyfél felé irányuló forgalom. Ugyanezen okból valaki nem blokkolható a bejövő csomagok számára, nem értem, miért nem tudja kiszűrni az ügyfélforgalmat. Szinte mindent. Amikor egy havi 100 dollárért bérelt szerver 10 gigabites / c forgalmat bonyolít le, és általában, a forgalmat a rendszer blokkolja, egyszerűen azért, mert a forgalom költsége meghaladja az ügyfelek bevételét. Ezenkívül gyakran az ilyen forgalom veszélyezteti az infrastruktúrát. Kérdeztek egy kérdést az anti-DDoS-ról. Mi ez, ha nem a forgalomszűrés?

Ezután azt gondolom, hogy fel kell állítanod a felfelé irányuló kapcsolatot, ez a legegyszerűbb és leghatékonyabb megoldás. Annak érdekében, hogy a kiszolgáló kapcsolódjon az útválasztó L3 interfészéhez, majd irányítsa (és ne áthidalja) a forgalmat az ügyfél számára. Elképzelni, hogy az L3-kapcsoló esetében hogyan fog kinézni, de bizonyára ismeretlen lesz számomra a hálózati támogatás végrehajtásának hangeja a Linuxban. Javasoljuk, hogy a használat előtt alaposan tesztelje a kört.




Kapcsolódó cikkek