TheGuy

I to jest ta wiadomość, na której się zacząłeś wykruszać. Napisałeś kolejno, że wyszukiwarka serwerów to w sumie ci nie jest potrzebna, więc gdzie leży problem w implementacji tego banalnego rozwiązania? Jeszcze dokładnie paluszkiem pokażę: "To wytnij cały tcp, zostaw sobie tylko na whiteliście adres innego serwera i pchaj komunikacje do niego po tunelu a potem do valva." next: "zwykłe proxy sobie załóż i dodaj do whitelisty na firewalu ovh."

Już abstrahując od tego jak w środku rozmowy zmieniasz temat, weź sam przeczytaj co piszesz 1. "mam wysycane łącze przez ataki tcp i chce przekierować ruch na inny adres" 2. " chodzi o ruch wychodzący." splitbrain? Nie rozumiesz paradoksu to czytaj do skutku.

No ty jednak nierozumny jesteś. Palcem jak dziecku trzeba pokazać? Zmieniłeś z du*y temat, nie rozumiałeś kontekstu rozmowy. Czy ja gdziekolwiek ci napisałem, jakoby niemożliwe było to o czym teraz piszesz? Więcej sobie wymyśl i dopowiedz mitomanie jeden Chcesz ruch gdzieś odbijać przy zapchanym łączu a teraz jeszcze kwestię jakiegoś natowania pakujesz z tym wszystkim do jednego wora :D!

Starałem się wstrzymać uszczypliwości ale prowokujesz swoim prostactwem. Próbowałem ci pomóc, wycofałem się z rozmowy bo nie chciałem cię kompromitować. Zgubiłeś kontekst (po raz kolejny) i randomowo zmieniłeś temat. Zacząłeś nagle pisać o czymś zupełnie innym (przeczytaj wszystko ponownie, powoli i może tym razem ze zrozumieniem). Nie muszę niczego udawać przed toksycznym randomem z internetu Nie potrafiłes uszanować, powodzenia :D

Dobrze, że wiedzą lepiej. Dobrego dnia

W kwestii rejestracji serwera na listach wyszukiwania - nie zadziała. Dla każdej innej komunikacji jakiej potrzebujesz, raczej bez problemu.

Rozwiniesz myśl?

To jest właśnie rejestracja serwera na listach wyszukiwania i okresowe odświeżenie rejestracji. Niektóre gry jeszcze autoryzują użytkowników w ten sposób. Brak tej komunikacji może zaburzyć nie więcej jak te wymienione procesy.

Po co innego chcesz stukać do valve? Masz jakąś poboczną usługę, która tego potrzebuje? W takim przypadku nie powinno być problemów, zwykłe proxy sobie załóż i dodaj do whitelisty na firewalu ovh.

To już najmniejszy problem, gameserver musi dostać ten ruch z ipka serwera 1. Jak go tam dostarczysz z innym src ip, serwer gry nie zarejestruje się na listach wyszukiwania... lub zarejestruje się pod innym adresem. Co niedawno w sumie widziałem... pewien sandbox w garrysmodzie robił coś takiego Klienci próbowali go querować ale nie szło bo stukali pod zły adres.

To wytnij cały tcp, zostaw sobie tylko na whiteliście adres innego serwera i pchaj komunikacje do niego po tunelu a potem do valva. Niestety jednak valve gameserver chciałby otrzymać dane z ipka serwera gry. Karkołomne zadanie, wysłać na zewnątrz pakiety z nie swojego adresu ip (pierwszego serwera) i to jeszcze po tcpie, gdzie musi się sesja nawiązać. Albo potrzebny ci będzie vps z iphm albo ktoś z własną siecią i adresacją, kto Ci na to pozwoli. Update: jednak nie ma opcji bo przy wycięciu całego tcp nie odbierzesz odpowiedzi na ovh - faktycznie

W tej sytuacji, jeśli wysyca łącze, może przecież przysłać dowolny inny rodzaj pakietów (choćby udpowy ruch) i efekt będzie taki sam. Tu żadne rozwiązanie się nie sprawdzi. Jeśli ovh tego nie ogarnia to wojna budżetów, twój vs jego. Wygra tylko ten z większą rurą

