Varför en VPN-klient på kontorets LAN tappar varje svar

En bärbar dator sitter på kontorets /24 över Ethernet och ansluter också till en OpenVPN-server som bor i samma /24. En kollega pingar tunneladressen; begäran anländer tydligt, och ingenting går tillbaka. Tunnelloggen är ren och surfandet fungerar fortfarande, så tunneln är den felaktiga misstänkte. IPv4-källvalidering på maskinen som tar emot kastar paketet innan något läser det.

Kastet sker innan något läser paketet

Källvalidering ställer en fråga om varje inkommande paket: om den här värden svarade den källan, skulle svaret då gå ut genom det gränssnitt paketet just kom in på? När svaret är nej kastar kärnan paketet vid ankomst. Varken en socket eller en vidarebefordringsväg ser det någonsin, och därför registrerar en inspelning på tunneln fortfarande en begäran som programmet aldrig tar emot.

Klienten här har 10.66.0.9 på sin tunnel, och OpenVPN-servern svarar på 192.168.80.10 inne i kontorets prefix. En kollega på 192.168.80.25 pingar tunneladressen, så begäran korsar LAN:et, servern dirigerar den in i tunneln, och den anländer på klientens tunnelgränssnitt med en källadress från kontoret. I den maskinens routingtabell tillhör kontorets prefix Ethernet-enheten, inte tunneln. Valideringen jämför ankomstgränssnittet med rutten, hittar en avvikelse och förkastar paketet, så kollegan ser total förlust medan båda ändar rapporterar en frisk tunnel.

Spegelriktningen har samma form: när klienten börjar mot kontoret kan svar förkastas på kontorets sida av exakt samma skäl. En rättelse som bara verifierats i en riktning kommer oftast tillbaka som ett andra ärende.

Bevisa det gällande läget innan du rör en sysctl

Läs de effektiva värdena i stället för att lita på en distributionsstandard, eftersom inställningen per gränssnitt bara är halva beslutet. Det gällande läget är det högre av gränssnittsvärdet och värdet all, så en nolla på tunnelgränssnittet betyder ingenting så länge all är ett. Det strikta lägets beslut är ett routingbeslut, så kör den sökning som kärnan kör och jämför svaret med gränssnittet paketet faktiskt kom in 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

Upprepa sedan pinget medan du följer felräknaren. En stigande räknare bredvid en begäran som inspelningen redan visar är signaturen för detta kast, inte för en saknad rutt. Slå på marsiansk loggning medan du är där, så att kärnan namnger källan och gränssnittet den avvisade. Tillsammans utesluter de chiffer, brandvägg och en saknad iroute som förklaringar.

Skriv ned utgångsläget innan du ändrar något: båda värdena, enheten sökningen valde och räknaren du följde. Det är den anteckningen som senare säger om ändringen gjorde det du tror.

Vad varje rp_filter-läge faktiskt accepterar

Kärnan visar tre värden per gränssnitt, och de är inte tre nyanser av en regel. Noll stänger av kontrollen. Ett är strikt och kräver att källan routas tillbaka ut genom ankomstgränssnittet. Två är löst och kräver bara att det finns någon rutt till källan i tabellen, vart den än pekar.

Raden som betyder något här är den lösa, och det den fortfarande avvisar. En förfalskad källa som är routbar var som helst i din tabell passerar, medan en källa utan någon rutt fortfarande avvisas. På en bärbar dator är det en snäv eftergift; på en router som vidarebefordrar trafik för andra är den vid. Läget tillhör värden, så samma tal bär olika vikt på de två ställena.

Vilken rad den här topologin behöver följer av tabellen och inte av vana. Paketet är legitimt och källan är routbar, så den lösa accepterar det och den strikta inte. Ingenting i ärendet kräver noll, och att välja noll skulle ta bort en kontroll som inte kostar något här.

Välj den minsta ändring som tar bort tvetydigheten

Det lösa läget är den minsta ändring som passar, och det är en verklig sänkning av strängheten, inte en ofarlig brytare. Ett bättre alternativ finns när topologin tillåter det: ta bort överlappningen, och tvetydigheten försvinner.

Där kontorets prefix bara behövs över Ethernet, ta bort det från de rutter profilen drar och adressen blir nåbar via en enda väg. När båda vägarna verkligen måste samexistera, fäst källan och enheten med en policyregel i stället för att lossa valideringen på varje gränssnitt. Det behåller strikt filtrering för allt annat på maskinen och dokumenterar undantaget där nästa ingenjör kommer att leta efter det.

Vilken väg du än väljer, registrera den i en sysctl-drop-in och inte i ett levande kommando. Sätt nycklarna all och default tillsammans, så att en återanslutning inte tyst kan återställa det strikta läget.

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

Vad det lösa läget avstår från, och var

Det lösa läget avvisar fortfarande en källa som ingen rutt skulle kunna nå, och det slutar avvisa en förfalskad källa som råkar vara routbar. På en bärbar dator är det en snäv eftergift. På en enhet som vidarebefordrar trafik som den inte äger är samma val mycket vidare. Därför bär samma inställning två mycket olika betydelser beroende på var den körs.

Att stänga av kontrollen helt på en värd som vidarebefordrar trafik för andra människor är den enda reparation man bör undvika. Noll kastar bort den validering som det lösa läget noga behåller. Om värden vidarebefordrar för andra, argumentera i stället för policyregelalternativet från föregående avsnitt.

Lämna en anteckning som namnger de två gränssnitten, det överlappande prefixet och det exakta test som nu lyckas. Det är mer användbart för nästa ingenjör än en rad om att filtreringen justerades.