eth0:0 er et navn, ikke en enhed: ret SNAT-reglen

En NAT-regel, der skulle give en VPN-klientpulje sin egen offentlige adresse, står på nul pakker, mens samme pulje fortsat går ud med den forkerte kilde. Reglen tager som regel ikke fejl af adressen; den tager fejl af interfacet. -o eth0:0 peger på en enhed, der ikke findes, fordi eth0:0 er et navn, der er knyttet til en adresse på eth0. At se på tællerne er den hurtigste måde at bekræfte det på, og rettelsen er mindre, end undersøgelsen antyder.

Tjek, hvad kernen kalder enheden

Læs de to visninger hver for sig, før du ændrer noget:

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

Linkoversigten viser interfaces. Adresseoversigten kan vise en ekstra IPv4-adresse, der bærer navnet eth0:0, og enheden for den adresse er stadig eth0. iproute2-håndbogen for adresser behandler navnet som et navn for adressen, ikke som et ekstra link, og det er netop den forskel, hele problemet drejer sig om.

Historien forklarer forvirringen. Den gamle ifconfig eth0:0 syntaks lignede virkelig et nyt interface, og scripts fra den tid henviser stadig til et. På et nutidigt system er aliaset et navn på en adresse, og intet i routing- eller netfilter-vejen behandler det som et selvstændigt udgangspunkt.

Tjek, hvad reglen faktisk ramte

Læs tællerne sammen med regellisten i stedet for fra hukommelsen:

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

En regel, hvis pakketæller bliver på nul, mens der flyder matchende trafik, bliver ikke evalueret, og en betingelse på udgangsinterfacet, der nævner eth0:0 er en almindelig årsag. Den udgangsenhed, routen har valgt, er eth0, så en betingelse, der leder efter et andet navn, bliver aldrig sand, uanset hvilken kildeadresse kernen valgte.

Ret betingelsen til den rigtige enhed, og lad navnet være ude af den. Hvis du skal skelne to klientpuljer, der deler den enhed, skal du skelne dem efter kildepræfiks, ikke efter et interfacenavn, der ikke kan findes. To regler med ikke-overlappende -s -match er læsbare og testbare; én regel med en opdigtet enhed er hverken det ene eller det andet. Giv hver regel en kommentar, der navngiver puljen, for om et halvt år vil præfikset alene ikke fortælle nogen, hvorfor den står der.

Tjek den rute, der valgte enheden

Postrouting-NAT kører, efter at routen allerede har valgt et udgangsinterface, så interfacet i reglen skal være det, routen valgte. Spørg kernen direkte med ip route get om en repræsentativ klientadresse, og læs både enheden og den kilde, den rapporterer.

Hvis svaret nævner eth0, er interface-delen af reglen afklaret. Hvis det nævner en tunneleenhed, når pakken aldrig den regel, du redigerer, og søgningen flytter til routingtabellen og dens prioriteter. En regel, der aldrig matcher, fordi pakken gik ud et andet sted, ser i tælleroutputtet ud som en regel med en fejlstavet enhed. Bekræft, hvilken af de to du har, før du redigerer noget, for den anden kræver en ændring i routingen frem for i teksten.

Vælg den oversatte kilde med vilje

Når enheden er rigtig, er kildeadressen en selvstændig beslutning. Dette er kun en illustrativ IPv4-pulje og en eksempeladresse:

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

At skrive en adresse ind i --to-source får ikke nogen til at route den tilbage til dig. Udbuderen eller adresseejeren skal levere svar for den adresse til denne vært, og adressen skal være en, du har tilladelse til at bruge. Er den ikke det, matcher reglen og oversætter, og svarene går stadig et andet sted hen.

At ændre kildeadressen er ikke det samme som at ændre uplink. Når det egentlige krav er en anden fysisk vej, skal routingpolitikken først vælge den vej; SNAT omskriver derefter kilden på den enhed, politikken valgte. Flere navne på eth0 giver hverken ruten eller tilladelsen.

Bekræft med en forbindelse, du lige har åbnet

Åbn en ny klientforbindelse i stedet for at genbruge en eksisterende. Connection tracking beholder den oversættelse, den registrerede, da flowet startede, så en gammel session kan blive ved med at bruge den tidligere kildeadresse og få en korrekt ny regel til at se i stykker ud. Se tælleren stige, og se derefter den oversatte kilde på ledningen eller i den anden ende.

Ved flere puljer, der deler et interface, skal du give hver en eksplicit kildematchning og sin egen oversættelsesadresse, holde dem i firewallens administrerede konfiguration og notere den rækkefølge, de evalueres i. Skriv derefter ned, hvad du bekræftede: enheden fra ip route get, tælleren der flyttede sig, og den kilde, den anden side så. Den registrering besvarer den næste rapport uden at gentage alias-forvirringen.