Een VPN-peer pingt andere interfaces omdat ze lokaal zijn
De lokale routetabel stuurt pakketten naar elk adres dat de host bezit, op welke interface het ook staat. Doorstuurinstellingen komen die route nooit binnen.
Een WireGuard-client maakt verbinding en pingt een adres op een heel andere interface, en het antwoord komt aan. Opnames tonen het verzoek alleen op de tunnel. Niets is kapot, en de zorgvuldig uitgeschakelde doorstuurinstelling heeft er niets mee te maken. Dit is een vergelijking tussen twee paden die op een diagram hetzelfde lijken en in de kernel volledig verschillend zijn.
Het ene pad stuurt pakketten door voor iemand anders; het andere levert ze af bij de host zelf.
Een pakket dat aan de host is gericht, blijft in de host
De externe client stuurt een IP-pakket naar een adres dat de host bezit. Routering stelt één vraag over dat pakket: is deze bestemming lokaal? Elk adres dat de host heeft, staat in de lokale routetabel, en die tabel wordt vóór de hoofdtabel geraadpleegd, dus het pakket gaat naar de eigen stack van de host in plaats van via een andere interface naar buiten. Het antwoord wordt lokaal gegenereerd, en het reist terug door de tunnel omdat de query daar vandaan kwam.
Dat is het hele mechanisme. Er vindt geen doorsturing plaats, er is geen wijziging van interfacestatus bij betrokken, en het adres in kwestie hoeft nergens anders bereikbaar te zijn.
Waarom ip_forward niet geldt
Doorsturing beheert pakketten die via een andere interface moeten vertrekken dan die waarop ze aankwamen. Een ping naar de host zelf neemt dat pad nooit: het pakket wordt lokaal verbruikt en het antwoord wordt lokaal gegenereerd. Het instellen van net.ipv4.ip_forward=0 verandert hier dus niets, en een regel in de doorstuurketen ziet dat verkeer nooit. De juiste controle zit op het invoerpad, beperkt door inkomende interface of bron.
Daarom geeft het uitschakelen van doorsturing en aannemen dat de host geïsoleerd is een vals gevoel van veiligheid.
Lees de lokale tabel die besliste
ip rule show meldt gewoonlijk een regel met prioriteit nul die alle opzoekingen eerst naar de lokale tabel stuurt, en ip route show table local somt de eigen adressen van de host op met lokale scope. Die tabel bevat adressen op interfaces die administratief uit staan maar nog steeds geconfigureerd zijn. Statisch toegewezen IPv4-adressen overleven meestal een linkstoring, en daardoor kan een ping naar een uitgevallen bridge nog steeds slagen en de operator verrassen.
IPv6 is het op precies dit punt oneens. De adressen worden gewoonlijk ingetrokken wanneer de link wegvalt, tenzij keep_addr_on_down is ingesteld. Vergelijk de families in plaats van aan te nemen dat één regel beide dekt.
Wat een peer werkelijk bereikt
Een antwoord van het eigen adres van de router op een segment zegt niets over de machines achter dat segment. De peer kan via dit pad geen host achter de andere interface bereiken; hij bereikt alleen adressen die de router zelf bezit. Een dienst testen op een aparte LAN-host, in plaats van de router pingen, is wat vaststelt of doorsturing überhaupt is toegestaan.
Een peer beperken tot diensten die aan het tunneladres zijn gebonden is een kwestie van invoerbeleid. Sta de gewenste dienst toe op de tunnelinterface en beperk de bronnen die ervan gebruik mogen maken, want het pakket komt daar echt aan.
Controleer ook adressen die je wilde uitfaseren. Een adres van een interface verwijderen is betrouwbaarder dan firewallregels stapelen op een verouderd adres.