Katoavatko Linux VPN:n vastaukset? Tarkista rp_filter ja reitti

Pyynnöt lähtevät koneesta, VPN-vertaiskumppani vastaa, eikä vastaus koskaan saavu sokettiin. Tunneli on pystyssä, vertaiskumppanin lokit näyttävät, että paketti lähetetään, eikä mikään sovelluksessa selitä hiljaisuutta. Linuxissa yksi tavallisimmista epäillyistä on paluupolun suodatus: saapuva IPv4-paketti voidaan hylätä, kun lähteen validointi ei vastaa reittiä, jota ydin odottaa kyseiselle lähteelle. Järjestyksessä läpikäyminen kertoo, onko se syy vai sattumaa. Se myös estää sinua poistamasta turvakontrollia käytöstä puuttuvan reitin korjaamiseksi.

Mitä lähteen validointi päättää

Ydin tarkistaa, onko paketin lähdeosoite uskottava sille liitännälle, jolta se saapui, kysymällä reititystaulusta reittiä takaisin kyseiseen lähteeseen. Jos paluureitti osoittaa muualle, paketti voidaan hylätä ennen kuin mikään palomuurisääntö tai sovelluksen soketti näkee sen. Tämä tarkistus on olemassa, jotta tietyistä spoofauskuvioista tulee vaikeampia, ja siksi epäsymmetriset ja käytäntöpohjaisesti reititetyt ratkaisut törmäävät siihen, kun taas jokainen tavallinen asiakas samassa verkossa toimii hyvin. Tavallisilla asiakkailla on symmetrinen reititys, ja juuri sitä tarkistus olettaa.

Tärkeä sana on uskottava. Paketti voi olla täysin laillinen ja silti epäonnistua tarkistuksessa, koska laillisuutta ei testata.

Lue todellinen tila, älä yhtä kenttää

Tiloja on kolme: pois päältä, tiukka ja löysä. Tiukka asettaa erilaisen reittiodotuksen kuin löysä, ja yleinen asetus vaikuttaa yhdessä liitäntäkohtaisten kanssa, joten yhden tiedoston lukeminen voi kuvata väärin sen, mikä tosiasiassa on voimassa. Lue molemmat ja lue ne liitännältä, joka vastaanottaa vastauksen, ei oletusreitin liitännältä.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Kolmannen rivin reittihaku on se osa, jonka ihmiset ohittavat. Se kertoo, mitä ydin uskoo lähteestä, ja juuri se on tarkistuksen syöte.

Löydä ristiriita ennen kuin muutat tarkistusta

Selvitä, miksi vastaus saapuu juuri sille liitännälle ja pitäisikö sen paluureitin olla erilainen. Käytäntösääntö, joka lähettää pyynnöt yhtä polkua pitkin ja palauttaa vastaukset toista, on laillinen ratkaisu, ja juuri sen tiukka validointi hylkää. Käytäntöreitityksessä käytetyt merkit voivat vaikuttaa tässäkin, koska ne muuttavat sitä, mitä paluuhaku palauttaa.

Jos paluureitti yksinkertaisesti puuttuu, sen lisääminen korjaa syyn sen sijaan, että tarkistus poistetaan käytöstä. Puuttuva reitti, palomuurin hylkäys ja väärä liikenteen valitsin tuottavat kaikki saman näkyvän oireen, ja vain yksi niistä liittyy lähteen validointiin.

Älä poista lähdetarkistuksia käytöstä yleisesti ensimmäisenä reaktiona. Se vaihtaa täsmällisen diagnoosin laajaan käytöksen muutokseen, joka sinun on muistettava myöhemmin.

Valikoiva säätö, jonka voit perustella

Jos kapea säätö on todella tarpeen, rajaa se liitäntään, joka sitä tarvitsee, kirjoita perustelu ja laita se sen liitännän omistamaan kokoonpanoon, jotta se kestää uudelleenkäynnistyksen. Testaa sitten uudelleen täsmälleen se virtaus, joka epäonnistui, samasta lähteestä samaan kohteeseen, eikä pingiä johonkin kätevään.

Sisällytä tapaus, joka pitäisi edelleen hylätä. Jos tapaus nyt onnistuu, säätö heikensi enemmän kuin sen yhden polun, jonka halusit korjata.

Pidä IPv4 ja IPv6 erillään

Tutulta näyttävä sysctl ei ole käytäntö kaikille osoiteperheille. IPv6:lla on oma käytöksensä ja omat asetuksensa, ja kone voi olla tiukka yhdessä perheessä ja salliva toisessa, kenenkään huomaamatta ennen kuin tietty kohde epäonnistuu. Tarkista molemmat, jos työkuorma käyttää molempia.

Kirjaa tila, liitäntä, reittihaun tulos ja muutoksen syy yhteen paikkaan. Seuraava henkilö löytää asetuksen eikä selitystä, ja joko poistaa sen tai kopioi sen paikkaan, johon se ei kuulu.