Prečo klient VPN v kancelárskej LAN stráca každú odpoveď
Notebook v kancelárskej LAN a v tuneli v tej istej podsieti odpovedá z nesprávneho rozhrania. Voľné filtrovanie spätnej cesty vysvetľuje to ticho.
Notebook sedí v /24 kancelárie cez Ethernet a zároveň sa pripája k serveru OpenVPN, ktorý žije v tej istej /24. Kolega pinguje adresu tunela; požiadavka zjavne prichádza a nič sa nevracia. Protokol tunela je čistý a prehliadanie stále funguje, takže tunel je nesprávny podozrivý. Overenie zdroja IPv4 na prijímajúcom počítači zahodí paket skôr, než ho čokoľvek prečíta.
Zahodenie nastane skôr, než čokoľvek paket prečíta
Overenie zdroja kladie jednu otázku o každom prichádzajúcom pakete: keby tento hostiteľ odpovedal tomu zdroju, vyšla by odpoveď rozhraním, ktorým paket práve prišiel? Keď je odpoveď nie, jadro paket pri príchode zahodí. Nevidí ho žiadny socket ani cesta preposielania, a preto zachytenie na tuneli stále zaznamená požiadavku, ktorú aplikácia nikdy nedostane.
Klient tu drží 10.66.0.9 na svojom tuneli a server OpenVPN odpovedá z 192.168.80.10 vnútri kancelárskeho prefixu. Kolega na 192.168.80.25 pinguje adresu tunela, takže požiadavka prejde cez LAN, server ju nasmeruje do tunela a dorazí na tunelové rozhranie klienta s kancelárskou zdrojovou adresou. V smerovacej tabuľke toho počítača patrí kancelársky prefix zariadeniu Ethernet, nie tunelu. Overenie porovná rozhranie príchodu so smerovaním, nájde nesúlad a paket zahodí, takže kolega vidí úplnú stratu, kým oba konce hlásia zdravý tunel.
Zrkadlový smer má ten istý tvar: keď klient iniciuje smerom do kancelárie, odpovede môžu byť na strane kancelárie zahodené z rovnakého dôvodu. Oprava overená len v jednom smere sa zvyčajne vráti ako druhý tiket.
Dokážte platný režim, skôr než sa dotknete akéhokoľvek sysctl
Čítajte účinné hodnoty namiesto spoliehania sa na predvolenú hodnotu distribúcie, pretože nastavenie pre rozhranie je len polovica rozhodnutia. Platný režim je vyššia z hodnoty rozhrania a hodnoty all, takže nula na tunelovom rozhraní nič neznamená, kým je all jedna. Rozhodnutie prísneho režimu je rozhodnutie o smerovaní, takže spustite vyhľadanie, ktoré spúšťa jadro, a porovnajte jeho odpoveď s rozhraním, ktorým paket skutočne prišiel.
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_filterPotom ping zopakujte a sledujte počítadlo chýb. Rastúci počet vedľa požiadavky, ktorú zachytenie už ukazuje, je podpisom tohto zahodenia, nie chýbajúcej trasy. Zapnite marťanské logovanie, kým ste tam, aby jadro pomenovalo zdroj a rozhranie, ktoré odmietlo. Spolu vylučujú šifru, firewall a chýbajúci iroute ako vysvetlenia.
Zapíšte východiskový stav, skôr než čokoľvek zmeníte: obe hodnoty, zariadenie, ktoré vybralo vyhľadanie, a počítadlo, ktoré ste sledovali. Práve tento záznam vám neskôr povie, či zmena urobila to, čo si myslíte.
Čo ktorý režim rp_filter skutočne prijíma
Jadro vystavuje tri hodnoty na rozhranie a nie sú to tri odtiene jedného pravidla. Nula kontrolu vypína. Jedna je prísna a vyžaduje, aby bol zdroj smerovaný späť cez rozhranie príchodu. Dvojka je voľná a vyžaduje len, aby v tabuľke existovala nejaká trasa k zdroju, kamkoľvek mieri.
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
Riadok, na ktorom tu záleží, je ten voľný, a to, čo naďalej odmieta. Podvrhnutý zdroj, ktorý je smerovateľný kdekoľvek vo vašej tabuľke, prejde, kým zdroj bez akejkoľvek trasy je stále odmietnutý. Na notebooku je to úzka ústupka; na routeri, ktorý preposiela prevádzku iných ľudí, je široká. Režim patrí hostiteľovi, takže to isté číslo nesie na dvoch miestach inú váhu.
Ktorý riadok táto topológia potrebuje, vyplýva z tabuľky a nie zo zvyku. Paket je legitímny a jeho zdroj je smerovateľný, takže voľný ho prijme a prísny nie. Nič v tomto prípade nežiada nulu a výber nuly by odstránil kontrolu, ktorá tu nič nestojí.
Vyberte najmenšiu zmenu, ktorá odstráni nejednoznačnosť
Voľný režim je najmenšia vhodná zmena a je to skutočné zmiernenie prísnosti, nie neškodný prepínač. Lepšia možnosť existuje vždy, keď to topológia dovolí: odstráňte prekrytie a nejednoznačnosť zmizne.
Kde je kancelársky prefix potrebný len cez Ethernet, vyhoďte ho z trás, ktoré ťahá profil, a adresa bude dostupná jednou cestou. Keď obe cesty skutočne musia existovať spolu, pripnite zdroj a zariadenie pravidlom politiky namiesto uvoľňovania overenia na každom rozhraní. Tým zostane prísne filtrovanie pre všetko ostatné na stroji a výnimka je zdokumentovaná tam, kde ju bude hľadať budúci inžinier.
Nech vyberiete akúkoľvek cestu, zapíšte ju do drop-inu sysctl, nie do živej príkazu. Nastavte kľúče all a default spolu, aby opätovné pripojenie nemohlo potichu obnoviť prísny 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Čo voľný režim obetuje, a kde
Voľný režim stále odmieta zdroj, ku ktorému by sa nedostala žiadna trasa, a prestáva odmietať podvrhnutý zdroj, ktorý je náhodou smerovateľný. Na notebooku je to úzka ústupka. Na zariadení, ktoré preposiela prevádzku, ktorá mu nepatrí, je tá istá voľba oveľa širšia. Preto to isté nastavenie nesie dva veľmi odlišné významy podľa toho, kde beží.
Úplne vypnúť kontrolu na hostiteľovi, ktorý preposiela prevádzku za iných ľudí, je jediná oprava, ktorej sa treba vyhnúť. Nula zahodí overenie, ktoré si voľný režim starostlivo drží. Ak hostiteľ preposiela za iných, argumentujte namiesto toho za možnosť s pravidlom politiky z predchádzajúcej časti.
Zanechajte poznámku, ktorá pomenuje obe rozhrania, prekrývajúci sa prefix a presnú skúšku, ktorá teraz prechádza. To je pre budúceho inžiniera užitočnejšie ako riadok, že filtrovanie bolo upravené.