Linux w sieci: Jak rozpoznać i zdiagnozować „pożeraczy” pasma na poziomie jądra?

Problemy z wolnym internetem na serwerze Linux to częsty ból głowy administratorów, ale ich źródło często tkwi nie w routerze, a w samym systemie. Jak rozpoznać procesy „pożerające” pasmo, zanim doprowadzą do przeciążenia sieci? Odpowiedź kryje się w narzędziach wbudowanych w jądro – od ebpf po `conntrack` – oraz w umiejętnym połączeniu klasycznych poleceń z nowoczesnymi metodami monitoringu.

Dlaczego Linux „pożera” całe łącze? Najczęstsze symptomy na pierwszy rzut oka

Zanim zanurzymy się w diagnostykę na poziomie jądra, warto rozpoznać typowe objawy problemów z przepustowością. Często bagatelizowane spowolnienia sieci mogą wynikać z ukrytych procesów, które niekoniecznie widoczne są w standardowych narzędziach systemowych. Oto symptomy, na które powinieneś zwrócić uwagę:

1. Nagłe „wpadanie” sieci mimo wolnego ruchu na routerze. Router pokazuje minimalne obciążenie, ale serwer działa wolno.
2. Wysokie wykorzystanie interfejsu sieciowego – sprawdzane poleceniem ip -s link lub ethtool -S eth0, gdzie wartości rx_bytes lub tx_bytes rosną lawinowo.
3. Procesy w stanie „D” (uninterruptible sleep) w top lub ps, co wskazuje na blokowanie operacji sieciowych.
4. Przekroczenie limitu przepustowości na interfejsie – np. 1 Gbps, ale sumaryczny ruch osiąga 900 Mbps nawet przy braku aktywnych użytkowników.
5. Logi jądra wypełnione komunikatami o błędach sieciowych (dmesg | grep -i net).

„Pamiętaj, że problemy z siecią nie zawsze są winą dostawcy internetu. Często winowajcą jest proces działający w tle, który np. uploaduje dane do chmury lub uczestniczy w atakach ddos.”

Narzędzia jądra do monitoringu ruchu: ebpf, nftables i conntrack w akcji

Jądro Linux dostarcza potężnych mechanizmów do monitoringu ruchu sieciowego, które działają z minimalnym obciążeniem systemu. Poniżej omówimy trzy kluczowe narzędzia, które pomogą zidentyfikować „pożeraczy” pasma na poziomie systemu operacyjnego.

1. ebpf: Dynamiczne monitorowanie ruchu sieciowego

Extended Berkeley Packet Filter (ebpf) to technologia, która pozwala na wdrażanie programów do jądra w czasie rzeczywistym bez konieczności jego rekompilacji. Jest szczególnie przydatna do monitoringu ruchu sieciowego, ponieważ działa na poziomie pakietów.

Przykład użycia ebpf do śledzenia połączeń sieciowych:

sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter {
    if (args->id == SYS_CONNECT) {
        @[comm] = count();
    }
}'

Wynik pokaże, które procesy (comm) nawiązują najwięcej połączeń. Możesz także monitorować konkretne porty:

sudo bpftrace -e 'kprobe:tcp_connect {
    @[comm] = count();
}'

Zalety ebpf:

• Niskie zużycie CPU (działa w przestrzeni jądra).
• Możliwość filtrowania ruchu na poziomie pakietów.
• Brak konieczności restartu systemu.

Ograniczenia:

• Wymaga uprawnień administratora (sudo).
• Skrypty ebpf trzeba dostosowywać do konkretnej wersji jądra.

2. nftables i śledzenie ruchu w czasie rzeczywistym

nftables to nowoczesna alternatywa dla iptables, która oferuje śledzenie ruchu sieciowego z dokładnością do pakietu. Możesz skonfigurować reguły monitorujące konkretne połączenia lub uruchomić tryb tracę:

sudo nft monitor trace

Powyższe polecenie wyświetli wszystkie reguły nftables wraz z informacjami o ruchu w czasie rzeczywistym. Aby skonfigurować dedykowaną regułę do monitoringu, użyj:

sudo nft add table ip monitor
sudo nft add chain ip monitor output { type filter hook output priority 0 \; }
sudo nft add rule ip monitor output ip protocol tcp counter

Zalety nftables:

• Możliwość precyzyjnego filtrowania ruchu.
• Niskie obciążenie systemu.
• Integracja z logami systemowymi.

3. conntrack: Śledzenie aktywnych połączeń

Narzędzie conntrack pozwala na monitorowanie aktywnych połączeń sieciowych w czasie rzeczywistym. Jest szczególnie przydatne do identyfikacji procesów, które nawiązują wiele połączeń lub utrzymują je przez długi czas.

Przykładowe polecenia:

• Wyświetlenie wszystkich aktywnych połączeń:

sudo conntrack -L

• Filtruj połączenia po porcie (np. 443):

sudo conntrack -L -p tcp --dport 443

• Wyświetlenie statystyk połączeń:

sudo conntrack -S

Zalety conntrack:

• Szybkie i proste w użyciu.
• Dostępne domyślnie w większości dystrybucji.
• Możliwość integracji z logami systemowymi.

Narzędzia CLI do monitoringu ruchu per-procesowego: Co wybrać?

Choć iftop i nethogs są powszechnie znane, istnieje szereg innych narzędzi CLI, które mogą okazać się bardziej przydatne w konkretnych scenariuszach. Poniżej porównanie najpopularniejszych rozwiązań dostępnych w standardowych repozytoriach Debian, RHEL i Arch.

Kiedy którego narzędzia użyć?

• Potrzebujesz szybkiego przeglądu ruchu? Użyj bmon lub nload.
• Chcesz monitorować konkretne porty lub protokoły? iftop lub nftables.
• Musisz zidentyfikować procesy zużywające pasmo? tcptrack lub ss -tulnp.
• Potrzebujesz historycznych danych? vnstat.

Monitoring w kontenerach: Dlaczego nethogs zawodzi i jak to naprawić?

Narzędzia takie jak nethogs lub iftop nie widzą ruchu wewnątrz kontenerów Docker lub LXC, ponieważ działają one w oddzielnych przestrzeniach nazw sieciowych. Aby monitorować ruch w kontenerach, musisz użyć innych metod.

Metody monitoringu ruchu w kontenerach

1. Monitorowanie interfejsu docker0:

   sudo nethogs docker0

   To pokaże ruch na mostku sieciowym, ale nie rozróżni indywidualnych kontenerów.
2. Użycie docker stats:

   docker stats --no-stream

   Pokazuje zużycie CPU, pamięci i sieci na poziomie kontenera, ale nie szczegółowy ruch per-procesowy.
3. Wejście do przestrzeni nazw sieci kontenera:

   sudo nsenter -t $(docker inspect --format '{{.State.Pid}}' ) -n nethogs eth0

   Pozwala uruchomić nethogs wewnątrz kontenera.
4. Monitorowanie ruchu na interfejsach veth*:

   sudo nethogs vethXXX

   Interfejsy wirtualne veth są używane przez Docker i można je monitorować bezpośrednio.

Ograniczenia konteneryzacji

• Brak widoczności ruchu wewnątrz kontenera dla narzędzi działających na fizycznych interfejsach.
• Złożoność diagnostyki – konieczność łączenia kilku narzędzi (np. docker stats + nsenter).
• Problem z procesami „ukrytymi” – niektóre procesy mogą działać w trybie „rootless”, uniemożliwiając monitorowanie.

Czy libpcap jest lepszy od narzędzi jądrowych? Porównanie wydajności

Narzędzia oparte na libpcap (np. tcpdump, nethogs) i te używające interfejsów jądrowych (np. ss, ip) mają różne zalety i wady, zależne od przypadku użycia.

Narzędzia oparte na libpcap

Zalety:

• Pełny wgląd w pakiety – możesz analizować nagłówki pakietów, co jest przydatne do diagnostyki zaawansowanej (np. problemy z MTU, fragmentacją).
• Możliwość filtrowania na poziomie pakietów – np. tcpdump 'port 443 and host 1.2.3.4'.
• Wsparcie dla wielu protokołów – nie tylko TCP/IP, ale także np. ICMP, ARP.

