Linux netwerkproblemen oplossen: van ping tot DNS en SSH-storingen

Waarom een laag-voor-laag aanpak werkt

Netwerkproblemen voelen vaak als één grote zwarte doos: "de server is niet bereikbaar". In werkelijkheid bestaat je verbinding uit lagen, en elke laag bouwt op de vorige. Een DNS-fout zegt niets als je netwerkkaart geen link heeft. Een open poort helpt niet als de route naar de gateway ontbreekt.

Daarom loop je de stack altijd in dezelfde volgorde door. Je bespaart tijd, want zodra een stap faalt, hoef je de stappen erboven niet meer te onderzoeken. Zo ziet de volgorde eruit:

Stap 1: controleer de interface en de link

Dit is ook het antwoord op de vraag hoe je de netwerkverbinding in Linux controleert. Begin met een compact overzicht van al je interfaces:

ip -br link
ip -br addr

In de kolom STATE zie je UP, DOWN of UNKNOWN. Staat de interface op DOWN, dan is er geen kabel, de switchpoort is uit of de interface is administratief uitgeschakeld. Zet hem aan met sudo ip link set eth0 up. Gebruik je een virtuele machine, controleer dan ook of de virtuele netwerkkaart nog aan de juiste bridge of vSwitch hangt.

Meer details over snelheid en duplex haal je op met ethtool eth0. Een link die steeds op 100 Mbit/s of half-duplex onderhandelt, wijst vaak op een slechte kabel of poort. Kijk daarnaast in ip -s link show eth0: oplopende errors, dropped of overruns zijn een duidelijk signaal dat het probleem fysiek of in de driver zit.

Stap 2: IP-adres, ARP en routing

Staat de link omhoog, dan heeft de interface een IP-adres nodig. Heb je bij ip -br addr geen IPv4-adres, of een adres als 169.254.x.x, dan is DHCP niet gelukt. Controleer de DHCP-client (bijvoorbeeld systemctl status NetworkManager of systemd-networkd) en kijk in journalctl -u NetworkManager -n 50.

Zie je de gateway? ARP-controle

Je kunt een gateway alleen bereiken als je zijn MAC-adres kent. Bekijk de buurtabel:

ip neigh show
# 192.168.1.1 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE
# 192.168.1.1 dev eth0  FAILED

REACHABLE of STALE is prima. FAILED of INCOMPLETE betekent dat de gateway niet op ARP-verzoeken antwoordt: een VLAN-fout, een verkeerd subnetmasker of een dode router.

Routing en de default gateway

ip route
# default via 192.168.1.1 dev eth0 proto dhcp metric 100
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20

Ontbreekt de regel default via, dan weet de server niet waar hij verkeer naartoe moet sturen dat buiten het eigen subnet ligt. Dat is een klassieke oorzaak van "Linux geen internet" terwijl het lokale netwerk gewoon werkt. Controleer ook met ip route get 1.1.1.1 welke route en welk bronadres de kernel daadwerkelijk kiest.

Ping en traceroute in de juiste volgorde

1. Ping de gateway: ping -c 3 192.168.1.1. Faalt dit, dan zit het probleem op laag 2 of in de lokale configuratie.
2. Ping een extern IP: ping -c 3 1.1.1.1. Lukt dit niet, maar de gateway wel, dan ligt het bij routing, NAT of je provider.
3. Ping een hostnaam: ping -c 3 linuxhulp.nl. Lukt het IP wel maar de naam niet, dan is het een DNS-probleem (zie stap 3).

Wil je weten waar onderweg het misgaat, gebruik dan traceroute -n 1.1.1.1 of beter nog mtr -rwn 1.1.1.1. Die laatste combineert ping en traceroute en toont pakketverlies per hop. Let op: sterretjes (* * *) in het midden van een traceroute betekenen niet automatisch een probleem, veel routers beantwoorden ICMP gewoonweg niet. Pakketverlies dat blijft doorlopen tot de laatste hop is wél verdacht.

