Зошто резултатите од скенирање на порти се менуваат зад излез на VPN?

Стартувајте ја истата проверка на порта од канцелариска линија и од излез на VPN, и двата одговора може да не се согласат за адреса што никој не ја сменил. Таа разлика доаѓа од рутата и од тоа кој хост одговорил, а не од тоа дали услугата работи. Три прашања ги делат тие објаснувања: што всушност прашала сондата, кој хост одговорил и што запишал вашиот сопствен сервер. Поминете ги во тој редослед и запишете го секој одговор пред да преминете на следниот.

Поправете ја сондата пред да споредите две извршувања

Зборот за состојба може да се споредува со друг збор за состојба само кога двата излегле од истиот експеримент. Пет полиња го фиксираат тоа: адресата на изворот што ја видел далечниот крај, решената дестинација, портата, типот на скенирање и времето. Сменете било кое од нив и сте направиле втор експеримент наместо првиот да го измерите двапати.

Проверете го изворот пред сѐ друго, бидејќи VPN клиентот може да работи додека сообраќајот сѐ уште излегува преку физичкиот интерфејс. Прашајте го далечниот крај што гледа, потоа прашајте го јадрото кој интерфејс го избрало:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Две адреси во различни мрежи значат дека објаснувањето е веќе во рака, а останатите проверки само ќе го потврдат. Кога се совпаѓаат, снимете ја сондата со вклучено знаменце за причина, за да се врати состојбата поврзана со објаснување наместо да стои сама како гола реч. Типот на скенирање исто така припаѓа на тој запис, бидејќи опишува што е побарано, а не што се вратило. Состојба без извор, без метод и без временска ознака не може да се спореди со ништо:

nmap -sT -p 443,8443 --reason 203.0.113.20

Чувајте го тој излез до записот, а не во бафер за скролување што следниот човек не може да го види. Две чесни скенирања што не се совпаѓаат се спор само кога никој не ги запишал условите. Кога условите се фиксирани, или резултатите се совпаѓаат и прашањето е затворено, или се разликуваат и разликата е факт за патеката.

Откријте кој хост го завршил ракувањето

Завршено ракување докажува дека некој хост го завршил, и тој хост не мора да биде процесот што го имате на ум. Балансер на оптоварување, обратен прокси или SYN прокси можат да одговорат пред да учествува вистинскиот сервер, што е вообичаен дизајн, а не симптом. Важечки сертификат за очекуваното име исто така не го стеснува тоа, бидејќи сертификатот опишува однос на услуга и не кажува ништо за тоа која машина ја завршила врската.

Nmap референцата за состојби на порти го смета ова за основно: состојбата запишува што сондата можела да набљудува од местото каде што е пратена, а не својство на портата. Читајте го зборот за состојба така и две извршувања што не се совпаѓале почнуваат да изгледаат доследни наместо противречни, додека прашањето се поместува од тоа дали портата е отворена на тоа кој стоел пред неа.

Одговорете на второто прашање во бекендот, а не однадвор. Фронтенд што прифаќа врски и потоа не го достигнува својот upstream создава точно надворешна слика на здрава услуга со бавна апликација. Само сопствениот запис на upstream ги дели двата случаи:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Линијата во дневникот ја покажува клиентската адреса што апликацијата навистина ја видела, а втората команда покажува дали процесот што ја држи портата 443 е вашата апликација или нешто пред неа. Ако двете не се согласуваат за тоа која адреса се поврзала, гледате две нозе од едно барање и тикетот треба да го каже тоа.

Проверете ги сопствените правила пред да го обвините тунелот

Намерната политика е најчестата причина портата да одговара во една мрежа, а не во друга, и тоа е најнеинтересното достапно објаснување. Правилата за пристап постојат за да дозволат еден извор и да го отфрлат остатокот, така што промената на излезот е точно тој настан за кој се напишани. Затоа поинаква состојба преку VPN не покажува дека давателот го инспектира сообраќајот. Таа покажува дека вашата изворна адреса сега е поинаква, што е многу помало тврдење.

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

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

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

Читајте транспорт, сертификат и одговор одделно

Три слоја создаваат три набљудувања, и сонда што тестира едно од нив не може да извести за другите две. Чувајте ги како одделни линии во записот наместо да ги превиткате во една пресуда, бидејќи секоја линија пропаѓа на свој начин и начинот на пропаѓање ви кажува каде да гледате следно.

Една команда ги создава првите три реда против услуга што ја контролирате. Ставете го нејзиниот излез во записот до скенирањето, а не во порака за разговор:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Читајте го излезот по ред: ракувањето одговара на прашањето за транспортот, субјектот на сертификатот на прашањето за името, а телото на одговорот на прашањето за апликацијата. Кога линијата на ракувањето успева, а линијата на одговорот не, имате фронтенд со скршен upstream, а не блокирана порта. Тоа е поинаков тикет од тој што го отворивте, и вреди да се каже директно.

Завршете со запишување четири факти во тикетот: изворна адреса, тип на скенирање, хостот што одговорил и времето. Сѐ што и треба на подоцнежна споредба живее во тие четири, и кој следен ќе го преземе случајот нема да ја има историјата на вашиот терминал. Ако не можете да ги пополните сите четири, извршувањето не е завршено.