eth0:0 er ei etikett, ikkje eining: rett opp SNAT-treffet

Ein NAT-regel som skulle gi éin VPN-klientpool si eiga offentlege adresse, står på null pakkar, medan den same poolen framleis går ut med feil kjelde. Regelen tek som regel ikkje feil av adressa; han tek feil av grensesnittet. -o eth0:0 peikar på ei eining som ikkje finst, fordi eth0:0 er ei etikett som er fest til ei adresse på eth0. Å sjå på teljarane er den raskaste måten å stadfeste det på, og rettinga er mindre enn undersøkinga antyder.

Sjekk kva kjernen kallar eininga

Les dei to visingane kvar for seg før du endrar noko:

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

Lenkjelista viser grensesnitt. Adresselista kan vise ei andre IPv4-adresse som ber etiketten eth0:0, og eininga for den adressa er framleis eth0. Adressehandboka til iproute2 behandlar etiketten som eit namn for adressa, ikkje som ei andre lenkje, og det er nettopp denne skilnaden heile problemet dreiar seg om.

Historia forklarar forvirringa. Den gamle ifconfig eth0:0 syntaksen såg verkeleg ut som eit nytt grensesnitt, og skript frå den tida viser framleis til eitt. På eit moderne system er aliaset ei etikett på ei adresse, og ingenting i rutings- eller netfiltervegen behandlar det som eit eige utgangspunkt.

Sjekk kva regelen faktisk trefte

Les teljarane saman med regellista i staden for frå minnet:

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

Ein regel der pakketeljaren blir ståande på null medan samsvarande trafikk flyt, blir ikkje vurdert, og eit vilkår på utgangsgrensesnittet som namngir eth0:0 er ein vanleg årsak. Utgangseininga som ruta valde, er eth0, så eit vilkår som leitar etter eit anna namn blir aldri sant, same kva kjeldeadresse kjernen valde.

Endre vilkåret til den verkelege eininga og lat etiketten vere utanfor. Viss du må skilje to klientpoolar som deler den eininga, skil dei etter kjelde-prefiks, ikkje etter eit grensesnittnamn som ikkje kan finnast. To reglar med ikkje-overlappande -s -treff er lesbare og testbare; éin regel med ei oppdikta eining er ingen av delane. Gi kvar regel ein kommentar som namngir poolen, for om eit halvt år vil prefikset åleine ikkje fortelje nokon kvifor den står der.

Sjekk ruta som valde eininga

Postrouting-NAT køyrer etter at ruta allereie har valt eit utgangsgrensesnitt, så grensesnittet i regelen må vere det ruta valde. Spør kjernen direkte med ip route get for ei representativ klientadresse og les både eininga og kjelda ho rapporterer.

Viss svaret namngir eth0, er grensesnittdelen av regelen avklart. Viss det namngir ei tunnel-eining, når pakken aldri regelen du redigerer, og søket flyttar seg til rutetabellen og prioriteringane hans. Ein regel som aldri treffer fordi pakken gjekk ut ein annan stad, ser lik ut i teljarutskrifta som ein regel med feilskriven eining. Stadfest kva av dei to tilfella du har før du redigerer noko, for det andre krev ei rutingendring og ikkje ei tekstendring.

Vel den omsette kjelda med vilje

Når eininga er riktig, er kjeldeadressa ei eiga avgjerd. Dette er berre ein illustrerande IPv4-pool og ei dømeadresse:

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

Å skrive ei adresse inn i --to-source får ingen til å rute ho tilbake til deg. Oppstraumsleverandøren eller adresseigaren må levere svar for den adressa til denne verten, og adressa må vere ei du har lov til å bruke. Viss ikkje, vil regelen treffe og omsetje, og svara går framleis ein annan stad.

Å endre kjeldeadressa er ikkje det same som å endre oppstraumslenkja. Når det eigentlege kravet er ein annan fysisk veg, må rutingpolitikken først velje den vegen; SNAT skriv deretter om kjelda på den eininga politikken valde. Fleire etikettar på eth0 gir korkje ruta eller løyvet.

Stadfest med ei tilkopling du nett opna

Opne ei ny klienttilkopling i staden for å bruke om att ei eksisterande. Tilkoplingssporing held på omsetjinga ho registrerte då straumen starta, så ei gammal økt kan halde fram med å bruke den førre kjeldeadressa og få ein korrekt ny regel til å sjå øydelagd ut. Sjå teljaren auke, og sjå deretter den omsette kjelda på leidningen eller i den andre enden.

For fleire poolar som deler eitt grensesnitt, gi kvar sin eksplisitte kildetreff og si eiga omsetjingsadresse, hald dei i den administrerte konfigurasjonen til brannmuren og noter rekkjefølgja dei blir vurderte i. Skriv deretter ned kva du stadfesta: eininga frå ip route get, teljaren som flytta seg og kjelda den andre sida såg. Den registreringa svarer på neste rapport utan å gjenta alias-forvirringa.