eth0:0 is 'n etiket, nie 'n toestel nie: herstel die SNAT-passing

'n NAT-reël wat aan een VPN-kliëntpoel sy eie publieke adres sou gee, staan op nul pakkette, terwyl dieselfde poel steeds onder die verkeerde bron uitgaan. Die reël is gewoonlik nie verkeerd oor die adres nie; dit is verkeerd oor die koppelvlak. -o eth0:0 verwys na 'n toestel wat nie bestaan nie, want eth0:0 is 'n etiket wat aan 'n adres geheg is, en die toestel vir daardie adres is eth0. Om die tellers te dophou is die vinnigste manier om dit te bevestig, en die regstelling is kleiner as wat die ondersoek laat lyk.

Kyk wat die kernel die toestel noem

Lees die twee aansigte afsonderlik voordat jy iets verander:

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

Die skakellys wys koppelvlakke. Die adreslys kan 'n tweede adres IPv4 wys wat die etiket dra: eth0:0, en die toestel vir daardie adres is steeds eth0. Die iproute2-adreshandleiding behandel die etiket as 'n naam vir die adres, nie as 'n tweede skakel nie, en dit is die onderskeid waarom die hele probleem draai.

Die geskiedenis verduidelik die verwarring. Die ou ifconfig eth0:0 -sintaks het regtig soos 'n nuwe koppelvlak gelyk, en skrifte uit daardie era verwys steeds na een. Op 'n huidige stelsel is die alias 'n etiket op 'n adres, en niks in die roete- of netfilter-pad behandel dit as 'n aparte uitgangspunt nie.

Kyk waaraan die reël werklik gekoppel het

Lees die tellers saam met die reëlbyslyn, nie uit die geheue nie:

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

'n Reël waarvan die pakkettelling op nul bly terwyl ooreenstemmende verkeer vloei, word nie geëvalueer nie, en 'n uitvoerkoppelvlak-voorwaarde wat eth0:0 noem, is 'n algemene oorsaak. Die uitvoertoestel wat deur die roete gekies is, is eth0, so 'n voorwaarde wat na 'n ander naam soek, word nooit waar nie, maak nie saak watter bronadres die kernel gekies het nie.

Verander die voorwaarde na die werklike toestel en laat die etiket daaruit. As jy twee kliëntpoele moet onderskei wat daardie toestel deel, onderskei hulle aan die bronvoorvoegsel, nie aan 'n koppelvlaknaam wat nie kan bestaan nie. Twee reëls met nie-oorvleuelende -s -passings is leesbaar en toetsbaar; een reël met 'n fiktiewe toestel is nie een van die twee nie. Gee elke reël 'n kommentaar wat die poel noem, want oor ses maande sal die voorvoegsel alleen vir niemand sê waarom dit daar is nie.

Kyk na die roete wat die toestel gekies het

Postrouting-NAT loop nadat die roete reeds 'n uitvoerkoppelvlak gekies het, dus die koppelvlak in die reël moet die een wees wat die roete gekies het. Vra die kernel direk met ip route get vir 'n verteenwoordigende kliëntadres en lees beide die toestel en die bron wat dit rapporteer.

As die antwoord eth0noem, is die koppelvlakdeel van die reël besleg. As dit 'n tonneltoestel noem, bereik die pakket nooit die reël wat jy wysig nie, en die soektog skuif na die roeteblad en sy prioriteite. 'n Reël wat nooit pas nie omdat die pakket elders uitgegaan het, lyk in die telleruitset identies aan 'n reël met 'n verkeerd gespelde toestel. Bevestig watter van die twee jy het voordat jy iets wysig, want die tweede vereis 'n roeteverandering eerder as 'n teksverandering.

Kies die vertaalde bron doelbewus

Sodra die toestel reg is, is die bronadres 'n aparte besluit. Dit is 'n illustratiewe poel IPv4 en slegs 'n voorbeeldadres:

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

Om 'n adres in --to-source te skryf, maak nie dat iemand dit na jou terugroeteer nie. Die opstroomverskaffer of die adreseienaar moet antwoorde vir daardie adres by hierdie gasheer aflewer, en die adres moet een wees wat jy gemagtig is om te gebruik. Is dit nie, sal die reël pas en vertaal, en die antwoorde sal steeds elders heen gaan.

Om die bronadres te verander is nie dieselfde as om die opstroom te verander nie. Wanneer die werklike vereiste 'n ander fisiese pad is, moet die roetebeleid eers daardie pad kies; SNAT herskryf dan die bron op watter toestel die beleid ook al gekies het. Om meer etikette by eth0 te voeg, voorsien nóg die roete nóg die magtiging.

Verifieer met 'n verbinding wat jy pas oopgemaak het

Maak 'n nuwe kliëntverbinding oop eerder as om 'n bestaande een te hergebruik. Verbindingsnasporing hou die vertaling wat dit aangeteken het toe die vloei begin het, so 'n ou sessie kan die vorige bronadres bly gebruik en 'n korrekte nuwe reël as stukkend laat lyk. Kyk hoe die teller styg en waarneem dan die vertaalde bron op die draad of aan die verre kant.

Vir verskeie poele wat een koppelvlak deel, gee elkeen 'n eksplisiete bronpassing en sy eie vertaaladres, hou hulle in die firewall se bestuurde konfigurasie, en let op die volgorde waarin hulle geëvalueer word. Teken dan aan wat jy geverifieer het: die toestel uit ip route get, die teller wat beweeg het, en die bron wat die ander kant gesien het. Daardie aantekening beantwoord die volgende verslag sonder om die alias-verwarring te herhaal.