Palvelimen IP-osoitteen vaihdon jälkeen SNAT-sääntö nimeää yhä vanhan

Palvelin siirtyi uuteen osoitteeseen, asiakkaat yhdistävät yhä, eikä mikään heidän lähettämänsä saavuta internetiä. Juuri tämä jako on vihje: kuunteleva pistoke ja portin välitys selvisivät siirrosta, joten tunneli nousee, kun taas välitettyihin paketteihin sovellettava lähdekäännös nimeää yhä osoitteen, jota isäntä ei enää omista. Vastaukset näihin uudelleen kirjoitettuihin paketteihin menevät koneelle, jota ei enää ole.

Yhdistäminen ja välitys epäonnistuvat eri kohdissa

Muodostus riippuu päätepisteestä, jonka asiakkaat jo tuntevat: julkinen osoite, sen edessä oleva portin välitys ja sisällä oleva kuuntelija. Välitetty liikenne riippuu toisesta päätöksestä, joka tehdään sen jälkeen, kun paketti saapuu tunneliin, kun isäntä kirjoittaa lähteensä uudelleen, jotta vastaukset löytävät tien takaisin.

Osoitteen vaihto rikkoo vain toisen päätöksen, ja siksi oire luetaan muodossa "yhdistetty mutta ei internetiä". Se selittää myös, miksi tavalliset asiakaspuolen tarkistukset näyttävät terveiltä: kättely valmistuu, asiakas saa osoitteen, ja jopa ping palvelimen tunneliosoitteeseen voi vastata. Tunteja kuluu asiakkaalla vian takia, joka asuu toisella puolella, ja siksi sääntötaulu on ensimmäinen paikka, josta katsoa.

Lue sääntö ja sen laskurit ennen muokkausta

Listaa käännössäännöt laskureineen ja vertaa määritettyä lähdettä osoitteisiin, jotka isäntä todella omistaa. Kuolleeseen osoitteeseen uudelleen kirjoitettu sääntö näyttää yleensä liikennettä sisäänpäin, koska paketit saavuttavat sen ja käännätetään, eikä mitään paluusuunnassa.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Tarkista kolme kenttää paikan päällä: lähteentäsmäytyksen joukko, lähtöliitäntä jos sääntö nimeää sellaisen, ja poissulku, joka estää tunnelien välisen liikenteen uudelleenkirjoituksen. Se poissulku on helppo menettää muokkauksen aikana, ja sen menettäminen saa vertaisten välisen liikenteen näyttämään toimivalta, kun sen vastaukset kulkevat outoa reittiä.

Jos laskurit jäävät nollaan, paketit eivät koskaan saavuta tätä sääntöä eikä osoite ole nykyinen ongelma. Etsi kilpaileva sääntö ketjusta aiempaa, mikä tapahtuu, kun joku lisää korvaavan säännön sen sijaan, että muokkaisi alkuperäistä. Vertaa sääntönumeroita tulosteeseen, jonka kirjasit minuutti sitten. Järjestys on osa määritystä, ei kosmeettinen yksityiskohta.

Korvaa lähde tai lakkaa nimeämästä sitä

Kun isännällä on vakaa osoite, korvaa sääntö paikallaan sen sijaan, että lisäisit toisen. Sääntönumeron mukaan korvaaminen säilyttää järjestyksen, josta ketjun loppuosa riippuu.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Kun osoite jaetaan dynaamisesti, älä nimeä lähdettä lainkaan ja anna ytimen valita nykyinen lähtöliitännästä. Tämä muunnelma selviää seuraavasta siirrosta ilman muokkausta, sen kustannuksella, että se kätkee, mitä osoitetta käytettiin.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Vahvista, että IPv4-välitys on yhä käytössä hallitun määrityksen kautta, ja tee sääntö sitten pysyväksi jakelun omalla mekanismilla. Vain käynnissä olevassa ytimessä tehty muutos palaa seuraavassa uudelleenkäynnistyksessä, yleensä huoltoikkunassa, jota kukaan ei yhdistä muutokseen.

Kaksi tapaa tehdä korvaus väärin

Joukon kääntäminen palvelimen tunneliosoitteeseen sen LAN-osoitteen sijaan lähettää vastaukset suoraan takaisin tunneliin, missä ne reititetään asiakkaalle, joka ei koskaan pyytänyt niitä. Yhteys pysähtyy tavalla, joka näyttää reitityssilmukalta, koska se on sellainen.

Toisen käännöksen pinoaminen vanhan päälle on toinen virhe. Ensimmäinen täsmäävä sääntö voittaa, joten vanhentunut merkintä käsittelee paketteja, kunnes se poistetaan, ja uuden säännön laskurit pysyvät nollassa, kun kaikki syyttävät korvausta. Poista kaksoiskappale ennen kuin lisäät mitään uutta. Lue sitten luettelo vielä kerran ja vahvista, että joukkoon täsmää täsmälleen yksi käännös.

Jos tunneli kuljettaa myös IPv6:ta, toista koko katsaus toisessa pinossa. IPv6-oletusreitti ilman käännöstä ja ilman reititettyä etuliitettä epäonnistuu yhtä äänettömästi, ja se on helppo unohtaa, koska kaikki sen yläpuolella näyttää samalta.

Saapuvat palvelut tarvitsevat vastakkaisen käännöksen

VPN-asiakkaan palvelu, jonka on oltava saavutettavissa ulkoa, tarvitsee kohdekäännöksen, ei lähdekäännöstä: julkinen portti kirjoitetaan asiakkaan tunneliosoitteeseen ennen sisääntuloa. Välityspolku tarvitsee sitten nimenomaisen säännön, joka sallii tämän liikenteen.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Älä koskaan käännä porttia, joka kuljettaa itse tunnelia, koska se uudelleenkirjoitus katkaisee yhteyden, joka pitää palvelun saavutettavana. Pidä tunneliportti kokonaan kohdesääntöjen ulkopuolella. Tarkista lopuksi molemmista päistä: laskurit uudessa säännössä, lyhyt tallennus tunnelilaitteella ja yksi pyyntö tunnelin sisäiseen osoitteeseen ennen kuin kokeilet julkista.