Ĉu respondoj de Linux VPN malaperas? Kontrolu rp_filter kaj la itineron

Petoj forlasas la maŝinon, la VPN-partnero respondas, kaj la respondo neniam atingas la ingon. La tunelo estas supren, la protokoloj de la partnero montras, ke la paketo estas sendita, kaj nenio en la aplikaĵo klarigas la silenton. En Linux unu el la kutimaj suspektatoj estas filtrado de la inversa vojo: envenanta IPv4-paketo povas esti malakceptita, kiam la fonta validado ne kongruas kun la itinero, kiun la kerno atendas por tiu fonto. Trairi ĝin laŭorde diras al vi, ĉu tio estas la kaŭzo aŭ koincido. Ĝi ankaŭ malhelpas vin malŝalti sekurecan kontrolon por ripari mankan itineron.

Kion decidas la fonta validado

La kerno kontrolas, ĉu la fonta adreso de paketo estas kredinda por la interfaco, sur kiu ĝi alvenis, konsultante la itineran tabelon por itinero reen al tiu fonto. Se la inversa itinero montras aliloken, la paketo povas esti forĵetita antaŭ ol iu ajn fajroŝirmila regulo aŭ aplikaĵa ingo vidas ĝin. Tiu kontrolo ekzistas por malfaciligi certajn trompajn ŝablonojn, kaj ĝi ankaŭ estas kial nesimetriaj kaj politike itineritaj dezajnoj trafas ĝin, dum ĉiu ordinara kliento en la sama reto funkcias bone. Ordinaraj klientoj havas simetrian itineradon, kio estas ĝuste tio, kion la kontrolo supozas.

La grava vorto estas kredinda. La paketo povas esti tute laŭleĝa kaj tamen malsukcesi la kontrolon, ĉar laŭleĝeco ne estas tio, kio estas testata.

Legu la efektivan reĝimon, ne unu kampon

Ekzistas tri reĝimoj: malŝaltita, strikta kaj malstrikta. La strikta starigas alian itineran atendon ol la malstrikta, kaj la tutmonda agordo interagas kun tiuj por ĉiu interfaco, do legi unu dosieron povas malĝuste priskribi, kio efektive validas. Legu ambaŭ, kaj legu ilin sur la interfaco, kiu ricevas la respondon, ne sur la interfaco de la defaŭlta itinero.

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

La itinera serĉo en tiu tria linio estas la parto, kiun homoj preterlasas. Ĝi diras al vi, kion la kerno kredas pri la fonto, kaj tio estas ĝuste la enigo de la kontrolo.

Trovu la miskongruon antaŭ ol ŝanĝi la kontrolon

Eltrovu, kial la respondo alvenas sur tiu interfaco kaj ĉu ĝia inversa itinero devus malsami. Politika regulo, kiu sendas petojn laŭ unu vojo dum respondoj revenas laŭ alia, estas laŭleĝa dezajno, kaj ĝi ankaŭ estas la dezajno, kiun strikta validado malakceptas. Markoj uzataj en politika itinerado povas gravi ankaŭ ĉi tie, ĉar ili ŝanĝas tion, kion la inversa serĉo redonas.

Se la inversa itinero simple mankas, aldoni ĝin riparas la kaŭzon anstataŭ malŝalti kontrolon. Manka itinero, fajroŝirmila malakcepto kaj malĝusta trafika selektilo ĉiuj produktas la saman videblan simptomon, kaj nur unu el ili temas pri fonta validado.

Ne malŝaltu fontajn kontrolojn tutmonde kiel unuan reagon. Tio interŝanĝas specifan diagnozon kontraŭ larĝa konduta ŝanĝo, kiun vi devos memori poste.

Selektema ĝustigo, kiun vi povas defendi

Se mallarĝa ĝustigo vere necesas, limigu ĝin al la interfaco, kiu bezonas ĝin, notu kial, kaj metu ĝin en la agordon, kiu posedas tiun interfacon, por ke ĝi postvivu restartigon. Poste retestu la ĝustan fluon, kiu fiaskis, de la sama fonto al la sama celloko, anstataŭ ping al io oportuna.

Inkluzivu kazon, kiu ankoraŭ devus esti rifuzata. Se tiu kazo nun sukcesas, la ĝustigo malfortigis pli ol la unu vojon, kiun vi volis ripari.

Tenu IPv4 kaj IPv6 apartaj

Konata aspektanta sysctl ne estas politiko por ĉiu adresa familio. IPv6 havas sian propran konduton kaj proprajn agordojn, kaj maŝino povas esti strikta en unu familio kaj permesema en la alia sen ke iu rimarkas, ĝis difinita celloko fiaskas. Kontrolu ambaŭ, se la laborŝarĝo uzas ambaŭ.

Notu la reĝimon, la interfacon, la eligon de la itinera serĉo kaj la kialon de la ŝanĝo en unu loko. La sekva homo trovos la agordon kaj neniun klarigon, kaj aŭ forigos ĝin aŭ kopios ĝin tien, kie ĝi ne apartenas.