Kvifor ein VPN-klient på kontorets LAN mistar kvart svar

Ein berbar PC sit på kontorets /24 over Ethernet og blir også med i ein OpenVPN-tenar som bur i same /24. Ein kollega pingar tunneladressa; førespurnaden kjem tydeleg fram, og ingenting går tilbake. Tunnelloggen er rein og nettlesinga verkar enno, så tunnelen er den gale mistenkte. IPv4-kjeldevalidering på maskinen som tek imot kastar pakken før noko les han.

Kastinga skjer før noko les pakken

Kjeldevalidering stiller eitt spørsmål om kvar innkomande pakke: viss denne verten svara den kjelda, ville svaret då gå ut gjennom grensesnittet pakken nettopp kom inn på? Når svaret er nei, kastar kjernen pakken ved ankomst. Korkje ein socket eller ein vidaresendingsveg ser han nokon gong, og difor registrerer eit opptak på tunnelen framleis ein førespurnad som programmet aldri mottek.

Klienten her har 10.66.0.9 på tunnelen sin, og OpenVPN-tenaren svarar på 192.168.80.10 inne i kontorets prefiks. Ein kollega på 192.168.80.25 pingar tunneladressa, så førespurnaden kryssar LAN-et, tenaren ruter han inn i tunnelen, og han kjem inn på tunnelgrensesnittet til klienten med ei kjeldeadresse frå kontoret. I rutetabellen til den maskinen høyrer kontorets prefiks til Ethernet-eininga, ikkje til tunnelen. Valideringa samanliknar ankomstgrensesnittet med ruta, finn eit avvik og forkastar pakken, så kollegaen ser totalt tap medan begge endar rapporterer ein sunn tunnel.

Spegelretninga har same form: når klienten startar mot kontoret, kan svar bli forkasta på kontorets side av nøyaktig same grunn. Ei retting som berre er stadfesta i éi retning kjem ofte tilbake som ei ny sak.

Prov den gjeldande modusen før du rører ein sysctl

Les dei effektive verdiane i staden for å stole på ein distribusjonsstandard, fordi innstillinga per grensesnitt berre er halve avgjerda. Den gjeldande modusen er den høgaste av grensesnittverdien og verdien all, så ein null på tunnelgrensesnittet tyder ingenting medan all er éin. Avgjerda til den strenge modusen er ei rutingavgjerd, så køyr oppslaget kjernen køyrer og samanlikn 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 medan du følgjer feilteljaren. Eit stigande tal ved sida av ein førespurnad opptaket alt viser er signaturen på denne kastinga, ikkje på ei manglande rute. Slå på marsiansk logging medan du er der, så kjernen nemner kjelda og grensesnittet han avviste. Saman utelukkar dei chifferet, brannmuren og ein manglande iroute som forklaringar.

Skriv ned utgangspunktet før du endrar noko: begge verdiane, eininga oppslaget valde, og teljaren du følgde. Det er den registreringa som seinare fortel deg om endringa gjorde det du trur.

Kva kvar rp_filter-modus faktisk godtek

Kjernen viser tre verdiar per grensesnitt, og dei er ikkje tre nyansar av éi regel. Null slår av kontrollen. Éin er streng og krev at kjelda blir ruta tilbake ut gjennom ankomstgrensesnittet. To er laus og krev berre at det finst ei eller anna rute til kjelda i tabellen, kvar ho enn peikar.

Rada som tel her er den lause, og det ho framleis avviser. Ei forfalska kjelde som kan rutast kvar som helst i tabellen din slepp gjennom, medan ei kjelde utan noka rute framleis blir avvist. På ein berbar PC er det ei trong innrømming; på ein ruter som vidaresender trafikk for andre er ho brei. Modusen høyrer til verten, så det same talet ber ulik vekt dei to stadene.

Kva rad denne topologien treng følgjer av tabellen og ikkje av vane. Pakken er legitim og kjelda kan rutast, så den lause godtek han og den strenge ikkje. Ingenting i saka krev null, og å velje null ville fjerne ein kontroll som ikkje kostar noko her.

Vel den minste endringa som fjernar tvitydigheita

Laus modus er den minste endringa som passar, og det er ei reell lemming av strengheita, ikkje ein ufarleg brytar. Eit betre alternativ finst når topologien tillèt det: fjern overlappinga, og tvitydigheita forsvinn.

Der kontorets prefiks berre trengst over Ethernet, fjern han frå rutene profilen dreg, og adressa blir tilgjengeleg via éin veg. Når begge vegane verkeleg må sameksistere, fest kjelda og eininga med ein policyregel i staden for å løysne valideringa på kvart grensesnitt. Det held på streng filtrering for alt anna på maskinen og dokumenterer unntaket der den neste ingeniøren vil leite etter det.

Kva veg du enn vel, registrer han i ein sysctl-drop-in og ikkje i ein levande kommando. Set nøklane all og default saman, så ei ny tilkopling ikkje 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

Kva laus modus gir avkall på, og kvar

Laus modus avviser framleis ei kjelde som inga rute kunne nå, og han sluttar å avvise ei forfalska kjelde som tilfeldigvis kan rutast. På ein berbar PC er det ei trong innrømming. På ei eining som vidaresender trafikk ho ikkje eig, er det same valet mykje breiare. Den same innstillinga ber difor to svært ulike tydingar avhengig av kvar ho køyrer.

Å slå kontrollen heilt av på ein vert som vidaresender trafikk for andre menneske er den einaste rettinga ein bør unngå. Null kastar valideringa som laus modus tek godt vare på. Viss verten vidaresender for andre, argumenter i staden for policyregel-alternativet frå førre avsnitt.

Legg att eit notat som nemner dei to grensesnitta, det overlappande prefikset og den nøyaktige testen som no lukkast. Det er nyttigare for den neste ingeniøren enn ei linje om at filtreringa vart justert.