Wady:

• Wysokie zużycie CPU przy dużym ruchu sieciowym – libpcap musi przechwytywać i analizować każdy pakiet.
• Brak informacji o procesach – chyba że narzędzie jest zintegrowane z proc (np. nethogs).
• Problem z ukrywaniem ruchu – niektóre atakujące procesy (np. rootkity) mogą ukrywać się przed libpcap.

Narzędzia oparte na interfejsach jądrowych (ss, ip)

Zalety:

• Szybkość i niskie obciążenie – narzędzia jądrowe działają bezpośrednio na strukturach danych jądra, bez konieczności przechwytywania pakietów.
• Informacje o procesach – ss -tulnp pokazuje, które procesy używają konkretnych portów.
• Stabilność – mniej podatne na błędy niż narzędzia oparte na libpcap.

Wady:

• Ograniczony wgląd w pakiety – nie zobaczysz szczegółów nagłówków pakietów.
• Brak możliwości filtrowania na poziomie pakietów – musisz polegać na filtrowaniu połączeń, a nie samych pakietów.
• Problem z niektórymi typami ruchu – np. ruch UDP lub multicast może być gorzej obsługiwany.

Podsumowanie: Jeśli potrzebujesz szybkiego przeglądu ruchu lub identyfikacji procesów, użyj narzędzi jądrowych. Jeśli potrzebujesz szczegółowej analizy pakietów (np. do debugowania protokołów), użyj libpcap.

Jak znaleźć „ukryte” procesy zużywające pasmo? Metody dla zaawansowanych administratorów

Niektóre procesy, szczególnie te działające z podwyższonymi uprawnieniami lub w przestrzeni użytkownika, celowo ukrywają się przed standardowymi narzędziami monitoringu. Aby je zidentyfikować, musisz użyć bardziej zaawansowanych technik.

1. Wykorzystanie lsof do identyfikacji procesów po portach

lsof (List Open Files) pozwala na wyświetlenie wszystkich procesów używających konkretnego portu:

sudo lsof -i :443 -P -n | awk '{print $1}' | sort | uniq -c

Wynik pokaże, które procesy ($1) używają portu 443. Możesz także filtrować po protokole:

sudo lsof -i tcp:80 -P -n

2. Monitorowanie grup kontroli (cgroup) z systemd-cgtop

Systemd pozwala na monitorowanie zużycia zasobów przez grupy procesów. Aby sprawdzić ruch sieciowy w konkretnej cgroup:

systemd-cgtop

Następnie naciśnij n (network) i i (interactive) dla bardziej szczegółowego widoku. Możesz także skonfigurować cgroup dla konkretnych procesów:

sudo systemd-run --slice=network-heavy --scope -t -p CPUQuota=50% -p MemoryLimit=1G /ścieżka/do/procesu

3. Logowanie połączeń sieciowych z auditd

auditd to narzędzie do monitoringu aktywności systemowej, które może logować wszystkie połączenia sieciowe podejrzanych procesów:

sudo auditctl -a exit,always -F arch=b64 -S socket -k network-connection
sudo cat /var/log/audit/audit.log | grep network-connection

Możesz także skonfigurować reguły, aby logować konkretne procesy:

sudo auditctl -w /ścieżka/do/procesu -p x -k suspicious-process

4. Użycie strace do monitoringu aktywności procesów

strace pozwala na śledzenie wszystkich wywołań systemowych procesu, w tym operacji sieciowych:

sudo strace -p PID_PROCESU -e trace=network

Powyższe pokaże wszystkie operacje sieciowe wykonywane przez proces, co może pomóc zidentyfikować podejrzane działania.

Automatyzacja monitoringu ruchu sieciowego: Skrypty, cron i systemy alertów

Aby skutecznie monitorować ruch sieciowy, nie wystarczy ręczne sprawdzanie narzędzi. Administratorzy powinni wdrożyć automatyzację, która pozwoli na:

• Regularne raportowanie ruchu.
• Wykrywanie anomalii i wysyłanie alertów.
• Długoterminową analizę trendów.

1. Skrypty do monitoringu ruchu

Poniżej przykładowy skrypt w Bash, który monitoruje ruch na interfejsie i wysyła alert, jeśli przekroczy próg:

