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/

Пре него што затворите:

  • Путања до одредишта излази кроз интерфејс тунела, а изворна адреса се поклапа с оним што политика очекује.
  • Нешто слуша на порту, а одбијање или истек времена приписује се именованом правилу, а не претпоставци.
  • Пролаз прослеђује у оба смера, а одредиште види извор за који су написана ваша правила.
  • Ниједна контрола није искључена да би тест прошао, а промена коју сте направили именује један изворни опсег и један порт.

Повезани чланци