Чаму вынікі сканавання порта змяняюцца за выхадам 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/

Чытайце вывад па парадку: рукапацісканне адказвае на пытанне транспарту, суб’ект сертыфіката — на пытанне імені, а цела адказу — на пытанне праграмы. Калі радок рукапаціскання паспяховы, а радок адказу не, у вас фронтэнд са зламаным верхнім серверам, а не заблакаваны порт. Гэта іншая заяўка, чым тая, якую вы адкрылі, і пра гэта варта сказаць проста.

Скончыце тым, што запішаце ў заяўку чатыры факты: адрас крыніцы, тып сканавання, хост, які адказаў, і час. Усё, што патрэбна для пазнейшага параўнання, жыве ў гэтых чатырох, і той, хто возьме справу далей, не будзе мець вашай гісторыі тэрмінала. Калі вы не можаце запоўніць усе чатыры, запуск не скончаны.