VPN е свързан, но защитната стена още блокира: как да разберете кое

Тунелът работи и един порт все още се проваля. Прочетете пътя, после политиката на всяко ниво и променете най-тясното правило, вместо да изключвате някоя от двете проверки.

Клиентът казва, че е свързан, ресурсът все още отказва, а обичайната следваща стъпка е да изключим нещо. Двете проверки в това изречение вършат различна работа: VPN изгражда път за обхванатия трафик, а защитната стена решава за всяка връзка дали трафикът може да мине. Работещ тунел с отказваща политика изглежда точно като счупен тунел от мястото на потребителя, затова задачата е да открием кой слой отговаря. Ето реда, който следвам, с прочита, който ви казва да спрете.

Отделете пътя от политиката

Започнете с формата на отказа, защото това е безплатна информация. Изхвърлянето на пакет дава таймаут: клиентът опитва отново, нищо не се връща и командата виси, докато не се откаже. Отказът дава отхвърляне или нулиране: нещо отговори и каза „не“. Услуга, която не слуша, отказва на самия хост, без никаква защитна стена.

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

Прочетете пътя с един преглед

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

Един капан, специфичен за VPN, заслужава отделна проверка. В WireGuard AllowedIPs на партньора е едновременно маршрут и криптографски филтър: пакет, чийто изходен адрес не попада в разрешеното множество на партньора, се изхвърля, преди да бъде прегледано каквото и да е правило на защитната стена. Така напълно правилна хост-защитна стена може да стои зад безшумен отказ, който изглежда като политика, и поправката е ред в конфигурацията на ключа, а не правило.

Прочетете политиката на слоя, който отговаря

След като пътят е правилен, вървете по политиката от хоста навън и следете единствения слой, чиито броячи се движат:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

Прочетете решението на шлюза, когато тунелът свършва там

При шлюз сайт-към-сайт или отдалечен достъп VPN удостоверява потребител, а политиката разрешава ресурс и това са отделни разрешения. Потребител, допуснат в тунела, не е автоматично допуснат до всеки вътрешен хост и отказът често идва от правило за препращане, докато самият тунел е здрав. Същото разделение се появява в IPsec, където политиката за сигурност, която избира трафика, е различна от филтъра, който го допуска, и затова двете са документирани като различни механизми в RFC 4301.

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

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

Променете най-тесния слой, после проверете

Устоявайте на широкия ремонт. Изключването на хост-защитната стена, добавянето на правило, което разрешава всичко, или насилването на всеки интерфейс в доверен профил — всяко от тях премахва проверката, която си е вършила работата, и промяната надживява инцидента. Правило, ограничено до диапазона на източника и въпросния порт, е по-лесно за преглед, по-лесно за премахване и оставя останалата политика на машината непокътната.

Проверете със същия тест, който се провали, от същия клиент, а после още веднъж след повторно свързване, защото правило, което съвпада преди тунелът да преговаря наново, може да спре да съвпада след това:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Преди да затворите въпроса:

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

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