Het ip-commando versus ifconfig

Zoek je naar het ip commando linux en kom je nog oude handleidingen met ifconfig tegen? Dat commando maakt deel uit van het verouderde net-tools-pakket en is op veel moderne distributies niet meer standaard aanwezig. Het ip-commando uit iproute2 vervangt het volledig, inclusief route en arp.

Een praktisch voordeel: met ip -br krijg je een compacte tabel en met ip -j JSON-uitvoer die je met jq kunt verwerken in scripts en monitoring. Wijzigingen via ip zijn overigens tijdelijk; na een herstart zijn ze weg. Leg permanente configuratie vast in Netplan, NetworkManager of systemd-networkd, afhankelijk van je distributie.

Stap 3: een Linux DNS-probleem oplossen

Het klassieke symptoom: ping 1.1.1.1 werkt, maar ping linuxhulp.nl geeft "Temporary failure in name resolution". Je vraagt je dan af waarom DNS niet werkt op je Linux-server. Het zit bijna altijd in één van deze oorzaken:

• /etc/resolv.conf wijst naar een nameserver die niet bereikbaar is of niet meer bestaat;
• systemd-resolved draait niet, terwijl resolv.conf naar de stub-resolver 127.0.0.53 verwijst;
• een firewall blokkeert uitgaand verkeer op poort 53 (UDP én TCP);
• de DHCP-server geeft verkeerde DNS-servers mee;
• het domein zelf heeft een fout in de DNS-records of DNSSEC.

Bepaal of het lokaal of extern is

De snelste test is een query rechtstreeks naar een publieke resolver, zonder je lokale configuratie:

dig @1.1.1.1 linuxhulp.nl +short
dig linuxhulp.nl +short
getent hosts linuxhulp.nl

Werkt de eerste wel en de tweede niet, dan is je lokale resolver het probleem. Werken beide niet, dan wordt poort 53 waarschijnlijk geblokkeerd of is het domein zelf stuk. Gebruik getent hosts als laatste test: dat doorloopt dezelfde route als de meeste applicaties (via nsswitch.conf), terwijl dig altijd direct een DNS-server bevraagt. Een afwijking tussen die twee verklaart vaak waarom "dig het wel doet, maar mijn applicatie niet".

Controleer de resolverconfiguratie

cat /etc/resolv.conf
resolvectl status
systemctl status systemd-resolved
sudo resolvectl flush-caches

Met resolvectl status zie je per interface welke DNS-servers actief zijn. Staat er niets of een verkeerd adres, pas dan de configuratie in Netplan of NetworkManager aan in plaats van /etc/resolv.conf met de hand te bewerken, want die wordt vaak overschreven. Zoek je een tijdelijke oplossing in een noodgeval? Dan helpt sudo resolvectl dns eth0 1.1.1.1 9.9.9.9 om meteen weer namen te kunnen vertalen.

Let tot slot op de zoekdomeinen (search in resolv.conf) en de instelling ndots. Die zorgen er soms voor dat een korte hostnaam eerst op een verkeerd domein wordt gezocht, met trage of foute resultaten als gevolg. Dat zie je veel in containeromgevingen.

Stap 4: testen of een poort open staat

De derde veelgestelde vraag: hoe test je of een poort open staat op een Linux-server? Dat is eigenlijk twee vragen. Luistert de service überhaupt, en komt het verkeer er van buitenaf door?

Luistert de service? Gebruik ss

sudo ss -tulpn
sudo ss -tlpn 'sport = :443'

De vlaggen staan voor TCP, UDP, listening, process en numeriek. Let op het lokale adres: 127.0.0.1:5432 betekent dat de service alleen lokaal bereikbaar is. Zie je 0.0.0.0:5432 of *:5432, dan luistert hij op alle interfaces. Heel vaak is "poort niet bereikbaar" simpelweg een service die alleen op localhost luistert.

Komt het verkeer door? Gebruik nc

Test vanaf een andere machine:

