Защо резултатите от сканиране на портове се променят зад изход на 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 за състоянията на портовете приема това за основно: състоянието записва какво е могла да наблюдава сондата от мястото, от което е изпратена, а не свойство на порта. Четете думата за състояние по този начин и две пускания, които са се разминавали, започват да изглеждат последователни, а не противоречиви, докато въпросът се измества от това дали портът е отворен към това кой е стоял пред него.

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

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/

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

Завършете, като запишете четири факта в тикета: адрес на източника, тип сканиране, хостът, който е отговорил, и времето. Всичко, което е нужно за по-късно сравнение, живее в тези четири, и който поеме случая след вас, няма да има историята на вашия терминал. Ако не можете да попълните и четирите, пускането не е приключило.