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/

Пред да го затворите:

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

Поврзани статии