Site-to-site VPN darbojas tikai vienā virzienā: divi dažādi bojājumi

Vietne A sasniedz B, B nevar sasniegt A, un tunelis abos virzienos izskatās kārtībā. Pirms aiztikt tuneli, izlemiet, kurš bojājums jums patiešām ir. Jauns savienojums, kas sākts B un tiek noraidīts, un atbilde uz A sāktu savienojumu, kas nekad nenāk, rada līdzīgas sūdzības un pilnīgi atšķirīgas diagnozes. Viens ir politikas vai maršruta problēma ceļā; otrs ir atgriešanās ceļa vai stāvokļa problēma jau atļautai plūsmai.

Šī atšķirība nosaka, kuras komandas ir vērts izpildīt.

Divi bojājumi, kas izskatās vienādi

Pirmajā gadījumā B resursdators sūta SYN uz A, un nekas neatgriežas. Otrajā A resursdators veiksmīgi atver sesiju, un atbilde pazūd atgriešanās ceļā. Abi lietotāji saka, ka savienojums ir vienvirziena, un abi apraksta pazudušu paketi, tāpēc apraksts vien tos nevar atdalīt.

Jautājiet, kura puse sāka neveiksmīgo mēģinājumu. Šis viens fakts noņem pusi iespējamo cēloņu.

Pēc tam pārbaudiet, vai tests visu laiku izmantoja tos pašus resursdatorus un to pašu pakalpojumu. Ping no vienas puses un koplietotās mapes savienojums no otras pārbauda divas dažādas lietas, un diagnostika no vārtejas var izvēlēties tuneļa adresi, ko neizmanto neviens lietotāja trafiks.

Pirmais gadījums: trūkst atgriešanās ceļa

Attālināts serveris, kas atbild pa citiem noklusējuma vārtiem, var saņemt pieprasījumu un maršrutēt atbildi citur. Tad stāvokli sekojošie ugunsmūri nomet asimetrisko atbildi, jo tā neatbilst izveidotai plūsmai, un tas izskatās tieši kā virziens, kas nekad nav strādājis. Tulkojumam pievienojas vēl viens variants: galamērķis redz tulkotu avotu un atbild tam, tāpēc noteikums, kas rakstīts sākotnējai adresei, nekad nesakrīt.

Pārbaudiet adresi, ko galamērķis pēc tulkošanas patiešām redz, un atgriešanās maršrutu šai adresei, nevis sākotnējam apakštīklam.

Otrais gadījums: politika to nekad nav atļāvusi

Pretējais gadījums ir vienkāršāks un biežāks, nekā izskatās: vienam birojam ir jāizmanto centrālais pakalpojums un nekad jāsāk savienojumi uz centru. Šī asimetrija ir apzināts piekļuves lēmums, un tunelis darbojas kā projektēts. Izlasiet piekļuves politiku pirms jebkura tuneļa iestatījuma maiņas. Kuru virzienu bija paredzēts, norāda dokuments, nevis pakešu tveršana. Tveršana var parādīt tikai to, kas notika, nevis to, kas bija atļauts.

Ja divvirzienu iniciēšana patiešām ir nepieciešama, pievienojiet konkrētā pakalpojuma atļauju, izmantojot platformas atbalstīto noteikumu kopu. Visu apakštīklu savstarpēja uzticēšanās vienas lietotnes labošanai šauru prasību pārvērš plašā atļaujā, un šis maiņas darījums vēlāk reti tiek pārskatīts.

Salīdziniet pirms un pēc tajos pašos resursdatoros

Vērojiet abus viena mēģinājuma galus, nevis divus atsevišķus mēģinājumus. Tveriet sākošā resursdatora vārtejā un galamērķī, tad salīdziniet, kas iegāja, kas izgāja un kādu adresi redzēja tālā puse.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Ja tveršana galamērķī rāda pieprasījumu ar negaidītu avota adresi, atbilde ir tulkošanā vai maršrutēšanā, nevis tuneļa drošības politikā. Ja galamērķis vispār nerāda pieprasījumu, pakete nekad nav šķērsojusi aizsargāto ceļu.

Pēc labojuma atkārtojiet to pašu testu no tā paša resursdatora un apstipriniet, ka nesaistīta piekļuve joprojām tiek liegta. Tuneļa statuss “established” pats par sevi neatbalsta nevienu no diviem secinājumiem.