nc -zv 192.168.1.20 443
# Connection to 192.168.1.20 443 port [tcp/https] succeeded!
nc -zv -w 3 192.168.1.20 8080
# nc: connect to 192.168.1.20 port 8080 (tcp) failed: Connection refused

De foutmelding vertelt veel. Connection refused betekent dat de machine bereikbaar is, maar er niets op die poort luistert (of een firewall actief weigert). Timeout betekent meestal dat een firewall de pakketten stilletjes weggooit. Dat onderscheid scheelt je uren zoeken.

Firewallregels bekijken

sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset

Welk commando past, hangt af van je distributie: ufw op Ubuntu, firewalld op RHEL en afgeleiden, nft als onderliggende laag. Vergeet ook niet de firewall van je hostingprovider (security groups of cloud firewalls), want die staat buiten de server en zie je dus niet in nft.

SSH-verbinding verbroken: oorzaken en oplossingen

Als je SSH-verbinding verbroken wordt, hangt de aanpak af van het moment waarop dat gebeurt. Er zijn grofweg drie scenario's.

1. Je kunt niet eens verbinden

Draai de client in verbose-modus om te zien waar het vastloopt:

ssh -vvv gebruiker@192.168.1.20

Blijft het hangen bij Connecting to..., dan is het een netwerk- of firewallprobleem: ga terug naar stap 2 en 4. Krijg je Connection refused, dan draait sshd niet of luistert hij op een andere poort (sudo systemctl status sshd). Krijg je Permission denied (publickey), dan ligt het aan authenticatie en niet aan het netwerk.

2. De verbinding valt weg na een tijd van inactiviteit

Dit is de meest voorkomende oorzaak van "Broken pipe" of "Connection reset by peer": een NAT-router of firewall gooit de sessie weg omdat er te lang geen verkeer was. Stuur keepalives vanaf de client in ~/.ssh/config:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

Aan de serverkant bestaan ClientAliveInterval en ClientAliveCountMax in /etc/ssh/sshd_config. Herstart daarna sshd met sudo systemctl restart sshd, maar houd altijd een tweede sessie open voordat je dat doet, zodat je jezelf niet buitensluit.

3. De verbinding crasht bij veel data of grote pakketten

Lukt inloggen wel, maar bevriest de sessie zodra je een groot bestand uitleest of ls in een grote map draait? Dan is er vrijwel zeker een MTU-probleem, bijvoorbeeld door een VPN of tunnel. Test het met:

ping -M do -s 1472 -c 3 192.168.1.20

Krijg je "Frag needed" of verlies je pakketten, verlaag dan de grootte (-s 1400, -s 1300) tot het werkt. Zo bepaal je de werkelijke MTU, die je vervolgens op de interface of tunnel aanpast. Controleer ook journalctl -u sshd en /var/log/auth.log op de server: tools als fail2ban kunnen je eigen IP-adres tijdelijk geblokkeerd hebben.

Snelle tabel: symptoom naar oorzaak

Wanneer schakel je hulp in?

Met bovenstaande aanpak los je het grootste deel van de gewone netwerkstoringen zelf op. Toch zijn er situaties waarin het verstandig is om iemand mee te laten kijken:

• een productieserver is onbereikbaar en elke minuut downtime kost geld;
• je ziet intermitterend pakketverlies dat je niet reproduceert;
• je vermoedt een aanval, bijvoorbeeld een DDoS of een gecompromitteerde server die vreemd verkeer genereert;
• je hebt je buitengesloten door een verkeerde firewall- of SSH-wijziging;
• het probleem speelt in complexe omgevingen met bonding, VLANs, VPN's of containernetwerken.

Bij LinuxHulp.nl werken we al meer dan 30 jaar met Linux-omgevingen en kunnen we op afstand meekijken, ook 's nachts en in het weekend. Wil je netwerkproblemen voorkomen in plaats van oplossen? Met een SLA-abonnement bewaken we je servers actief. De tarieven vind je op de prijzenpagina, en meer antwoorden op de FAQ-pagina.