Linux VPN atsakymai dingsta? Patikrinkite rp_filter ir maršrutą

Užklausos palieka mašiną, VPN partneris atsako, o atsakymas niekada nepasiekia lizdo. Tunelis pakeltas, partnerio žurnalai rodo, kad paketas siunčiamas, ir niekas programoje nepaaiškina tylos. Linux atveju vienas įprastų įtariamųjų yra atvirkštinio kelio filtravimas: gaunamas IPv4 paketas gali būti atmestas, kai šaltinio tikrinimas nesutampa su maršrutu, kurio branduolys tikisi tam šaltiniui. Nuoseklus perėjimas per tai pasako, ar tai priežastis, ar atsitiktinumas. Tai taip pat neleidžia išjungti saugumo kontrolės, kad pataisytumėte trūkstamą maršrutą.

Ką nusprendžia šaltinio tikrinimas

Branduolys tikrina, ar paketo šaltinio adresas yra tikėtinas sąsajai, kuria jis atėjo, pasižiūrėdamas maršrutų lentelėje maršruto atgal į tą šaltinį. Jei atgalinis maršrutas rodo kitur, paketas gali būti išmestas anksčiau, nei jį pamatys bet kuri ugniasienės taisyklė ar programos lizdas. Ši patikra egzistuoja tam, kad tam tikri apsimetimo šablonai būtų sunkesni, ir todėl asimetriški bei politikos maršrutizuoti sprendimai į ją atsitrenkia, o kiekvienas paprastas klientas tame pačiame tinkle veikia gerai. Paprasti klientai turi simetrinį maršrutizavimą, ir būtent tai patikra daro prielaidą.

Svarbus žodis yra tikėtinas. Paketas gali būti visiškai teisėtas ir vis tiek nepraeiti patikros, nes tikrinamas ne teisėtumas.

Skaitykite faktinį režimą, o ne vieną lauką

Yra trys režimai: išjungtas, griežtas ir laisvas. Griežtas nustato kitokį maršruto lūkestį nei laisvas, o globalus nustatymas sąveikauja su tais, kurie skirti kiekvienai sąsajai, todėl vieno failo skaitymas gali neteisingai apibūdinti tai, kas iš tikrųjų galioja. Skaitykite abu ir skaitykite juos sąsajoje, kuri gauna atsakymą, o ne numatytojo maršruto sąsajoje.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Maršruto paieška trečioje eilutėje yra ta dalis, kurią žmonės praleidžia. Ji pasako, ką branduolys mano apie šaltinį, ir tai yra būtent patikros įvestis.

Raskite neatitikimą prieš keisdami patikrą

Išsiaiškinkite, kodėl atsakymas ateina per tą sąsają ir ar jo atgalinis maršrutas turėtų skirtis. Politikos taisyklė, kuri užklausas siunčia vienu keliu, o atsakymus grąžina kitu, yra teisėtas sprendimas, ir būtent šį sprendimą atmeta griežtas tikrinimas. Politikos maršrutizavime naudojami žymėjimai čia taip pat gali turėti reikšmės, nes jie keičia, ką grąžina atgalinė paieška.

Jei atgalinio maršruto tiesiog trūksta, jo pridėjimas ištaiso priežastį, o ne išjungia patikrą. Trūkstamas maršrutas, ugniasienės atmetimas ir neteisingas srauto parinkiklis sukuria tą patį matomą simptomą, ir tik vienas jų yra apie šaltinio tikrinimą.

Neišjunkite šaltinio tikrinimų globaliai kaip pirmos reakcijos. Tai iškeičia konkretų diagnozę į platų elgsenos pakeitimą, kurį vėliau turėsite atsiminti.

Selektyvus pritaikymas, kurį galite apginti

Jei siauro pritaikymo tikrai reikia, apribokite jį sąsaja, kuriai jo reikia, užsirašykite kodėl ir įdėkite į konfigūraciją, kuriai priklauso ta sąsaja, kad jis išliktų po perkrovimo. Tada dar kartą patikrinkite tiksliai tą srautą, kuris nepavyko, iš to paties šaltinio į tą patį tikslą, o ne ping į ką nors patogaus.

Įtraukite atvejį, kuris vis tiek turėtų būti atmetamas. Jei šis atvejis dabar pavyksta, pritaikymas susilpnino daugiau nei vieną kelią, kurį norėjote pataisyti.

Laikykite IPv4 ir IPv6 atskirai

Pažįstamai atrodantis sysctl nėra politika kiekvienai adresų šeimai. IPv6 turi savo elgseną ir savo nustatymus, ir mašina gali būti griežta vienoje šeimoje bei atlaidi kitoje, niekam nepastebint, kol nepasiseka konkretus tikslas. Patikrinkite abu, jei darbo krūvis naudoja abu.

Užsirašykite režimą, sąsają, maršruto paieškos išvestį ir pakeitimo priežastį vienoje vietoje. Kitas žmogus ras nustatymą ir jokio paaiškinimo, ir arba jį pašalins, arba nukopijuos ten, kur jam ne vieta.