IPsec na maraming subnet nawawalan ng return traffic? Bilangin ang reqid

Umalis ang trapiko sa isang site at hindi na bumabalik, parehong gateway ang nag-uulat ng tapos na negosasyon, at ang tanging palatandaan ay isang tumpok ng papalabas na packet na walang sagot. Sa isang Linux endpoint, ang karaniwang dahilan ay hindi ang lakas ng encryption, MTU o routing table. Ito ay ang granularity ng mga patakaran entry at ang numero na nag-uugnay sa bawat patakaran sa isang security association. Binabasa ng pamamaraan sa ibaba ang dalawang database bago hawakan ang anupaman.

Hiwalayin ang sintomas bago magbago ng anuman

Ang isang-daan na pagkabigo na may tapos na IKE negosasyon ay nagpapaliit ng problema sa data path. Maaaring tumugma ang palabas na patakaran at itinapon ang sagot, o hindi kailanman dumating ang sagot dahil walang maipadala ang kabilang panig. Mula sa isang aplikasyon, magkapareho ang anyo ng dalawa, at pinag-iiba sila ng xfrm databases.

Huwag magsimula sa MTU. Ang maling MTU ay nagdudulot ng pagtigil at sintomas ng fragmentation, hindi ng malinis na paghahati ng direksyon na may tumataas na palabas na counter.

Basahin ang patakaran database at ang state database

Sa Linux, ang encryption ay pinagpapasyahan ng mga patakaran entry, kaya isang tugmang patakaran, hindi ruta, ang naglalagay ng packet sa tunnel. Patakbuhin ang ip xfrm policy upang makita ang mga selector, direksyon, priyoridad at template ng bawat entry, at ip xfrm state upang makita ang mga naitatag na association kasama ang kanilang reqid. Ang patakaran at ang association ay pinag-uugnay ng reqid na iyon.

Tingnan ang lahat ng tatlong direksyon. Saklaw ng palabas at papasok ang trapiko papunta at mula sa host na ito; mahalaga ang pasulong na direksyon kapag nagruruta ang host para sa iba. Ang nawawala o hindi tugmang entry sa isang direksyon ay nagpapaliwanag ng isang-daan na resulta nang walang anumang cryptographic fault.

Ang klasikong asimetriya: isang reqid para sa maraming subnet

Ang karaniwang pagkabigo ay nagmumula sa isang peer na naglalagay ng patakaran para sa lahat ng napagkasunduang subnet sa ilalim ng isang reqid, na nangyayari sa generate_policy require ng racoon. Ang trapiko ay lumalabas sa association na huling naitatag, habang ang kabilang panig ay may hiwalay na association sa bawat subnet. Dumarating ang mga sagot sa isang association na ang reqid ay hindi tumutukoy sa patakarang dapat tumanggap sa kanila, at itinatapon ng kernel ang mga ito pagkatapos ng decryption.

Ang pagwawasto ay pagbabago sa configuration, hindi patakaran ng firewall: binibigyan ng generate_policy unique; ang bawat patakaran ng sarili nitong reqid, kaya ang mga association ng peer sa bawat patakaran ay may tugmang kapareha. Ilapat ito, makipagnegosasyon muli, at bilangin ang magkakaibang reqid para sa inaasahang subnet bago magpahayag ng tagumpay.

Kung dalawang subnet pa rin ang nagbabahagi ng isang reqid habang inaasahan ng kabilang panig ang dalawa, natagpuan mo ang asimetriya. Itala ang pagmamapa, dahil ito ang ebidensya na inayos o pinanatili ito ng susunod na pagbabago.

Ang mga selector ay nagmumula sa negosasyon, hindi sa iyong configuration

Ang mga protektadong saklaw ay ang napagkasunduan ng dalawang dulo, hindi ang hiniling ng isang panig. Ang client na nag-aalok ng pares ng host laban sa malawak na malayong saklaw ay tumatanggap ng makitid na bersyon ng gateway, at hindi ito mapapalawak ng client. Basahin ang mga naka-install na selector sa halip na ang nasa iyong lokal na file.

Kapag ang layunin ay kabaligtaran, ang panatilihin ang isang destinasyon sa labas ng tunnel, magdagdag ng bypass na patakaran na may mas mababang priority number upang talunin nito ang awtomatikong naka-install na entry. Ang patakarang walang template ay nagpapahintulot ng plaintext, na ginagawa itong sadyang eksepsyon para sa change record kaysa hakbang sa debugging.

I-verify sa ayos na ito, at alamin kung paano ibalik

Ilista ang mga patakaran para sa bawat subnet sa dalawang direksyon, kasama ang pasulong kung nagruruta ang host. Bilangin ang magkakaibang reqid at kumpirmahin ang isa kada patakaran sa panig na umaasa nito. Ihambing ang mga naka-install na selector sa mga napagkasunduan. Basahin muli ang mga counter kada association pagkatapos ng key renewal, dahil ang association na sinuri mo ay maaaring wala na. Suriin ang mga ruta sa huli, dahil ang nawawalang ruta papunta sa malayong subnet ay nagdudulot ng katulad na isang-daan na sintomas na may malinis na patakaran counter.

Bago baguhin ang peer, i-save ang kasalukuyang output ng dalawang xfrm command. Kung hindi naibalik ng bagong setting ang direksyon ng pagbabalik, ang pagbalik sa output na iyon ay mas mabilis na rollback kaysa muling pagbuo ng tunnel mula sa memorya, at pinapanatili nitong tapat ang paghahambing.