Would you mind sharing some pcaps? Wiem sporo o rozwiązaniach antyddos w ovh, ciężko opisać jak bardzo dziwią mnie przedstawione tu informacje. Jak ruch cię dowala to normalnie ssh zrywa? Laguje coś? Chyba nie do końca rozumiem jak rozwiązanie z początkowego posta ma pomóc, skoro pasma brakuje.

Jeśli odpowiadasz na ten ruch syn-ack generujesz drugie 50%, spróbowałbym na twoim miejscu proponowanego rozwiązania. Ovh zobaczy, że dostajesz spam synów na który nie odpowiadasz i prawdopodobnie (mam 95% pewności) wytnie to w cholerę automatycznie.

Ale jak wytniesz przychodzące połączenia (na swojej zaporze) to problem się rozwiązuje, dalej możesz stukać gdzie tylko chcesz na zewnątrz. Dlatego pytałem cię ile masz ruchu przychodzącego, bo prawdopodobnie nie ma powodu by wycinać na ich firewalu całe tcp w obie strony

Syn reflection attack? No to wracamy się o kilka komentarzy do góry, wystarczy nie przyjmować połączeń tcp i wolumen ruchu spada o połowę bo nie ma już wychodzącego. Ile przychodzącego ruchu masz w mbps?

Nie trzeba być uszczypliwym, a w jakim celu chcesz blokować to na firewalu w ovh? Ilość ruchu cię przytłacza? Myślę, że moje doświadczenie w tej materii jest niekwestionowalne

Conntrack śledzi połączenia jakie wykonujesz na zewnątrz i wpuści odpowiedź. Podstawy linuksa szanowny Panie.

Do hlds/srcds nie lata ani jeden pakiet tcp, obejrzyj tcpdump. Ustaw policy drop na inpucie i allow tylko dla udp. Problem rozwiązany, to najprostsze i najszybsze do wyjaśnienia rozwiązanie.

Nie ma wielu skutecznych metod ochrony tego, srcds dostanie spofowanym ruchem i składa się od razu, problematyczne do ochrony jak dns. Jedyna 100% skuteczna metoda to: Postawić aplikacyjne "przezroczyste" proxy przed serwerem gry, które przeprowadza wstępną autoryzację klienta (na protokole gry, działanie nieco analogiczne do synproxy). Dopiero po ustanowieniu połączenia (jakakolwiek wymiana pakietów, choćby query challenge upewnia nas, że ruch nie jest spofowany) wpuszcza go (nawiązuje połączenie z faktycznym serwerem gry, w pewnym sensie "udając" klienta przez pierwsze kilka pakietów, które wcześniej proxy wymieniło z klientem). Kolejno proxy pilnuje tej sesji , sprawdza czy ruch pasuje do heurystyki. Tu rozwiązania ochrony muszą być szyte pod specyfikację aplikacji i protokół konkretnej gry. W przypadku srcds są w większości podobne. Cloudflare ma... podobnie jak ovh, coś co "patrzy" na ruch i wycina wg swojej logiki bad actorów, czasem wytnie normalnych graczy (nawet na etapie łączenia się do serwera) notorycznie się zdarza. Nie dalej jak 2 lata temu valve zaktualizowało query protocol, facepunch zaimplementował to w garrysmodzie, ovh żarło się z nim przez 3 miesiące podobnie jak cloudflare - dopóki ktoś ręcznie nie poprawił rozwiązań. To wszystko rozwiązania szyte pod protokół ale ich skuteczność jest taka sobie. Firmy z takim budżetem mogłyby zrobić to lepiej... jednak ta kiepska skuteczność nie dziwi mnie, wystarczy że serwer będzie miał inny tickrate, niektóre sieciowe convary np. cl_updaterate inny niż ten, na podstawie którego tworzyli heurystykę... i już problemy.

Jeśli dalej szukacie, poproszę o szczegóły.

Zapraszam na pw, 12 lat spędziłem z silnikiem source, nie ma tu tajemnic od strony sieci. Autor prawdopdobnie nie rozumie czego chce.