Miksi net.ipv4.conf.default.forwarding jättää tun0:n rauhaan

Asetit net.ipv4.conf.default.forwarding=1, käynnistit VPN:n uudelleen, ja tunneli pudottaa edelleen paketteja, jotka yhdyskäytävän pitäisi reitittää. Asetus näyttää tiedostossa oikealta, ja liitäntä ilmoittaa edelleen, että edelleenlähetys on pois päältä. Mikään ei ole rikki: muutit arvoa, jonka tulevat liitännät perivät, et sitä, jota elävä tunneli käyttää.

Käy tämä läpi sillä isännällä, joka omistaa tunnelin, siinä verkkonamespacessa, jossa tunneli todella on. Kontti tai verkkonamespace voi pitää liitäntää, kun taas isäntä näyttää eri lukuja.

Lue kolme arvoa yhdessä

Aloita vertaamalla yhdyskäytävän laajuista kytkintä, uusien liitäntöjen mallipohjaa ja liitäntää, josta välität. Korvaa tun0 todellisella saapuvalla liitännällä ja lue myös paluuliitäntä, koska edelleenlähetys arvioidaan siinä pisteessä, johon paketti saapuu.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Yleinen tulos on ip_forward = 0, default.forwarding = 1 ja tun0.forwarding = 0. Kaksi ensimmäistä ovat eri mieltä isännän roolista, ja kolmas näyttää, mitä liitäntä todella tekee. Yhdistelmä sopii isäntään, jota ei koskaan määritetty reitittimeksi vaan jolle annettiin vain mallipohjan arvo. Kolme lukua eivät ole ristiriidassa; ne vastaavat kolmeen eri kysymykseen. Mallipohjan arvon kirjoittaminenkaan ei ratkaise isännän roolia.

Miksi juuri globaali kytkin liikkuu

net.ipv4.ip_forward on yhdyskäytävän laajuinen ohjaus. Sen muuttaminen päivittää liitäntäkohtaiset edelleenlähetysasetukset osana samaa toimenpidettä, minkä vuoksi yksi kirjoitus voi saada olemassa olevan tunnelin lähettämään edelleen. default.forwarding kylvää vain liitäntöjä, jotka alustetaan myöhemmin, joten jo olemassa ollut tunneli säilyttää arvon, jonka kanssa se syntyi.

Ytimen dokumentaatio merkitsee ip_forward erityiseksi yhteen liittyvästä syystä: sen muuttaminen nollaa joukon muita IPv4-parametreja isännän tai reitittimen oletusarvoihin. Se tekee siitä karkean työkalun. Sen asettaminen kerran osana yhdyskäytäväroolin käyttöönottoa on kunnossa; sen vaihtaminen toistuvasti virityskikkana voi hiljaa kirjoittaa uudelleen asetukset, joiden oikein saamiseen käytit aikaa.

Liitäntäkohtaiset arvot ovat myös olemassa syystä. Tarkoituksella hallittu yhdyskäytävä voi pitää edelleenlähetyksen pois liitännästä, jonka ei koskaan pitäisi reitittää, vaikka isäntä lähettäisi muualla edelleen. Siksi elävän liitännän lukeminen on tärkeää ja siksi pelkkä globaali arvo ei ole koko vastaus. Lue tällainen poikkeus tietoisena päätöksenä ja kirjoita muistiin, miksi kyseinen liitäntä on erilainen. Muuten seuraava insinööri "korjaa" sen avuliaasti.

Tee asetuksesta pysyvä oikeassa paikassa

Onnistunut kertaluonteinen sysctl -w todistaa, että ydin hyväksyy arvon. Se ei selviä uudelleenkäynnistyksestä eikä selviä verkkohallinnasta, joka uudelleenyhdistettäessä soveltaa jälleen omaa käsitystään liitännän asetuksista. Laita yhdyskäytävärooli sysctl-asetustiedostoon tai verkkohallintaan, joka omistaa isännän ja käynnistä sitten palvelu, joka sen soveltaa, uudelleen.

Järjestyksellä on merkitystä tunneleissa. Jos hallinta luo liitännän käynnistyksen yhteydessä ja soveltaa edelleenlähetystä vasta sen jälkeen, liitäntä voi periä vanhan oletusarvon. Palvelun uudelleenkäynnistys, joka luo tunnelin uudelleen, on myös luontitapahtuma, ja se on helppo jättää huomaamatta, kun unit näyttää terveeltä. Tarkista järjestys, ei vain tiedoston lopullinen sisältö.

Lue samat kolme arvoa uudelleen, kun VPN on yhdistänyt uudelleen, ja vielä kerran uudelleenkäynnistyksen jälkeen. Äskettäin luotu tunneli on uusi liitäntä, ja uusi liitäntä ottaa luontihetkellä voimassa olevan oletusarvon. Jos luvut muuttuvat näiden tapahtumien välillä, asetuksia soveltaa jokin, jota et ole vielä tunnistanut.

Älä korjaa tätä väärällä työkalulla

Kun edelleenlähetys näytti rikkinäiseltä, houkutus on tyhjentää palomuuri tai lisätä masquerading. Kumpikaan ei käsittele edelleenlähetyskytkintä. Edelleenlähetyksen tila, lupa lähettää edelleen, reitti kohteeseen ja paluupolku ovat neljä erillistä vaatimusta, ja vain ensimmäinen on sysctl.

Testaa myös oikealla virtauksella. Yhdyskäytävällä itsellään tehty pyyntö ei harjoita edelleenlähetystä lainkaan; se on paikallisesti tuotettua liikennettä. Kysymys on, otetaanko VPN-asiakkaalta tai LAN-isännältä saapuva paketti vastaan ja reititetäänkö se edelleen, joten testin on lähdettävä yhdyskäytävän takaa.

Pidä IPv6-tapaus erillään

Täällä kaikki on IPv4:tä. IPv6:n edelleenlähetyksellä, reitittimen ilmoituksilla ja accept_ra-käyttäytymisellä on omat ohjauksensa, ja ipv4-polun kopioiminen ipv6-asetukseksi tuottaa tiedoston, joka näyttää uskottavalta eikä tee mitään hyödyllistä. Kaksoispinon yhdyskäytävä tarvitsee molemmat joukot tietoisesti määritettyinä.

Vielä yksi tarkistus: kun arvot täsmäävät, varmista, että tunnelin reitti valitaan kohteelle ja että paluupolku on olemassa. Ilman reittiä olevalle liitännälle päälle kytketty edelleenlähetys on edelleen musta aukko, ja se vika näyttää asiakkaan puolelta samalta.