eth0:0 is een label, geen apparaat: herstel de SNAT-match

Een NAT-regel die één VPN-clientpool zijn eigen openbare adres moest geven, staat op nul pakketten, terwijl dezelfde pool nog steeds met de verkeerde bron naar buiten gaat. De regel heeft het meestal niet over het adres mis; hij heeft het over de interface mis. -o eth0:0 verwijst naar een apparaat dat niet bestaat, omdat eth0:0 een label is dat aan een adres op eth0 hangt. Naar de tellers kijken is de snelste manier om dat te bevestigen, en de correctie is kleiner dan het onderzoek suggereert.

Controleer hoe de kernel het apparaat noemt

Lees de twee weergaven apart voordat je iets verandert:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

De linklijst toont interfaces. De adreslijst kan een tweede IPv4-adres tonen dat het label eth0:0 draagt, en het apparaat voor dat adres is nog steeds eth0. De adressenhandleiding van iproute2 behandelt het label als een naam voor het adres, niet als een tweede link, en dat is precies het onderscheid waar het hele probleem om draait.

De geschiedenis verklaart de verwarring. De oude ifconfig eth0:0 syntaxis leek echt op een nieuwe interface, en scripts uit die tijd verwijzen er nog naar. Op een hedendaags systeem is de alias een label op een adres, en niets in het routerings- of netfilterpad behandelt het als een apart uitgangspunt.

Controleer waar de regel echt op matchte

Lees de tellers samen met de regellijst in plaats van uit je geheugen:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Een regel waarvan de pakketteller op nul blijft terwijl passend verkeer stroomt, wordt niet geëvalueerd, en een voorwaarde voor de uitgangsinterface die eth0:0 noemt is een veelvoorkomende oorzaak. Het uitgangsapparaat dat de route koos is eth0, dus een voorwaarde die een andere naam zoekt wordt nooit waar, welke bronadres de kernel ook koos.

Verander de voorwaarde naar het echte apparaat en laat het label erbuiten. Als je twee clientpools moet onderscheiden die dat apparaat delen, onderscheid ze dan op bronprefix, niet op een interfacenaam die niet kan bestaan. Twee regels met niet-overlappende -s -matches zijn leesbaar en testbaar; één regel met een verzonnen apparaat is geen van beide. Geef elke regel een commentaar dat de pool noemt, want over een half jaar zal de prefix alleen niemand vertellen waarom die er staat.

Controleer de route die het apparaat koos

Postrouting-NAT draait nadat de route al een uitgangsinterface heeft gekozen, dus de interface in de regel moet degene zijn die de route koos. Vraag de kernel rechtstreeks met ip route get voor een representatief clientadres en lees zowel het apparaat als de bron die het meldt.

Als het antwoord eth0 noemt, is het interface-deel van de regel beslecht. Als het een tunnelapparaat noemt, bereikt het pakket nooit de regel die je bewerkt, en het zoeken verschuift naar de routeringstabel en zijn prioriteiten. Een regel die nooit matcht omdat het pakket ergens anders naar buiten ging, ziet er in de telleruitvoer hetzelfde uit als een regel met een verkeerd gespeld apparaat. Bevestig welke van de twee je hebt voordat je iets bewerkt, want de tweede vraagt een routeringswijziging en niet een tekstwijziging.

Kies de vertaalde bron bewust

Zodra het apparaat klopt, is het bronadres een aparte beslissing. Dit is alleen een illustratieve IPv4-pool en een voorbeeldadres:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Een adres in --to-source schrijven zorgt er niet voor dat iemand het terug naar jou routeert. De upstreamprovider of de adresseigenaar moet antwoorden voor dat adres naar deze host afleveren, en het adres moet er een zijn die je mag gebruiken. Is dat niet zo, dan matcht de regel en vertaalt, en de antwoorden gaan alsnog ergens anders heen.

Het bronadres wijzigen is niet hetzelfde als de uplink wijzigen. Als de echte eis een ander fysiek pad is, moet het routeringsbeleid eerst dat pad kiezen; SNAT herschrijft daarna de bron op het apparaat dat het beleid koos. Meer labels op eth0 leveren noch de route noch de autorisatie.

Verifieer met een verbinding die je net hebt geopend

Open een nieuwe clientverbinding in plaats van een bestaande te hergebruiken. Connection tracking bewaart de vertaling die het bij de start van de flow vastlegde, dus een oude sessie kan het vorige bronadres blijven gebruiken en een correcte nieuwe regel kapot laten lijken. Zie de teller oplopen en bekijk daarna de vertaalde bron op de lijn of aan de andere kant.

Geef bij meerdere pools die één interface delen elk een expliciete bronmatch en hun eigen vertaaladres, houd ze in de beheerde configuratie van de firewall en noteer de volgorde waarin ze worden geëvalueerd. Leg daarna vast wat je hebt geverifieerd: het apparaat uit ip route get, de teller die bewoog en de bron die de andere kant zag. Die vastlegging beantwoordt het volgende rapport zonder de aliasverwarring te herhalen.