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

En bærbar computer sidder på kontorets /24 over Ethernet og tilslutter sig også en OpenVPN-server, der bor i samme /24. En kollega pinger tunneladressen; anmodningen ankommer tydeligt, og intet kommer tilbage. Tunnel-loggen er ren, og browsing virker stadig, så tunnelen er den forkerte mistænkte. IPv4-kildevalidering på maskinen, der modtager, kaster pakken væk, før noget læser den.

Kastet sker, før noget læser pakken

Kildevalidering stiller ét spørgsmål til hver indgående pakke: hvis denne vært svarede den kilde, ville svaret så forlade systemet gennem den grænseflade, som pakken netop ankom på? Når svaret er nej, kaster kernen pakken væk ved ankomsten. Hverken en socket eller en videresendelsesvej ser den nogensinde, og derfor registrerer en optagelse på tunnelen stadig en anmodning, som programmet aldrig modtager.

Klienten her har 10.66.0.9 på sin tunnel, og OpenVPN-serveren svarer på 192.168.80.10 inde i kontorets præfiks. En kollega på 192.168.80.25 pinger tunneladressen, så anmodningen krydser LAN'et, serveren ruter den ind i tunnelen, og den ankommer på klientens tunnelgrænseflade med en kildeadresse fra kontoret. I den maskines routingtabel hører kontorets præfiks til Ethernet-enheden, ikke til tunnelen. Valideringen sammenligner ankomstgrænsefladen med ruten, finder en uoverensstemmelse og forkaster pakken, så kollegaen ser totalt tab, mens begge ender rapporterer en sund tunnel.

Den spejlede retning har samme form: når klienten starter mod kontoret, kan svar blive forkastet på kontorets side af præcis samme grund. En rettelse, der kun er verificeret i én retning, vender ofte tilbage som en ny sag.

Bevis den gældende tilstand, før du rører en sysctl

Læs de effektive værdier i stedet for at stole på en distributionstandard, for indstillingen for hver grænseflade er kun halvdelen af beslutningen. Den gældende tilstand er den højeste af grænsefladeværdien og værdien all, så et nul på tunnelgrænsefladen betyder intet, mens all er et. Den strenge tilstands beslutning er en routingbeslutning, så kør det opslag, kernen kører, og sammenlign svaret med den grænseflade, pakken faktisk ankom 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

Gentag derefter pinget, mens du holder øje med fejltælleren. Et stigende antal ved siden af en anmodning, som optagelsen allerede viser, er signaturen på dette kast, ikke på en manglende rute. Slå marsiansk logning til, mens du er der, så kernen navngiver kilden og den grænseflade, den afviste. Sammen udelukker de chifferen, firewallsystemet og en manglende iroute som forklaringer.

Skriv basislinjen ned, før du ændrer noget: begge værdier, den enhed opslaget valgte, og den tæller du overvågede. Den registrering er det, der senere fortæller dig, om ændringen gjorde det, du tror.

Hvad hver rp_filter-tilstand faktisk accepterer

Kernen viser tre værdier for hver grænseflade, og de er ikke tre nuancer af én regel. Nul slår kontrollen fra. Et er strengt og kræver, at kilden routes tilbage ud gennem ankomstgrænsefladen. To er løst og kræver kun, at der findes en eller anden rute til kilden i tabellen, hvor den end peger hen.

Den række, der betyder noget her, er den løse, og det, den fortsat afviser. En forfalsket kilde, der kan routes hvor som helst i din tabel, slipper igennem, mens en kilde uden nogen rute stadig afvises. På en bærbar computer er det en snæver indrømmelse; på en router, der videresender trafik for andre, er den bred. Tilstanden hører til værten, så det samme tal bærer forskellig vægt de to steder.

Hvilken række denne topologi har brug for, følger af tabellen og ikke af vane. Pakken er legitim, og dens kilde kan routes, så den løse accepterer den og den strenge ikke. Intet i sagen kræver nul, og at vælge nul ville fjerne en kontrol, der intet koster her.

Vælg den mindste ændring, der fjerner tvetydigheden

Løs tilstand er den mindste ændring, der passer, og det er en reel lempelse af strengheden, ikke en uskyldig kontakt. En bedre mulighed findes, når topologien tillader det: fjern overlapningen, og tvetydigheden forsvinder.

Hvor kontorets præfiks kun er nødvendigt over Ethernet, skal du fjerne det fra de ruter, profilen trækker, og adressen bliver tilgængelig ad én vej. Når begge veje virkelig skal sameksistere, skal du fastgøre kilden og enheden med en politikregel i stedet for at løsne valideringen på hver grænseflade. Det bevarer streng filtrering for alt andet på maskinen og dokumenterer undtagelsen, hvor den næste ingeniør vil lede efter den.

Hvilken vej du end vælger, skal du registrere den i et sysctl drop-in i stedet for i en levende kommando. Sæt nøglerne all og default sammen, så en genopkobling ikke stille kan genoprette streng tilstand.

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

Hvad løs tilstand giver afkald på, og hvor

Løs tilstand afviser stadig en kilde, som ingen rute kunne nå, og den holder op med at afvise en forfalsket kilde, der tilfældigvis kan routes. På en bærbar computer er det en snæver indrømmelse. På en enhed, der videresender trafik, den ikke ejer, er det samme valg en meget bredere. Den samme indstilling bærer derfor to meget forskellige betydninger afhængigt af, hvor den kører.

At slå kontrollen helt fra på en vært, der videresender trafik for andre, er den ene reparation, man skal undgå. Nul kaster den validering væk, som løs tilstand omhyggeligt bevarer. Hvis værten videresender for andre, skal du i stedet argumentere for politikregel-muligheden fra det foregående afsnit.

Efterlad en note, der navngiver de to grænseflader, det overlappende præfiks og den præcise test, der nu lykkes. Det er mere nyttigt for den næste ingeniør end en linje om, at filtreringen blev justeret.