Odzivi Linux VPN izginejo? Preverite rp_filter in pot
Preverjanje vira IPv4 lahko zavrne paket, katerega povratna pot ne ustreza načinu. Preglejte usmerjanje in dejansko nastavitev, preden jo izklopite.
Zahteve zapustijo stroj, partner VPN odgovori, odgovor pa nikoli ne doseže vtiča. Tunel je vzpostavljen, dnevniki partnerja kažejo pošiljanje paketa, in nič v aplikaciji ne pojasni tišine. V Linuxu je eden običajnih osumljencev filtriranje povratne poti: dohodni paket IPv4 je lahko zavrnjen, ko se preverjanje vira ne ujema s potjo, ki jo jedro pričakuje za ta vir. Pregled po vrsti pove, ali je to vzrok ali naključje. Prav tako vas zadrži pred izklopom varnostne kontrole, da bi popravili manjkajočo pot.
Kaj odloča preverjanje vira
Jedro preveri, ali je izvorni naslov paketa verjeten za vmesnik, po katerem je prispel, tako da v usmerjevalni tabeli poišče pot nazaj do tega vira. Če povratna pot kaže drugam, je paket lahko zavržen, preden ga vidi katero koli pravilo požarnega zidu ali vtič aplikacije. Ta kontrola obstaja zato, da oteži nekatere vzorce ponarejanja, in zato se asimetrične ter politično usmerjene zasnove zaletijo vanjo, medtem ko vsak običajen odjemalec v istem omrežju deluje dobro. Običajni odjemalci imajo simetrično usmerjanje, kar je natanko tisto, kar kontrola predpostavlja.
Pomembna beseda je verjeten. Paket je lahko povsem zakonit in kljub temu ne prestane kontrole, ker se ne preverja zakonitost.
Preberite dejanski način, ne enega polja
Obstajajo trije načini: izklopljen, strog in ohlapen. Strog nalaga drugačno pričakovanje poti kot ohlapen, globalna nastavitev pa deluje skupaj s tistimi za posamezni vmesnik, zato lahko branje ene datoteke napačno opiše, kaj dejansko velja. Preberite oba in ju preberite na vmesniku, ki prejme odgovor, ne na vmesniku privzete poti.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>Iskanje poti v tretji vrstici je del, ki ga ljudje preskočijo. Pove, kaj jedro misli o viru, in to je natanko vhod kontrole.
Poiščite neskladje, preden spremenite kontrolo
Ugotovite, zakaj odgovor prispe na ta vmesnik in ali bi morala biti njegova povratna pot drugačna. Pravilo politike, ki pošilja zahteve po eni poti, medtem ko se odgovori vračajo po drugi, je zakonita zasnova, in prav to zasnovo strogo preverjanje zavrne. Oznake, uporabljene pri političnem usmerjanju, so lahko pomembne tudi tu, ker spreminjajo, kaj vrne povratno iskanje.
Če povratna pot preprosto manjka, jo dodajanje popravi vzrok, namesto da bi izklopilo kontrolo. Manjkajoča pot, zavrnitev požarnega zidu in napačen izbirnik prometa dajo enak viden simptom, in le eden od njih se nanaša na preverjanje vira.
Ne izklopite preverjanja vira globalno kot prvi odziv. To zamenja konkretno diagnozo za široko spremembo vedenja, ki si jo boste morali pozneje zapomniti.
Selektivna prilagoditev, ki jo lahko zagovarjate
Če je ozka prilagoditev res potrebna, jo omejite na vmesnik, ki jo potrebuje, zapišite zakaj in jo vstavite v konfiguracijo, ki ima ta vmesnik, da preživi ponovni zagon. Nato znova preizkusite natanko tisti tok, ki je spodletel, iz istega vira na isti cilj, namesto pinga na nekaj priročnega.
Vključite primer, ki bi moral biti še vedno zavrnjen. Če ta primer zdaj uspe, je prilagoditev oslabila več kot eno pot, ki ste jo hoteli popraviti.
Držite IPv4 in IPv6 ločeno
Znano videč sysctl ni politika za vsako družino naslovov. IPv6 ima svoje vedenje in svoje nastavitve, stroj pa je lahko strog v eni družini in popustljiv v drugi, ne da bi kdo opazil, dokler ne spodleti določen cilj. Preverite oba, če delovna obremenitev uporablja oba.
Zapišite način, vmesnik, izpis iskanja poti in razlog spremembe na enem mestu. Naslednja oseba bo našla nastavitev in nobene razlage ter jo bo bodisi odstranila bodisi kopirala tja, kamor ne sodi.