Linux VPN odgovori nestaju? Provjerite rp_filter i rutu

Zahtjevi napuštaju mašinu, VPN peer odgovara, a odgovor nikada ne stigne do soketa. Tunel je podignut, peer logovi pokazuju da je paket poslan, i ništa u aplikaciji ne objašnjava tišinu. Na Linuxu je jedan od uobičajenih sumnjivaca filtriranje povratne putanje: dolazni IPv4 paket može biti odbijen kada se validacija izvora ne slaže s rutom koju kernel očekuje za taj izvor. Ako to pratite po redu, saznat ćete je li to uzrok ili slučajnost. To vas također sprječava da isključite sigurnosnu kontrolu kako biste popravili rutu koja nedostaje.

Šta validacija izvora odlučuje

Kernel provjerava je li izvorna adresa paketa vjerodostojna za interfejs na koji je stigao, tako što konsultuje tabelu rutiranja za rutu natrag prema tom izvoru. Ako povratna ruta pokazuje negdje drugo, paket može biti odbačen prije nego što ga vidi bilo koje pravilo firewall-a ili soket aplikacije. Ta provjera postoji da oteža određene obrasce lažiranja, i upravo zato asimetrični i policy-rutirani dizajni nailaze na nju, dok svaki obični klijent na istoj mreži radi ispravno. Obični klijenti imaju simetrično rutiranje, što je upravo ono što provjera pretpostavlja.

Važna riječ je vjerodostojna. Paket može biti potpuno legitiman i ipak pasti na provjeri, jer se ne testira legitimnost.

Čitajte stvarni režim, ne jedno polje

Postoje tri režima: isključen, strog i labav. Strog nameće drugačije očekivanje rute od labavog, a globalna postavka djeluje zajedno s onima po interfejsu, pa čitanje jedne datoteke može pogrešno opisati šta je zapravo na snazi. Čitajte obje i čitajte ih na interfejsu koji prima odgovor, a ne na interfejsu zadane rute.

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

Pretraga rute u tom trećem redu je dio koji ljudi preskaču. Ona vam kaže šta kernel misli o izvoru, a to je upravo ulaz u provjeru.

Nađite nesklad prije nego što promijenite provjeru

Utvrdite zašto odgovor dolazi na taj interfejs i treba li njegova povratna ruta biti drugačija. Pravilo politike koje šalje zahtjeve jednim putem, a vraća odgovore drugim, legitiman je dizajn, i upravo taj dizajn stroga validacija odbija. Oznake koje se koriste u policy rutiranju i ovdje mogu biti važne, jer mijenjaju šta povratna pretraga vraća.

Ako povratna ruta jednostavno nedostaje, njeno dodavanje popravlja uzrok umjesto da isključi provjeru. Ruta koja nedostaje, odbijanje firewall-a i pogrešan selektor saobraćaja daju isti vidljivi simptom, a samo jedan od njih tiče se validacije izvora.

Ne isključujte provjere izvora globalno kao prvu reakciju. To mijenja konkretnu dijagnozu za široku promjenu ponašanja koju ćete morati pamtiti kasnije.

Selektivna prilagodba koju možete braniti

Ako je uska prilagodba zaista potrebna, ograničite je na interfejs kojem je potrebna, zapišite zašto i stavite je u konfiguraciju koja posjeduje taj interfejs da preživi restart. Zatim ponovo testirajte tačno onaj tok koji je pao, od istog izvora do istog odredišta, a ne ping prema nečemu zgodnom.

Uključite slučaj koji i dalje treba biti odbijen. Ako taj slučaj sada uspije, prilagodba je oslabila više od jedne putanje koju ste htjeli popraviti.

Držite IPv4 i IPv6 odvojeno

Poznato izgledajući sysctl nije politika za svaku familiju adresa. IPv6 ima svoje ponašanje i svoje postavke, a mašina može biti stroga na jednoj familiji i popustljiva na drugoj, a da to niko ne primijeti dok ne padne određeno odredište. Provjerite oboje ako radni teret koristi oboje.

Zapišite režim, interfejs, izlaz pretrage rute i razlog promjene na jednom mjestu. Sljedeća osoba naći će postavku i nikakvo objašnjenje, pa će je ili ukloniti ili kopirati negdje gdje joj nije mjesto.