Hvorfor en VPN-klient på kontorets LAN mister hvert svar

En bærbar PC sitter på kontorets /24 over Ethernet og blir også med i en OpenVPN-server som bor i samme /24. En kollega pinger tunneladressen; forespørselen kommer tydelig fram, og ingenting går tilbake. Tunnelloggen er ren og nettlesing virker fortsatt, så tunnelen er den gale mistenkte. IPv4-kildevalidering på maskinen som mottar kaster pakken før noe leser den.

Kastingen skjer før noe leser pakken

Kildevalidering stiller ett spørsmål om hver innkommende pakke: hvis denne verten svarte den kilden, ville svaret da gå ut gjennom grensesnittet pakken nettopp kom inn på? Når svaret er nei, kaster kjernen pakken ved ankomst. Verken en socket eller en videresendingsvei ser den noen gang, og derfor registrerer en opptak på tunnelen fortsatt en forespørsel som programmet aldri mottar.

Klienten her har 10.66.0.9 på tunnelen sin, og OpenVPN-serveren svarer på 192.168.80.10 inne i kontorets prefiks. En kollega på 192.168.80.25 pinger tunneladressen, så forespørselen krysser LAN-et, serveren ruter den inn i tunnelen, og den ankommer på klientens tunnelgrensesnitt med en kildadresse fra kontoret. I den maskinens rutetabell tilhører kontorets prefiks Ethernet-enheten, ikke tunnelen. Valideringen sammenligner ankomstgrensesnittet med ruten, finner en mismatch og forkaster pakken, så kollegaen ser totalt tap mens begge ender rapporterer en sunn tunnel.

Speilretningen har samme form: når klienten starter mot kontoret, kan svar bli forkastet på kontorets side av nøyaktig samme grunn. En rettelse som bare er verifisert i én retning kommer ofte tilbake som en ny sak.

Bevis den gjeldende modusen før du rører en sysctl

Les de effektive verdiene i stedet for å stole på en distribusjonsstandard, fordi innstillingen per grensesnitt bare er halve beslutningen. Den gjeldende modusen er den høyeste av grensesnittverdien og verdien all, så en null på tunnelgrensesnittet betyr ingenting mens all er én. Den strenge modusens beslutning er en rutingsbeslutning, så kjør oppslaget kjernen kjører og sammenlign svaret med grensesnittet pakken faktisk kom inn på.

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

Gjenta deretter pinget mens du følger feiltelleren. Et stigende tall ved siden av en forespørsel opptaket allerede viser er signaturen på denne kastingen, ikke på en manglende rute. Slå på marsiansk logging mens du er der, så kjernen navngir kilden og grensesnittet den avviste. Sammen utelukker de chifferet, brannmuren og en manglende iroute som forklaringer.

Skriv ned utgangspunktet før du endrer noe: begge verdiene, enheten oppslaget valgte, og telleren du fulgte. Det er den registreringen som senere forteller deg om endringen gjorde det du tror.

Hva hver rp_filter-modus faktisk godtar

Kjernen viser tre verdier per grensesnitt, og de er ikke tre nyanser av én regel. Null slår av kontrollen. Én er streng og krever at kilden rutes tilbake ut gjennom ankomstgrensesnittet. To er løs og krever bare at det finnes en eller annen rute til kilden i tabellen, hvor den enn peker.

Raden som betyr noe her er den løse, og det den fortsatt avviser. En forfalsket kilde som kan rutes hvor som helst i tabellen din slipper gjennom, mens en kilde uten noen rute fortsatt avvises. På en bærbar PC er det en snever innrømmelse; på en ruter som videresender trafikk for andre er den bred. Modusen tilhører verten, så det samme tallet bærer ulik vekt de to stedene.

Hvilken rad denne topologien trenger følger av tabellen og ikke av vane. Pakken er legitim og kilden kan rutes, så den løse godtar den og den strenge ikke. Ingenting i saken krever null, og å velge null ville fjerne en kontroll som ikke koster noe her.

Velg den minste endringen som fjerner tvetydigheten

Løs modus er den minste endringen som passer, og det er en reell lemping av strengheten, ikke en ufarlig bryter. Et bedre alternativ finnes når topologien tillater det: fjern overlappingen, og tvetydigheten forsvinner.

Der kontorets prefiks bare trengs over Ethernet, fjern det fra rutene profilen drar, og adressen blir tilgjengelig via én vei. Når begge veiene virkelig må sameksistere, fest kilden og enheten med en policyregel i stedet for å løsne valideringen på hvert grensesnitt. Det beholder streng filtrering for alt annet på maskinen og dokumenterer unntaket der den neste ingeniøren vil lete etter det.

Uansett hvilken vei du velger, registrer den i en sysctl-drop-in og ikke i en levende kommando. Sett nøklene all og default sammen, så en gjenoppkobling ikke stille kan gjenopprette streng modus.

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

Hva løs modus gir avkall på, og hvor

Løs modus avviser fortsatt en kilde som ingen rute kunne nå, og den slutter å avvise en forfalsket kilde som tilfeldigvis kan rutes. På en bærbar PC er det en snever innrømmelse. På en enhet som videresender trafikk den ikke eier, er det samme valget mye bredere. Den samme innstillingen bærer derfor to svært ulike betydninger avhengig av hvor den kjører.

Å slå kontrollen helt av på en vert som videresender trafikk for andre mennesker er den ene reparasjonen man bør unngå. Null kaster valideringen som løs modus tar godt vare på. Hvis verten videresender for andre, argumenter i stedet for policyregel-alternativet fra forrige avsnitt.

Legg igjen et notat som navngir de to grensesnittene, det overlappende prefikset og den nøyaktige testen som nå lykkes. Det er nyttigere for den neste ingeniøren enn en linje om at filtreringen ble justert.