Покрените исту проверу порта са канцеларијске линије и са излаза 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

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

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

Три слоја производе три посматрања, а сонда која тестира једно од њих не може известити о друга два. Држите их као одвојене линије у запису уместо да их савијате у једну пресуду, јер свака линија пада на свој начин и начин квара вам говори где даље да гледате.

ObservationWhat it settlesWhat it leaves open
Connection completedA host on the path accepted the handshakeWhich host, and whether its upstream is reachable
Certificate valid for the nameThe endpoint holds a credential for that nameWhether the process behind it is the one you meant
Expected response bodyThe application handled the requestAnything about other ports or other paths
Connection refusedA host replied and nothing was listeningWhether a filter sits ahead of the refused port
TimeoutNo reply arrived before the deadlineDrop, blackhole route or an overloaded host

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

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

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

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

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