#!/bin/bash

INTERFACE="eth0"
THRESHOLD=1000000  # 1 Mbps
LOG_FILE="/var/log/network_monitor.log"

# Pobierz ruch w ciągu ostatnich 5 minut
RX_BYTES=$(cat /sys/class/net/$INTERFACE/statistics/rx_bytes)
TX_BYTES=$(cat /sys/class/net/$INTERFACE/statistics/tx_bytes)

# Oblicz ruch w Mbps (przy założeniu stałej prędkości interfejsu)
RX_MBPS=$(echo "scale=2; $RX_BYTES * 8 / 1000000 / 300" | bc)
TX_MBPS=$(echo "scale=2; $TX_BYTES * 8 / 1000000 / 300" | bc)

# Zapisz do loga
echo "$(date) - RX: $RX_MBPS Mbps, TX: $TX_MBPS Mbps" >> $LOG_FILE

# Sprawdź próg
if (( $(echo "$RX_MBPS > $THRESHOLD" | bc -l) )) || (( $(echo "$TX_MBPS > $THRESHOLD" | bc -l) )); then
    echo "ALERT: Wysoki ruch sieciowy na $INTERFACE!" | mail -s "Alert sieciowy" admin@example.com
fi

Aby uruchamiać skrypt co 5 minut, dodaj go do cron:

*/5 * * * * /ścieżka/do/skryptu.sh

2. Integracja z Prometheus i Grafana

Jeśli używasz Prometheus do monitoringu, możesz skonfigurować exportera sieciowego (node_exporter), który zbiera statystyki ruchu sieciowego:

Przykładowa konfiguracja prometheus.yml:

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

Następnie skonfiguruj Grafanę, aby wizualizować dane:

1. Dodaj panel z zapytaniem:

rate(node_network_receive_bytes_total[5m]) * 8 / 1000000

2. Ustaw alert w Prometheus Alertmanager:

- alert: HighBandwidthUsage
  expr: rate(node_network_receive_bytes_total[5m]) > 1e8  # 100 Mbps
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Wysoki ruch sieciowy na {{ $labels.instance }}"

3. Wykorzystanie Netdata do monitoringu w czasie rzeczywistym

Netdata to lekki agent monitoringu, który automatycznie zbiera statystyki ruchu sieciowego i wizualizuje je w czasie rzeczywistym. Instalacja jest prosta:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Po instalacji Netdata automatycznie skonfiguruje panele dla ruchu sieciowego, zużycia pasma i aktywnych połączeń.

Podsumowanie: Jak skutecznie monitorować ruch sieciowy w Linuxie?

Diagnostyka problemów z przepustowością sieci w Linuxie wymaga połączenia nowoczesnych narzędzi jądrowych (ebpf, nftables) z klasycznymi metodami monitoringu. Kluczem jest:

• Identyfikacja „pożeraczy” pasma – użyj ss, tcptrack lub ebpf do śledzenia procesów.
• Monitorowanie w kontenerach – użyj docker stats, nsenter lub interfejsów veth.
• Automatyzacja procesu – wdrożenie skryptów, cron lub systemów takich jak Prometheus + Grafana.
• Wykrywanie ukrytych procesów – użyj auditd, lsof lub strace.

Pamiętaj, że każde narzędzie ma swoje ograniczenia – najlepsze efekty osiągniesz, łącząc kilka metod. Jeśli problem z siecią jest krytyczny, rozważ także audyt bezpieczeństwa, aby wykluczyć obecność rootkitów lub ataków.

Źródła

• https://www.tecmint.com/find-process-using-bandwidth-linux/
• https://www.kernel.org/doc/html/latest/networking/index.html
• https://www.kernel.org/doc/html/latest/bpf/index.html
• https://wiki.nftables.org/
• https://www.tcpdump.org/manpages/pcap.3pcap.html
• https://manpages.debian.org/testing/iproute2/ss.8.en.html
• https://docs.docker.com/network/
• https://github.com/netdata/netdata
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_audit_system/audit-filtering-configuration_configuring-audit-system
• https://prometheus.io/docs/alerting/latest/overview/