IPsec ar vairākiem apakštīkliem zaudē atgaitas trafiku? Saskaitiet reqid

Trafiks atstāj vienu vietu un nekad neatgriežas, abi vārtejas ziņo par pabeigtām sarunām, un vienīgā norāde ir kaudze izejošu pakešu bez atbildēm. Linux galapunktā ierastais cēlonis nav šifrēšanas stiprums, MTU vai maršrutēšanas tabula. Tas ir politikas ierakstu granularitāte un numurs, kas saista katru politiku ar drošības asociāciju. Tālāk aprakstītā procedūra nolasa šīs divas datubāzes, pirms tiek aiztikts kaut kas cits.

Atdaliet simptomu, pirms kaut ko maināt

Vienvirziena kļūme ar pabeigtām IKE sarunām sašaurina problēmu līdz datu ceļam. Vai nu izejošā politika sakrita un atbilde tika izmesta, vai atbilde nekad nenonāca, jo otrai pusei nebija ar ko to nosūtīt. No lietojumprogrammas abi gadījumi izskatās vienādi, un xfrm datubāzes tos atšķir.

Nesāciet ar MTU. Nepareizs MTU rada iesprūšanas un fragmentācijas simptomus, nevis tīru virziena sadalījumu ar augošiem izejošiem skaitītājiem.

Nolasiet politikas datubāzi un stāvokļu datubāzi

Linux šifrēšanu nosaka politikas ieraksti, tāpēc atbilstoša politika, nevis maršruts, ievada paketi tunelī. Palaidiet ip xfrm policy, lai redzētu selektorus, virzienu, prioritāti un katra ieraksta veidni, un ip xfrm state, lai redzētu izveidotās asociācijas ar to reqid. Politiku un asociāciju saista šis reqid.

Apskatiet visus trīs virzienus. Izejošais un ienākošais aptver trafiku uz šo resursdatoru un no tā; pārsūtīšanas virziens ir svarīgs, kad resursdators maršrutē citu vietā. Trūkstošs vai neatbilstošs ieraksts vienā virzienā izskaidro vienvirziena rezultātu bez jebkādas kriptogrāfiskas kļūdas.

Klasiskā asimetrija: viens reqid vairākiem apakštīkliem

Bieža kļūme nāk no partnera, kas instalē politiku visiem saskaņotajiem apakštīkliem zem viena reqid, kas notiek ar racoon generate_policy require. Trafiks tad iziet caur pēdējo izveidoto asociāciju, kamēr otra puse uztur atsevišķu asociāciju katram apakštīklam. Atbildes nonāk asociācijā, kuras reqid neapzīmē politiku, kurai tās būtu jāpieņem, un kodols tās izmet pēc atšifrēšanas.

Labojums ir konfigurācijas izmaiņas, nevis ugunsmūra noteikums: generate_policy unique; piešķir katrai politikai savu reqid, tāpēc partnera asociācijām pa politikai ir atbilstoši partneri. Piemērojiet to, vienojieties no jauna un saskaitiet atšķirīgos reqid sagaidāmajiem apakštīkliem, pirms pasludināt panākumus.

Ja divi apakštīkli joprojām dala vienu reqid, kamēr otra puse sagaida divus, jūs esat atradis asimetriju. Pierakstiet kartējumu, jo tas ir pierādījums, ka nākamā izmaiņa to izlaboja vai saglabāja.

Selektori nāk no sarunām, nevis no jūsu konfigurācijas

Aizsargātie diapazoni ir tas, par ko vienojās abi gali, nevis tas, ko prasīja viena puse. Klients, kas piedāvā resursdatoru pāri pret plašu attālinātu diapazonu, saņem sašaurināto vārtejas versiju, un klients to nevar paplašināt. Lasiet instalētos selektorus, nevis tos savā vietējā failā.

Kad mērķis ir pretējs, paturēt vienu galamērķi ārpus tuneļa, pievienojiet apiešanas politiku ar zemāku prioritātes numuru, lai tā uzvarētu automātiski instalēto ierakstu. Politika bez veidnes pieļauj vienkāršu tekstu, kas padara to par apzinātu izņēmumu izmaiņu žurnālam, nevis atkļūdošanas soli.

Pārbaudiet šādā secībā un ziniet, kā atritināt

Uzskaitiet politiku katram apakštīklam abos virzienos, tostarp pārsūtīšanas virzienu, ja resursdators maršrutē. Saskaitiet atšķirīgos reqid un apstipriniet vienu uz politiku tajā pusē, kas to sagaida. Salīdziniet instalētos selektorus ar saskaņotajiem. Pēc atslēgas atjaunošanas vēlreiz nolasiet asociācijas skaitītājus, jo pārbaudītā asociācija jau var būt pazudusi. Maršrutus pārbaudiet pēdējos, jo trūkstošs maršruts uz attālo apakštīklu rada līdzīgu vienvirziena simptomu ar tīriem politikas skaitītājiem.

Pirms maināt partneri, saglabājiet abu xfrm komandu pašreizējo izvadi. Ja jaunais iestatījums neatjauno atgaitas virzienu, šīs izvades atjaunošana ir ātrāka atritināšana nekā tuneļa atjaunošana no atmiņas, un tā saglabā godīgu salīdzinājumu.