Aj keď VPS ma nikdy nejak nelákal (mám vlastný hypervízor Proxmox), tak zo zvedavosti som si na skúšku jeden prenajal. Poskytovateľov VPS je nespočetné množstvo a aby som nemusel všetko manuálne preverovať, tak som siahol po webovej stránke serverhunter, kde je filter pre nastavenie parametrov. Keďže nepotrebujem nič veľké, parametre som nastavil veľmi nízko. Celkom ma zaujala táto ponuka na eugamehost.
- CPU: 1vCore Intel Xeon E5-2699v3
- Memory: 1GB DDR4 ECC
- Storage: 10GB NVMe 4.0 SSD
- Network: 1Gbps port with 1TB monthly transfer
- IP Allocation: 1x IPv4 Address
- DDoS Protection: Cosmic Guard™ Advanced Anycast DDoS Protection
Áno, podľa názvu domény sa zdá, že je to prioritné určené pre hráčov, ale to ma veľmi nezaujímalo, pretože mne stačia tieto parametre, ktoré poskytovateľ ponúka. Cena na mesiac bola neuveriteľných 0.61€, čo je 7.30€ na celý rok. Aj keď server sa nachádza v Spojenom Kráľovstve, nevidel som v tom problém a okamžite som si tento VPS objednal a zaplatil.
Počas registrácie a platby som nemal možnosť, zvoliť si operačný systém, takže hneď po aktivovaní účtu som chvíľu hľadal kde si zvolím OS. Našiel som to pomerne rýchlo a na výber bolo množstvo linuxových distribúcii (Bez možností MS Windows). V súčasnej dobe na svojom lokálnom Proxmoxe prevádzkujem hlavne LXC a KVM založené na Debian 13, tak som aj na VPS vybuildil Debian 13. Ako je vidieť z obrázka, tak build Debian 13, trval 22 sekúnd (takto vlastne vyzerá dashboard)

Ako je vidieť na obrázku, tak VPS som vytvoril 02.07.2026 o 10:24 a buil Debian 13 som spustil 02.07.2026 o 11:59. Zatiaľ sa zdalo, že všetko funguje správne. Po builde OS som všetko nechal tak a na druhy deň som sa cez SSH prihlásil a zistil som, že za nejakých 20 hodín mám Inbound takmer 4GB (prečo?)
No dobre. Server bol spustený a s NFTables (IPTAbles) som nič nerobil. Je možné, že server vystavený do sveta na verejnej IPv4 adrese sa stal terčom netbotov, DDoS útokov a pod. Spustil som si tcpdump a nestačil som sa diviť. Nebol som pod žiadnym útokom z vonka, ale z vnútra na úrovni L2.
14:53:17.224567 ARP, Request who-has 178.214.209.142 tell 172.31.253.2, length 46
14:53:17.224568 ARP, Request who-has 195.58.134.122 tell 172.31.253.2, length 46
14:53:17.224568 ARP, Request who-has 178.214.223.225 tell 172.31.253.2, length 46
14:53:17.224569 ARP, Request who-has 91.205.158.253 tell 172.31.253.2, length 46
14:53:17.224570 ARP, Request who-has 91.205.158.242 tell 172.31.253.2, length 46
14:53:17.224570 ARP, Request who-has 91.205.158.204 tell 172.31.253.2, length 46
14:53:17.226121 ARP, Request who-has 45.146.48.203 tell 172.31.253.2, length 46
Z tohto logu plynie, že IP 172.31.253.2 chce získať MAC adresu (niektorej IP viď log), ale odpoveď nikdy nedostane, lebo IP sú z rôznych verejných sieti a v mnoho prípadoch aj z iného AS. Tým pádom zariadenia nemôžu byť fyzicky v jednej L2 LAN. Možno by som si to ani nevšimol, keby tých ARP requestov nebolo počas jednej sekundy 1000 (čiže približne každú milisekundu jeden request).
tcpdump -e -n -i eth0 arp -c 10
21:15:34.577378 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 98.205.158.221 tell 172.31.253.2, length 46
21:15:34.579949 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 98.214.180.141 tell 172.31.253.2, length 46
21:15:34.582678 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 26.26.247.132 tell 172.31.253.2, length 46
21:15:34.583457 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 95.214.180.224 tell 172.31.253.2, length 46
21:15:34.586223 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 188.186.65.222 tell 172.31.253.2, length 46
21:15:34.589568 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 37.59.122.71 tell 172.31.253.2, length 46
21:15:34.589903 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 182.214.223.255 tell 172.31.253.2, length 46
21:15:34.591190 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 96.205.158.0 tell 172.31.253.2, length 46
21:15:34.593992 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 95.214.180.127 tell 172.31.253.2, length 46
21:15:34.603310 D9:5F:C8:E0:AB:E2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 201.58.134.227 tell 172.31.253.2, length 46
10 packets captured
88 packets received by filter
0 packets dropped by kernel
ip neigh
47.242.127.1 dev eth0 lladdr 00:1c:73:00:10:22 REACHABLE
172.31.253.2 dev eth0 lladdr D9:5F:C8:E0:AB:E2 STALE
172.31.253.3 dev eth0 lladdr D9:5F:C8:E0:AC:E8 STALE
Veľmi zaujímave je, prečo stroj z MAC: D9:5F:C8:E0:AB:E2 sa pýta na ARP verejných IP adries a ja tie requesty vidím na svojom eth0 rozhraní. V každom prípade je to veľmi neštandardné. Kontaktoval som poskytovateľa a teraz čakám na odpoveď.
Vzhľadom k tomu, že prenájom VPS je veľmi lacná, nebudem okolo toho robiť žiadne peripetie. Aj keď sa problém nepodarí vyriešiť VPS stále funguje a určite je aj vyťažený virtuálny CPU (ktorý generuje záťaž aj na fyzickom CPU). O tento problém by sa mal postarať poskytovateľ VPS a hlavne malo by mu na tom záležať, pretože im to zaťažuje sieť a generuje zbytočnú šťavu.
Záver
Predpokladal som, že keď bude niečo lacne, tak to zrejme nebude na profi úrovni. Možno som poskytovateľovi objavil nejakú nekorektnú konfiguráciu a po oprave to bude v poriadku. Aj keby som tento VPS opustil, určite nemám dôvod žiadať peniaze späť, lebo 7.30€ mi nestojí za to. Ja dúfam že v pracovnom týždni (po víkende) to prevádzkovateľ určite začne riešiť a ja o tom budem na svojom webe informovať.
V tomto článku boli IP (verejné) a MAC adresy vymyslené (privátne IP adresy sú pôvodné).
