Hoekom ’n VPN-kliënt op die kantoor-LAN elke antwoord verloor

’n Skootrekenaar sit op die kantoor se /24 oor Ethernet en sluit ook by ’n OpenVPN-bediener aan wat in dieselfde /24 woon. ’n Kollega ping die tonneladres; die versoek kom duidelik aan, en niks gaan terug nie. Die tonnelloë is skoon en webblaai werk nog, so die tonnel is die verkeerde verdagte. IPv4-bronvalidering op die ontvangende masjien gooi die pakket weg voordat enigiets dit lees.

Die verwerping gebeur voordat enigiets die pakket lees

Bronvalidering vra een vraag oor elke inkomende pakket: as hierdie gasheer daardie bron geantwoord het, sou die antwoord die koppelvlak verlaat waarop die pakket pas aangekom het? Wanneer die antwoord nee is, gooi die kernen die pakket dadelik weg. Geen soket en geen aanstuurpad sien dit ooit nie, en daarom teken ’n opname op die tonnel steeds ’n versoek aan wat die toepassing nooit ontvang nie.

Die kliënt hier hou 10.66.0.9 op sy tonnel, en die OpenVPN-bediener antwoord by 192.168.80.10 binne die kantoorvoorvoegsel. ’n Kollega by 192.168.80.25 ping die tonneladres, so die versoek kruis die LAN, die bediener stuur dit in die tonnel in, en dit kom op die kliënt se tonnelkoppelvlak aan met ’n kantoorbronadres. In daardie masjien se roetertabel behoort die kantoorvoorvoegsel aan die Ethernet-toestel, nie aan die tonnel nie. Validering vergelyk die aankomskoppelvlak met die roete, vind ’n wanverhouding en verwerp die pakket, so die kollega sien totale verlies terwyl albei kante ’n gesonde tonnel rapporteer.

Die spieëlrigting het dieselfde vorm: wanneer die kliënt na die kantoor begin, kan antwoorde aan die kantoor se kant om dieselfde rede verwerp word. ’n Herstelling wat net in een rigting geverifieer is, kom gewoonlik terug as ’n tweede kaartjie.

Bewys die geldende modus voordat jy aan ’n sysctl raak

Lees die effektiewe waardes eerder as om ’n verspreidingsverstek te vertrou, want die per-koppelvlak-instelling is net die helfte van die beslissing. Die geldende modus is die hoër van die koppelvlakwaarde en die all-waarde, so ’n nul op die tonnelkoppelvlak beteken niks terwyl all een is. Strenge modus se beslissing is ’n roetebeslissing, so voer die opsoek uit wat die kernen uitvoer en vergelyk die antwoord met die koppelvlak waarop die pakket werklik aangekom het.

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

Herhaal dan die ping terwyl jy die foutteller dophou. ’n Stygende telling langs ’n versoek wat die opname al wys, is die kenmerk van hierdie verwerping, nie van ’n ontbrekende roete nie. Skakel martiaanse logboektering aan terwyl jy daar is, sodat die kernen die bron en die koppelvlak noem wat dit verwerp het. Saam sluit hulle die syfer, die firewall en ’n ontbrekende iroute as verklarings uit.

Skryf die basislyn neer voordat jy enigiets verander: albei waardes, die toestel wat die opsoek gekies het, en die teller wat jy dopgehou het. Daardie rekord is wat jou later vertel of die verandering gedoen het wat jy dink.

Wat elke rp_filter-modus werklik aanvaar

Die kernen bied drie waardes per koppelvlak, en hulle is nie drie skakerings van een reël nie. Nul skakel die kontrole af. Een is streng en vereis dat die bron terug uit die aankomskoppelvlak gestuur word. Twee is los en vereis net dat een of ander roete na die bron in die tabel bestaan, waar dit ook wys.

Die ry wat hier saak maak, is die los een, en wat dit bly verwerp. ’n Vervalste bron wat enige plek in jou tabel bereikbaar is, gaan deur, terwyl ’n bron met glad geen roete nie steeds geweier word. Op ’n skootrekenaar is dit ’n geringe toegewing; op ’n roeteerder wat verkeer vir ander mense aanstuur, is dit ’n groot een. Die modus behoort aan die gasheer, so dieselfde nommer dra verskillende gewig op die twee plekke.

Watter ry hierdie topologie nodig het, volg uit die tabel eerder as uit gewoonte. Die pakket is wettig en sy bron is bereikbaar, so los aanvaar dit en streng nie. Niks in die geval vra vir nul nie, en nul kies sou ’n kontrole verwyder wat hier niks kos nie.

Kies die kleinste verandering wat die dubbelsinnigheid verwyder

Los modus is die kleinste verandering wat pas, en dit is ’n werklike verlaging in strengheid, nie ’n skadelose skakelaar nie. ’n Beter opsie bestaan wanneer die topologie dit toelaat: verwyder die oorvleueling, en die dubbelsinnigheid verdwyn.

Waar die kantoorvoorvoegsel net ooit oor Ethernet nodig is, laat val dit uit die roetes wat die profiel trek, en die adres word met een pad bereikbaar. Wanneer albei paaie werklik moet saambestaan, pen die bron en die toestel met ’n beleidsreël vas in plaas daarvan om validering op elke koppelvlak losser te maak. Dit hou streng filtering vir alles anders op die masjien en dokumenteer die uitsondering waar die volgende ingenieur daarvoor sal soek.

Watter roete jy ook kies, teken dit in ’n sysctl-drop-in aan eerder as in ’n lewende opdrag. Stel die all en default sleutels saam, sodat ’n herverbinding nie stilweg streng modus kan herstel nie.

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

Wat los modus prysgee, en waar

Los modus verwerp steeds ’n bron wat geen roete kon bereik nie, en dit hou op om ’n vervalste bron te verwerp wat toevallig bereikbaar is. Op ’n skootrekenaar is dit ’n geringe toegewing. Op ’n toestel wat verkeer aanstuur wat hy nie besit nie, is dieselfde keuse ’n veel wyer een. Dieselfde instelling dra dus twee baie verskillende betekenisse, afhangend van waar dit loop.

Om die kontrole heeltemal af te skakel op ’n gasheer wat verkeer vir ander mense aanstuur, is die een herstelling om te vermy. Nul gooi die validering weg wat los modus juis sorgvuldig hou. As die gasheer vir ander mense aanstuur, argumenteer eerder vir die beleidsreël-opsie uit die vorige afdeling.

Los ’n nota wat die twee koppelvlakke, die oorvleuelende voorvoegsel en die presiese toets noem wat nou slaag. Dit is nuttiger vir die volgende ingenieur as ’n reël wat sê filtering is aangepas.