Site-to-site VPN veikia tik viena kryptimi: du skirtingi gedimai

A svetainė pasiekia B, B negali pasiekti A, o tunelis abiem kryptimis atrodo tvarkingai. Prieš liesdami tunelį nuspręskite, kurį gedimą iš tikrųjų turite. Naujas ryšys, pradėtas B ir atmestas, bei atsakymas į A pradėtą ryšį, kuris niekada neateina, sukelia panašius skundus ir visiškai skirtingas diagnozes. Vienas yra politikos ar maršruto problema kelyje; kitas yra grįžimo kelio ar būsenos problema jau leistam srautui.

Šis skirtumas nulemia, kurias komandas verta vykdyti.

Du gedimai, kurie atrodo vienodai

Pirmuoju atveju B hostas siunčia SYN į A, ir nieko negrįžta. Antruoju A hostas sėkmingai atidaro sesiją, o atsakymas dingsta grįžimo kelyje. Abu naudotojai sako, kad ryšys vienkryptis, ir abu aprašo dingusį paketą, todėl vien aprašymas jų neatskirs.

Paklauskite, kuri pusė pradėjo nepavykusį bandymą. Šis vienas faktas pašalina pusę galimų priežasčių.

Tada patikrinkite, ar testas visą laiką naudojo tuos pačius hostus ir tą pačią paslaugą. Ping iš vienos pusės ir bendro aplanko ryšys iš kitos tikrina du skirtingus dalykus, o diagnostika iš tinklo vartų gali pasirinkti tunelio adresą, kurio nenaudoja joks naudotojo srautas.

Pirmasis atvejis: trūksta grįžimo kelio

Nuotolinis serveris, atsakantis per kitus numatytuosius vartus, gali gauti užklausą ir nukreipti atsakymą kitur. Tada būseną sekantys ugniasieniai atmeta nesimetrišką atsakymą, nes jis neatitinka nustatyto srauto, o tai atrodo būtent kaip kryptis, kuri niekada neveikė. Vertimas prideda dar vieną variantą: paskirties vieta mato išverstą šaltinį ir atsako jam, todėl taisyklė, parašyta pradiniam adresui, niekada nesutampa.

Patikrinkite adresą, kurį paskirties vieta iš tikrųjų mato po vertimo, ir grįžimo maršrutą tam adresui, o ne pradiniam potinkliui.

Antrasis atvejis: politika to niekada neleido

Priešingas atvejis paprastesnis ir dažnesnis, nei atrodo: vienas biuras turi naudoti centrinę paslaugą ir niekada nepradėti ryšių į centrą. Ši asimetrija yra sąmoningas prieigos sprendimas, o tunelis veikia taip, kaip suprojektuotas. Perskaitykite prieigos politiką prieš keisdami bet kokį tunelio nustatymą. Kuri kryptis buvo numatyta, nurodo dokumentas, o ne paketų įrašymas. Įrašymas gali parodyti tik tai, kas įvyko, o ne tai, kas buvo leista.

Jei dvipusis inicijavimas tikrai reikalingas, pridėkite konkrečios paslaugos leidimą per platformos palaikomą taisyklių rinkinį. Visų potinklių abipusis pasitikėjimas vienai programai sutaisyti siaurą reikalavimą paverčia plačiu leidimu, o šis mainas vėliau retai peržiūrimas.

Palyginkite prieš ir po tuose pačiuose hostuose

Stebėkite abu to paties bandymo galus, o ne du atskirus bandymus. Įrašykite pradinio hosto vartuose ir paskirties vietoje, tada palyginkite, kas įėjo, kas išėjo ir kokį adresą matė tolimoji pusė.

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

Jei įrašas paskirties vietoje rodo užklausą su netikėtu šaltinio adresu, atsakymas yra vertime arba maršrutizavime, o ne tunelio saugumo politikoje. Jei paskirties vieta iš viso nerodo užklausos, paketas niekada neperėjo apsaugoto kelio.

Po pataisymo pakartokite tą patį testą iš to paties hosto ir patvirtinkite, kad nesusijusi prieiga vis dar atmetama. Tunelio būsena “established” pati savaime nepagrindžia nė vienos iš dviejų išvadų.