NAT-sääntö, jonka piti antaa yhdelle VPN-asiakaspoolille oma julkinen osoite, seisoo nollassa paketissa, kun sama pool lähtee edelleen väärällä lähteellä. Sääntö ei yleensä erehdy osoitteesta; se erehtyy käyttöliittymästä. -o eth0:0 viittaa laitteeseen, jota ei ole olemassa, koska eth0:0 on nimi, joka on liitetty osoitteeseen laitteella eth0. Laskureiden katsominen on nopein tapa vahvistaa se, ja korjaus on pienempi kuin tutkinta antaa ymmärtää.

Tarkista, miksi ydin kutsuu laitetta

Lue kaksi näkymää erikseen ennen kuin muutat mitään:

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

Linkkiluettelo näyttää käyttöliittymät. Osoiteluettelo voi näyttää toisen IPv4-osoitteen, jolla on nimi eth0:0, ja kyseisen osoitteen laite on edelleen eth0. iproute2:n osoiteopas kohtelee nimeä osoitteen nimenä, ei toisena linkkinä, ja juuri se ero on koko ongelman ydin.

Historia selittää sekaannuksen. Vanha ifconfig eth0:0 syntaksi näytti todella uudelta käyttöliittymältä, ja sen ajan skriptit viittaavat yhä sellaiseen. Nykyisessä järjestelmässä alias on osoitteessa oleva nimi, eikä mikään reitityksen tai netfilterin polulla kohtele sitä erillisenä lähtöpisteenä.

Tarkista, mihin sääntö todella osui

Lue laskurit sääntöluettelon kanssa sen sijaan, että luottaisit muistiin:

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

Sääntö, jonka pakettilaskuri pysyy nollassa sopivan liikenteen virratessa, ei ole arvioitavana, ja lähtörajapinnan ehto, joka nimeää eth0:0 on yleinen syy. Reitin valitsema lähtölaite on eth0, joten toista nimeä etsivä ehto ei koskaan toteudu, riippumatta siitä, minkä lähdeosoitteen ydin valitsi.

Vaihda ehto todelliseen laitteeseen ja jätä nimi siitä pois. Jos sinun on erotettava kaksi asiakaspoolia, jotka jakavat laitteen, erota ne lähdeprefiksillä, älä rajapinnan nimellä, jota ei voi olla olemassa. Kaksi sääntöä, joissa ei ole päällekkäisiä -s -osumia, ovat luettavia ja testattavia; yksi sääntö keksityllä laitteella ei ole kumpaakaan. Anna jokaiselle säännölle kommentti, joka nimeää poolin, sillä puolen vuoden päästä pelkkä prefiksi ei kerro kenellekään, miksi se on siellä.

Tarkista reitti, joka valitsi laitteen

Postrouting-NAT ajetaan, kun reitti on jo valinnut lähtörajapinnan, joten säännön rajapinnan on oltava se, jonka reitti valitsi. Kysy ytimeltä suoraan komennolla ip route get edustavalle asiakasosoitteelle ja lue sekä laite että lähde, jonka se raportoi.

Jos vastaus nimeää eth0, säännön rajapintaosa on selvitetty. Jos se nimeää tunnelilaitteen, paketti ei koskaan saavuta muokkaamaasi sääntöä, ja etsintä siirtyy reititystauluun ja sen prioriteetteihin. Sääntö, joka ei koskaan osu, koska paketti lähti muualta, näyttää laskuritulosteessa samalta kuin sääntö, jossa laite on kirjoitettu väärin. Vahvista, kumpi tapaus sinulla on, ennen kuin muokkaat mitään, sillä jälkimmäinen vaatii reititysmuutoksen eikä tekstimuutosta.

Valitse käännetty lähde tarkoituksella

Kun laite on oikein, lähdeosoite on erillinen päätös. Tämä on vain havainnollistava IPv4-pooli ja esimerkkiosoite:

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

Osoitteen kirjoittaminen kohtaan --to-source ei saa ketään reitittämään sitä takaisin sinulle. Ylävirran tarjoajan tai osoitteen omistajan on toimitettava kyseisen osoitteen vastaukset tälle isännälle, ja osoitteen on oltava sellainen, jota sinulla on lupa käyttää. Jos ei ole, sääntö osuu ja kääntää, ja vastaukset menevät silti muualle.

Lähdeosoitteen vaihtaminen ei ole sama asia kuin ylävirran vaihtaminen. Kun todellinen vaatimus on eri fyysinen polku, reitityskäytännön on ensin valittava se polku; SNAT kirjoittaa sitten lähteen uudelleen laitteeseen, jonka käytäntö valitsi. Lisää nimiä laitteeseen eth0 ei anna reittiä eikä valtuutusta.

Vahvista yhteydellä, jonka juuri avasit

Avaa uusi asiakasyhteys sen sijaan, että käyttäisit olemassa olevaa uudelleen. Yhteyksien seuranta säilyttää käännöksen, jonka se kirjasi vuon alkaessa, joten vanha istunto voi jatkaa aiemman lähdeosoitteen käyttöä ja saada oikean uuden säännön näyttämään rikkinäiseltä. Seuraa laskurin kasvua ja katso sitten käännettyä lähdettä johdolla tai kauempana päässä.

Kun useat poolit jakavat yhden rajapinnan, anna kullekin selkeä lähdeosuma ja oma käännösosoite, pidä ne palomuurin hallitussa kokoonpanossa ja kirjaa, missä järjestyksessä ne arvioidaan. Kirjaa sitten, mitä varmistit: laite komennosta ip route get, liikkunut laskuri ja lähde, jonka vastapuoli näki. Se kirjaus vastaa seuraavaan raporttiin toistamatta alias-sekaannusta.

Aiheeseen liittyvät artikkelit