Miksi VPN-asiakas toimiston lähiverkossa hukkaa jokaisen vastauksen

Kannettava istuu toimiston /24-verkossa Ethernetin yli ja liittyy samalla OpenVPN-palvelimeen, joka asuu samassa /24-verkossa. Kollega pingaa tunnelin osoitetta; pyyntö saapuu selvästi, eikä mitään tule takaisin. Tunnelin loki on puhdas ja selailu toimii yhä, joten tunneli on väärä epäilty. IPv4-lähteen validointi vastaanottavassa koneessa heittää paketin pois ennen kuin mikään lukee sitä.

Pudotus tapahtuu ennen kuin mikään lukee paketin

Lähteen validointi kysyy yhden kysymyksen jokaisesta saapuvasta paketista: jos tämä isäntä vastaisi kyseiselle lähteelle, lähtisikö vastaus ulos rajapinnasta, jolta paketti juuri saapui? Kun vastaus on ei, ydin heittää paketin pois saapuessaan. Eikä mikään pistoke tai välityspolku näe sitä koskaan, ja siksi tunnelin kaappaus tallentaa yhä pyynnön, jota sovellus ei koskaan saa.

Asiakas pitää täällä tunnelillaan osoitetta 10.66.0.9, ja OpenVPN-palvelin vastaa osoitteesta 192.168.80.10 toimiston etuliitteen sisällä. Kollega osoitteessa 192.168.80.25 pingaa tunnelin osoitetta, joten pyyntö ylittää lähiverkon, palvelin reitittää sen tunneliin ja se saapuu asiakkaan tunnelirajapintaan toimiston lähdeosoitetta kantaen. Kyseisen koneen reititystaulussa toimiston etuliite kuuluu Ethernet-laitteelle, ei tunnelille. Validointi vertaa saapumisrajapintaa reittiin, löytää ristiriidan ja hylkää paketin, joten kollega näkee täyden häviön, kun molemmat päät ilmoittavat terveestä tunnelista.

Peilisuunnalla on sama muoto: kun asiakas aloittaa toimistoa kohti, vastaukset voidaan hylätä toimiston puolella samasta syystä. Vain yhteen suuntaan varmennettu korjaus palaa yleensä toisena tiketin.

Todista voimassa oleva tila ennen kuin kosket mihinkään sysctl-asetukseen

Lue tehokkaat arvot sen sijaan, että luottaisit jakelun oletukseen, sillä rajapintakohtainen asetus on vain puolet päätöksestä. Voimassa oleva tila on suurempi rajapinnan arvosta ja all-arvosta, joten nolla tunnelirajapinnassa ei tarkoita mitään niin kauan kuin all on yksi. Tiukan tilan päätös on reitityspäätös, joten aja haku, jonka ydin ajaa, ja vertaa sen vastausta rajapintaan, jolta paketti todella saapui.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Toista sitten pingiä seuraten virhelaskuria. Pyynnön vieressä nouseva luku, jonka kaappaus jo näyttää, on tämän pudotuksen allekirjoitus, ei puuttuvan reitin. Kytke marsilaisten pakettien kirjaus päälle ollessasi siellä, jotta ydin nimeää lähteen ja rajapinnan, jonka se hylkäsi. Yhdessä ne sulkevat pois salauksen, palomuurin ja puuttuvan iroute-määrityksen selityksinä.

Kirjoita lähtötaso ylös ennen kuin muutat mitään: molemmat arvot, laite jonka haku valitsi, ja laskuri jota seurasit. Juuri se merkintä kertoo sinulle myöhemmin, tekikö muutos sen mitä luulet.

Mitä kukin rp_filter-tila todella hyväksyy

Ydin näyttää kolme arvoa rajapintaa kohden, eivätkä ne ole yhden säännön kolme sävyä. Nolla kytkee tarkistuksen pois. Yksi on tiukka ja vaatii, että lähde reititetään takaisin saapumisrajapinnan kautta. Kaksi on löysä ja vaatii vain, että taulussa on jokin reitti lähteeseen, mihin tahansa se osoittaakin.

Rivi, jolla on tässä merkitystä, on löysä rivi, ja se, mitä se yhä hylkää. Taulussasi missä tahansa reititettävä väärennetty lähde menee läpi, kun taas lähde, jolla ei ole lainkaan reittiä, hylätään yhä. Kannettavassa se on kapea myönnytys; reitittimessä, joka välittää muiden liikennettä, se on laaja. Tila kuuluu isännälle, joten sama luku kantaa eri painon kahdessa paikassa.

Minkä rivin tämä topologia tarvitsee, seuraa taulusta eikä tavasta. Paketti on laillinen ja sen lähde on reititettävä, joten löysä hyväksyy sen eikä tiukka. Mikään tapauksessa ei vaadi nollaa, ja nollan valinta poistaisi tarkistuksen, joka ei maksa tässä mitään.

Valitse pienin muutos, joka poistaa epäselvyyden

Löysä tila on pienin sopiva muutos, ja se on todellinen lievennys tiukkuudessa, ei harmiton kytkin. Parempi vaihtoehto on olemassa aina, kun topologia sallii: poista päällekkäisyys, ja epäselvyys katoaa.

Missä toimiston etuliitettä tarvitaan vain Ethernetin yli, poista se reiteistä, jotka profiili vetää, ja osoitteesta tulee yhden polun kautta saavutettava. Kun molempien polkujen on todella oltava olemassa, kiinnitä lähde ja laite käytäntösäännöllä sen sijaan, että löysäisit validointia jokaisella rajapinnalla. Se pitää tiukan suodatuksen kaikelle muulle koneessa ja dokumentoi poikkeuksen sinne, mistä seuraava insinööri sitä etsii.

Minkä polun valitsetkin, kirjaa se sysctl drop-in-tiedostoon, älä elävään komentoon. Aseta avaimet all ja default yhdessä, jotta uudelleenyhdistäminen ei voi hiljaa palauttaa tiukkaa tilaa.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Mitä löysä tila antaa periksi, ja missä

Löysä tila hylkää yhä lähteen, johon mikään reitti ei pääsisi, ja lakkaa hylkäämästä väärennettyä lähdettä, joka sattuu olemaan reititettävä. Kannettavassa se on kapea myönnytys. Laitteessa, joka välittää liikennettä, jota se ei omista, sama valinta on paljon laajempi. Sama asetus kantaa siksi kahta hyvin erilaista merkitystä sen mukaan, missä se toimii.

Tarkistuksen kytkeminen kokonaan pois isännässä, joka välittää liikennettä muiden puolesta, on ainoa korjaus, jota kannattaa välttää. Nolla heittää pois sen validoinnin, jonka löysä tila huolellisesti säilyttää. Jos isäntä välittää muiden puolesta, perustele sen sijaan edellisen osion käytäntösääntövaihtoehtoa.

Jätä muistiinpano, joka nimeää kaksi rajapintaa, päällekkäisen etuliitteen ja täsmällisen kokeen, joka nyt onnistuu. Se on seuraavalle insinöörille hyödyllisempi kuin rivi, joka sanoo suodatusta säädetyn.