eth0:0 är en etikett, inte en enhet: rätta SNAT-träffen

En NAT-regel som skulle ge en VPN-klientpool dess egen publika adress står på noll paket, medan samma pool fortsätter att gå ut med fel källa. Regeln har oftast inte fel om adressen; den har fel om gränssnittet. -o eth0:0 pekar på en enhet som inte finns, eftersom eth0:0 är en etikett som är fäst vid en adress på eth0. Att titta på räknarna är det snabbaste sättet att bekräfta det, och rättelsen är mindre än utredningen antyder.

Kontrollera vad kärnan kallar enheten

Läs de två vyerna var för sig innan du ändrar något:

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

Länklistan visar gränssnitt. Adresslistan kan visa en andra IPv4-adress som bär etiketten eth0:0, och enheten för den adressen är fortfarande eth0. Adresshandboken för iproute2 behandlar etiketten som ett namn för adressen, inte som en andra länk, och det är just den skillnaden hela problemet kretsar kring.

Historien förklarar förvirringen. Den gamla ifconfig eth0:0 syntaxen såg verkligen ut som ett nytt gränssnitt, och skript från den tiden refererar fortfarande till ett. På ett modernt system är aliaset en etikett på en adress, och ingenting i routing- eller netfiltervägen behandlar det som en egen utgångspunkt.

Kontrollera vad regeln faktiskt träffade

Läs räknarna tillsammans med regellistan i stället för ur minnet:

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

En regel vars paketräknare stannar på noll medan matchande trafik flyter utvärderas inte, och ett villkor för utgångsgränssnittet som namnger eth0:0 är en vanlig orsak. Den utgångsenhet som rutten valde är eth0, så ett villkor som letar efter ett annat namn blir aldrig sant, oavsett vilken källadress kärnan valde.

Ändra villkoret till den verkliga enheten och lämna etiketten utanför. Om du behöver skilja på två klientpooler som delar den enheten, skilj dem på källprefix, inte på ett gränssnittsnamn som inte kan finnas. Två regler med icke överlappande -s -träffar är läsbara och testbara; en regel med en påhittad enhet är ingetdera. Ge varje regel en kommentar som namnger poolen, för om ett halvår kommer prefixet ensamt inte att berätta för någon varför den står där.

Kontrollera rutten som valde enheten

Postrouting-NAT körs efter att rutten redan har valt ett utgångsgränssnitt, så gränssnittet i regeln måste vara det som rutten valde. Fråga kärnan direkt med ip route get för en representativ klientadress och läs både enheten och den källa den rapporterar.

Om svaret namnger eth0, är gränssnittsdelen av regeln avgjord. Om det namnger en tunnelenhet når paketet aldrig regeln du redigerar, och sökningen flyttar till routingtabellen och dess prioriteringar. En regel som aldrig träffar därför att paketet gick ut någon annanstans ser i räknarutskriften likadan ut som en regel med en felstavad enhet. Bekräfta vilket av de två fallen du har innan du redigerar något, för det andra kräver en routingändring och inte en textändring.

Välj den översatta källan med avsikt

När enheten är rätt är källadressen ett eget beslut. Detta är bara en illustrativ IPv4-pool och en exempeladress:

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

Att skriva en adress i --to-source får ingen att routa den tillbaka till dig. Leverantören uppströms eller adressägaren måste leverera svar för den adressen till den här värden, och adressen måste vara en du har tillåtelse att använda. Om inte kommer regeln att träffa och översätta, och svaren går ändå någon annanstans.

Att ändra källadressen är inte samma sak som att ändra upplänken. När det verkliga kravet är en annan fysisk väg måste routingpolicyn först välja den vägen; SNAT skriver sedan om källan på den enhet policyn valde. Fler etiketter på eth0 ger varken rutten eller tillståndet.

Verifiera med en anslutning du just öppnade

Öppna en ny klientanslutning i stället för att återanvända en befintlig. Anslutningsspårningen behåller den översättning den registrerade när flödet började, så en gammal session kan fortsätta använda den tidigare källadressen och få en korrekt ny regel att se trasig ut. Se räknaren öka och betrakta sedan den översatta källan på ledningen eller i andra änden.

För flera pooler som delar ett gränssnitt, ge var och en en uttrycklig källträff och sin egen översättningsadress, håll dem i brandväggens hanterade konfiguration och notera ordningen de utvärderas i. Skriv sedan ned vad du verifierade: enheten från ip route get, räknaren som flyttade sig och källan som den andra sidan såg. Den anteckningen svarar på nästa rapport utan att upprepa aliasförvirringen.