VPN между сайтове работи само в една посока: две различни повреди

Отговор, който никога не се връща, и връзка, която е отказана, са различни повреди. Сравнете политиката, маршрутизацията и адреса на източника, който сървърът наистина вижда.

Сайт A достига до B, B не може да достигне до A, а тунелът изглежда наред в двете посоки. Преди да пипате тунела, решете коя повреда имате в действителност. Нова връзка, започната от B и отказана, и отговор на връзка, започната от A, който никога не пристига, дават подобни оплаквания и напълно различни диагнози. Едното е проблем с политика или маршрут по пътя; другото е проблем с обратния път или състоянието на трафик, който вече е бил разрешен.

Това разграничение решава кои команди си заслужава да се изпълнят.

Две повреди, които изглеждат еднакви

В първия случай хостът на B изпраща SYN към A и нищо не се връща. Във втория хостът на A отваря сесия успешно и отговорът изчезва по обратния път. И двамата потребители казват, че връзката е еднопосочна, и двамата описват пакет, който е изчезнал, така че описанието само по себе си не може да ги различи.

Попитайте коя страна е започнала неуспешния опит. Този единствен факт премахва половината от възможните причини.

След това проверете дали тестът е използвал едни и същи хостове и услуга през цялото време. Ping от едната страна и връзка към споделена папка от другата изпитват две различни неща, а диагностика от шлюза може да избере адрес на тунела, който никакъв потребителски трафик не използва.

Случай първи: обратният път липсва

Отдалечен сървър, който отговаря през различен шлюз по подразбиране, може да получи заявката и да насочи отговора другаде. След това защитните стени, които следят състоянието, изхвърлят асиметричния отговор, защото той не съвпада с установен поток, което изглежда точно като посока, която никога не е работила. Транслацията добавя още един вариант: дестинацията вижда транслатиран адрес на източника и отговаря на него, така че правило, написано за оригиналния адрес, никога не съвпада.

Проверете адреса, който дестинацията действително вижда след транслацията, и обратния маршрут за този адрес, а не за оригиналната подмрежа.

Случай втори: политиката никога не го е разрешавала

Обратният случай е по-прост и по-чест, отколкото изглежда: един офис трябва да ползва централна услуга и никога да не започва връзки към центъра. Тази асиметрия е съзнателно решение за достъп и тунелът работи както е проектиран. Прочетете политиката за достъп, преди да променяте каквато и да е настройка на тунела. Документът, а не снемането на пакети, посочва коя посока е била предвидена. Снемането може да покаже само какво се е случило, не какво е било разрешено.

Ако двупосочното иницииране наистина е необходимо, добавете разрешение за конкретната услуга чрез поддържания набор от правила на платформата. Правенето на всяка подмрежа взаимно доверена, за да се поправи едно приложение, превръща тясно изискване в широко разрешение и тази размяна рядко се преглежда после.

Сравнете преди и след на същите хостове

Наблюдавайте двата края на един и същ опит, а не два отделни опита. Снемайте на шлюза на иницииращия хост и на дестинацията, после сравнете какво е влязло, какво е излязло и какъв адрес е видяла далечната страна.

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

Ако снемането на дестинацията показва заявката с неочакван адрес на източника, отговорът е в транслацията или маршрутизацията, а не в политиката за сигурност на тунела. Ако дестинацията не показва никаква заявка, пакетът никога не е преминал защитения път.

След корекция повторете идентичния тест от идентичния хост и потвърдете, че несвързаният достъп все още е забранен. Статус на тунела “established” не подкрепя нито едно от двете заключения сам по себе си.

Подобни статии