Proč klient VPN na kancelářské LAN zahazuje každou odpověď

Notebook sedí v kancelářské síti /24 přes Ethernet a zároveň se připojuje k serveru OpenVPN, který žije ve stejné /24. Kolega pingá adresu tunelu; požadavek zjevně dorazí a nic se nevrací. Protokol tunelu je čistý a prohlížení funguje, takže tunel je špatný podezřelý. Ověření zdroje IPv4 na přijímajícím stroji paket zahodí dřív, než ho cokoli přečte.

Zahození nastane dřív, než cokoli paket přečte

Ověření zdroje klade u každého příchozího paketu jednu otázku: kdyby tento hostitel odpověděl onomu zdroji, vyšla by odpověď rozhraním, kterým paket právě dorazil? Když je odpověď ne, jádro paket při příchodu zahodí. Nevidí ho žádný socket ani cesta předávání, a proto zachycení na tunelu stále zaznamená požadavek, který aplikace nikdy nedostane.

Klient zde drží 10.66.0.9 na svém tunelu a server OpenVPN odpovídá z 192.168.80.10 uvnitř kancelářského prefixu. Kolega na 192.168.80.25 pingá adresu tunelu, takže požadavek projde přes LAN, server ho nasměruje do tunelu a dorazí na tunelové rozhraní klienta s kancelářskou zdrojovou adresou. Ve směrovací tabulce toho stroje patří kancelářský prefix zařízení Ethernet, ne tunelu. Ověření porovná rozhraní příchodu se směrováním, najde nesoulad a paket zahodí, takže kolega vidí úplnou ztrátu, zatímco oba konce hlásí zdravý tunel.

Zrcadlový směr má stejný tvar: když klient iniciuje směrem do kanceláře, odpovědi mohou být na straně kanceláře zahozeny ze stejného důvodu. Oprava ověřená jen v jednom směru se obvykle vrací jako druhý tiket.

Dokažte platný režim, než se dotknete jakéhokoli sysctl

Čtěte účinné hodnoty místo spoléhání na výchozí hodnotu distribuce, protože nastavení pro rozhraní je jen polovina rozhodnutí. Platný režim je vyšší z hodnoty rozhraní a hodnoty all, takže nula na tunelovém rozhraní nic neznamená, dokud je all jedna. Rozhodnutí přísného režimu je rozhodnutím směrování, takže spusťte vyhledání, které spouští jádro, a porovnejte jeho odpověď s rozhraním, kterým paket skutečně dorazil.

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

Potom ping zopakujte a sledujte počítadlo chyb. Rostoucí počet vedle požadavku, který zachycení už ukazuje, je podpisem tohoto zahození, ne chybějící trasy. Zapněte marťanské logování, dokud jste tam, aby jádro pojmenovalo zdroj a rozhraní, které odmítlo. Společně vylučují šifru, firewall a chybějící iroute jako vysvětlení.

Zapište výchozí stav, než cokoli změníte: obě hodnoty, zařízení, které vyhledání zvolilo, a počítadlo, které jste sledovali. Právě tento záznam vám později řekne, zda změna udělala to, co si myslíte.

Co který režim rp_filter skutečně přijímá

Jádro vystavuje tři hodnoty pro každé rozhraní a nejsou to tři odstíny jednoho pravidla. Nula kontrolu vypíná. Jedna je přísná a vyžaduje, aby byl zdroj směrován zpět přes rozhraní příchodu. Dvojka je volná a vyžaduje jen, aby v tabulce existovala nějaká trasa ke zdroji, ať už míří kamkoli.

Řádek, na kterém zde záleží, je ten volný, a to, co nadále odmítá. Podvržený zdroj, který je směrovatelný kdekoli ve vaší tabulce, projde, zatímco zdroj bez jakékoli trasy je stále odmítnut. Na notebooku je to úzká ústupek; na routeru, který předává provoz jiným lidem, je široká. Režim patří hostiteli, takže stejné číslo nese na obou místech jinou váhu.

Který řádek tato topologie potřebuje, vyplývá z tabulky, ne ze zvyku. Paket je legitimní a jeho zdroj je směrovatelný, takže volný ho přijme a přísný ne. Nic v tomto případě nevolá po nule a volba nuly by odstranila kontrolu, která zde nic nestojí.

Vyberte nejmenší změnu, která odstraní nejednoznačnost

Volný režim je nejmenší změna, která se hodí, a je to skutečné zmírnění přísnosti, ne neškodný přepínač. Lepší možnost existuje vždy, když to topologie dovolí: odstraňte překryv a nejednoznačnost zmizí.

Kde je kancelářský prefix potřeba jen přes Ethernet, vyřaďte ho z tras, které profil tahá, a adresa bude dostupná jednou cestou. Když obě cesty skutečně musí koexistovat, připněte zdroj a zařízení pravidlem zásad, místo abyste uvolňovali ověření na každém rozhraní. Tím zůstane přísné filtrování pro vše ostatní na stroji a výjimka je zdokumentována tam, kde ji příští inženýr bude hledat.

Ať zvolíte kteroukoli cestu, zapište ji do drop-inu sysctl, ne do živého příkazu. Nastavte klíče all a default společně, aby opětovné připojení nemohlo tiše obnovit přísný režim.

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

Co volný režim ztrácí a kde

Volný režim stále odmítá zdroj, na který by nedosáhla žádná trasa, a přestává odmítat podvržený zdroj, který je náhodou směrovatelný. Na notebooku je to úzká ústupek. Na zařízení, které předává cizí provoz, je stejná volba mnohem širší. Stejné nastavení proto nese dva velmi různé významy podle toho, kde běží.

Úplně vypnout kontrolu na hostiteli, který předává provoz jiným lidem, je jediná oprava, které je třeba se vyhnout. Nula zahazuje ověření, které volný režim pečlivě zachovává. Pokud hostitel předává za jiné, argumentujte místo toho pro možnost s pravidlem zásad z předchozí části.

Zanechte poznámku, která pojmenuje obě rozhraní, překrývající se prefix a přesnou zkoušku, která nyní prochází. To je pro příštího inženýra užitečnější než řádek, že filtrování bylo upraveno.