eth0:0 er en etikett, ikke en enhet: rett opp SNAT-treffet

En NAT-regel som skulle gi én VPN-klientpool sin egen offentlige adresse, står på null pakker, mens den samme poolen fortsatt går ut med feil kilde. Regelen tar som regel ikke feil av adressen; den tar feil av grensesnittet. -o eth0:0 peker på en enhet som ikke finnes, fordi eth0:0 er en etikett som er festet til en adresse på eth0. Å se på tellerne er den raskeste måten å bekrefte det på, og rettelsen er mindre enn undersøkelsen antyder.

Sjekk hva kjernen kaller enheten

Les de to visningene hver for seg før du endrer noe:

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

Lenkelisten viser grensesnitt. Adresselisten kan vise en andre IPv4-adresse som bærer etiketten eth0:0, og enheten for den adressen er fortsatt eth0. Adressehåndboken til iproute2 behandler etiketten som et navn for adressen, ikke som en andre lenke, og det er nettopp denne forskjellen hele problemet dreier seg om.

Historien forklarer forvirringen. Den gamle ifconfig eth0:0 syntaksen så virkelig ut som et nytt grensesnitt, og skript fra den tiden viser fortsatt til ett. På et moderne system er aliaset en etikett på en adresse, og ingenting i ruting- eller netfilterveien behandler det som et eget utgangspunkt.

Sjekk hva regelen faktisk traff

Les tellerne sammen med regellisten i stedet for fra hukommelsen:

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

En regel der pakketelleren blir stående på null mens samsvarende trafikk flyter, blir ikke evaluert, og en betingelse på utgangsgrensesnittet som navngir eth0:0 er en vanlig årsak. Utgangsenheten som ruten valgte, er eth0, så en betingelse som leter etter et annet navn blir aldri sann, uansett hvilken kildeadresse kjernen valgte.

Endre betingelsen til den virkelige enheten og la etiketten være utenfor. Hvis du må skille to klientpooler som deler den enheten, skill dem etter kilde-prefiks, ikke etter et grensesnittnavn som ikke kan finnes. To regler med ikke-overlappende -s -treff er lesbare og testbare; én regel med en oppdiktet enhet er ingen av delene. Gi hver regel en kommentar som navngir poolen, for om et halvt år vil prefikset alene ikke fortelle noen hvorfor den står der.

Sjekk ruten som valgte enheten

Postrouting-NAT kjører etter at ruten allerede har valgt et utgangsgrensesnitt, så grensesnittet i regelen må være det ruten valgte. Spør kjernen direkte med ip route get for en representativ klientadresse og les både enheten og kilden den rapporterer.

Hvis svaret navngir eth0, er grensesnittdelen av regelen avklart. Hvis det navngir en tunnel-enhet, når pakken aldri regelen du redigerer, og søket flytter seg til rutetabellen og dens prioriteringer. En regel som aldri treffer fordi pakken gikk ut et annet sted, ser lik ut i tellerutskriften som en regel med feilskrevet enhet. Bekreft hvilket av de to tilfellene du har før du redigerer noe, for det andre krever en rutingendring og ikke en tekstendring.

Velg den oversatte kilden med vilje

Når enheten er riktig, er kildeadressen en egen beslutning. Dette er bare en illustrerende IPv4-pool og en eksempeladresse:

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

Å skrive en adresse inn i --to-source får ingen til å rute den tilbake til deg. Oppstrømsleverandøren eller adresseieren må levere svar for den adressen til denne verten, og adressen må være en du har lov til å bruke. Hvis ikke, vil regelen treffe og oversette, og svarene går fortsatt et annet sted.

Å endre kildeadressen er ikke det samme som å endre oppstrømslenken. Når det egentlige kravet er en annen fysisk vei, må rutingpolitikken først velge den veien; SNAT skriver deretter om kilden på den enheten politikken valgte. Flere etiketter på eth0 gir verken ruten eller tillatelsen.

Verifiser med en tilkobling du nettopp åpnet

Åpne en ny klienttilkobling i stedet for å gjenbruke en eksisterende. Tilkoblingssporing beholder oversettelsen den registrerte da strømmen startet, så en gammel økt kan fortsette å bruke den forrige kildeadressen og få en korrekt ny regel til å se ødelagt ut. Se telleren øke, og se deretter den oversatte kilden på ledningen eller i den andre enden.

For flere pooler som deler ett grensesnitt, gi hver sin eksplisitte kildetreff og sin egen oversettelsesadresse, hold dem i brannmurens administrerte konfigurasjon og noter rekkefølgen de evalueres i. Skriv deretter ned hva du verifiserte: enheten fra ip route get, telleren som flyttet seg og kilden den andre siden så. Den registreringen svarer på neste rapport uten å gjenta alias-forvirringen.