IPsec s više podmreža gubi povratni promet? Prebrojite reqidove

Promet napušta jedno mjesto i nikad se ne vraća, oba pristupnika prijavljuju dovršeno pregovaranje, a jedini trag je hrpa odlaznih paketa bez odgovora. Na Linux krajnjoj točki uobičajeni uzrok nije jačina enkripcije, MTU ni tablica usmjeravanja. To je granulacija unosa politike i broj koji povezuje svaku politiku sa sigurnosnom asocijacijom. Postupak u nastavku čita te dvije baze prije nego što se dotakne bilo čega drugog.

Odvojite simptom prije nego što bilo što promijenite

Jednosmjerna greška s dovršenim IKE pregovaranjem svodi problem na podatkovni put. Ili se odlazna politika podudarala i odgovor je odbačen, ili odgovor nikad nije stigao jer druga strana nije imala čime da ga pošalje. Iz aplikacije oba slučaja izgledaju isto, a xfrm baze ih razlikuju.

Ne počinjite s MTU-om. Pogrešan MTU stvara zastoje i simptome fragmentacije, a ne čisto razdvajanje smjera s rastućim odlaznim brojačima.

Pročitajte bazu politika i bazu stanja

Na Linuxu o enkripciji odlučuju unosi politike, pa odgovarajuća politika, a ne ruta, je ono što stavlja paket u tunel. Pokrenite ip xfrm policy da vidite selektore, smjer, prioritet i predložak svakog unosa, i ip xfrm state da vidite uspostavljene asocijacije s njihovim reqidovima. Politika i asocijacija povezane su tim reqidom.

Pogledajte sva tri smjera. Odlazni i dolazni pokrivaju promet prema i od ovog hosta; smjer naprijed važan je kada host usmjerava za druge. Unos koji nedostaje ili se razlikuje u jednom smjeru objašnjava jednosmjerni rezultat bez ikakve kriptografske greške.

Klasična asimetrija: jedan reqid za više podmreža

Česta greška dolazi od partnera koji instalira politike za sve dogovorene podmreže pod jednim reqidom, što se događa s generate_policy require kod racoona. Promet tada izlazi kroz asocijaciju uspostavljenu posljednju, dok druga strana drži zasebnu asocijaciju po podmreži. Odgovori pristižu na asocijaciju čiji reqid ne označava politiku koja bi ih trebala prihvatiti, a jezgra ih odbacuje nakon dešifriranja.

Ispravak je promjena konfiguracije, a ne vatrozidno pravilo: generate_policy unique; daje svakoj politici vlastiti reqid, tako da asocijacije partnera po politici imaju odgovarajuće partnere. Primijenite to, ponovno pregovarajte i prebrojite različite reqidove za očekivane podmreže prije nego što proglasite uspjeh.

Ako dvije podmreže još dijele reqid dok druga strana očekuje dva, pronašli ste asimetriju. Zapišite mapiranje, jer je to dokaz da ju je sljedeća promjena ispravila ili sačuvala.

Selektori dolaze iz pregovaranja, a ne iz vaše konfiguracije

Zaštićeni rasponi su ono o čemu su se oba kraja dogovorila, a ne ono što je jedna strana tražila. Klijent koji nudi par hostova prema širokom udaljenom rasponu dobiva suženu verziju pristupnika i ne može ju proširiti. Čitajte instalirane selektore umjesto onih u svojoj lokalnoj datoteci.

Kada je cilj suprotan, zadržati jedno odredište izvan tunela, dodajte politiku zaobilaženja s nižim prioritetnim brojem kako bi pobijedila automatski instaliran unos. Politika bez predloška dopušta čisti tekst, što ju čini namjernom iznimkom za zapis promjene umjesto koraka otklanjanja pogrešaka.

Provjerite ovim redom i znajte kako se vratiti

Popišite politike za svaku podmrežu u oba smjera, uključujući smjer naprijed ako host usmjerava. Prebrojite različite reqidove i potvrdite jedan po politici na strani koja ga očekuje. Usporedite instalirane selektore s dogovorenima. Ponovno pročitajte brojače po asocijaciji nakon obnove ključa, jer asocijacija koju ste pregledali možda je već nestala. Provjerite rute na kraju, jer ruta koja nedostaje prema udaljenoj podmreži daje sličan jednosmjerni simptom s čistim brojačima politike.

Prije nego što promijenite partnera, spremite trenutni izlaz obaju xfrm naredbi. Ako nova postavka ne obnovi povratni smjer, vraćanje tog izlaza brži je povratak od ponovne izgradnje tunela po sjećanju i održava usporedbu poštenom.