Kodėl portų skenavimo rezultatai keičiasi už VPN išėjimo?

Paleiskite tą pačią prievado patikrą iš biuro linijos ir iš VPN išėjimo, ir du atsakymai gali nesutarti dėl adreso, kurio niekas nepakeitė. Šis skirtumas kyla iš maršruto ir iš to, kuris hostas atsakė, o ne iš to, ar paslauga veikia. Trys klausimai atskiria tuos paaiškinimus: ką zondas iš tikrųjų paklausė, kuris hostas atsakė ir ką užrašė jūsų serveris. Pereikite juos ta tvarka ir užrašykite kiekvieną atsakymą prieš pereidami prie kito.

Pataisykite zondą prieš lygindami du paleidimus

Būsenos žodį galima lyginti su kitu būsenos žodžiu tik tada, kai abu kilo iš to paties eksperimento. Penki laukai tai užfiksuoja: šaltinio adresas, kurį matė tolimoji pusė, išspręstas tikslas, prievadas, skenavimo tipas ir laikas. Pakeiskite bet kurį jų ir atlikote antrą eksperimentą, o ne pirmąjį pamatavote du kartus.

Pirmiausia patikrinkite šaltinį, nes VPN klientas gali būti įjungtas, o srautas vis dar išeina per fizinį sąsają. Paklauskite tolimosios pusės, ką ji mato, tada paklauskite branduolio, kurią sąsają jis pasirinko:

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

Du skirtingų tinklų adresai reiškia, kad paaiškinimas jau rankoje, o likusios patikros jį tik patvirtins. Kai jie sutampa, užfiksuokite zondą su įjungta priežasties vėliavėle, kad būsena grįžtų susieta su paaiškinimu, o ne stovėtų viena kaip nuogas žodis. Skenavimo tipas taip pat priklauso tam įrašui, nes jis aprašo, ko buvo klausiama, o ne kas grįžo. Būsena be šaltinio, be metodo ir be laiko žymos negali būti su niekuo lyginama:

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

Laikykite tą išvestį šalia įrašo, o ne slinkimo buferyje, kurio kitas žmogus negali pamatyti. Du sąžiningi skenavimai, kurie nesutampa, yra ginčas tik tada, kai niekas neužrašė sąlygų. Kai sąlygos užfiksuotos, arba rezultatai sutampa ir klausimas uždarytas, arba jie skiriasi ir skirtumas yra faktas apie maršrutą.

Išsiaiškinkite, kuris hostas baigė rankos paspaudimą

Baigtas rankos paspaudimas įrodo, kad jį baigė koks nors hostas, ir tas hostas nebūtinai yra procesas, kurį turite omenyje. Apkrovos balansuotojas, atvirkštinis tarpinis serveris ar SYN tarpinis serveris gali atsakyti prieš įsitraukiant tikrajam serveriui, o tai įprastas dizainas, ne simptomas. Galiojantis numatomo vardo sertifikatas taip pat to nesusiaurina, nes sertifikatas aprašo paslaugos santykį ir nieko nesako apie tai, kuri mašina užbaigė ryšį.

Nmap prievadų būsenų žinynas laiko tai pagrindiniu dalyku: būsena užrašo, ką zondas galėjo stebėti iš siuntimo vietos, o ne prievado savybę. Skaitykite būsenos žodį taip ir du paleidimai, kurie nesutarė, pradeda atrodyti nuoseklūs, o ne prieštaringi, o klausimas persikelia nuo to, ar prievadas atidarytas, prie to, kas stovėjo priešais jį.

Atsakykite į antrą klausimą backend'e, o ne iš išorės. Frontend'as, kuris priima ryšius ir po to nepasiekia savo upstream'o, sukuria tiksliai sveikos paslaugos su lėta programa išorinį vaizdą. Tik paties upstream'o įrašas atskiria du atvejus:

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

Žurnalo eilutė rodo kliento adresą, kurį programa iš tikrųjų matė, o antroji komanda rodo, ar procesas, laikantis 443 prievadą, yra jūsų programa, ar kažkas priešais ją. Jei tie du nesutaria dėl to, kuris adresas prisijungė, jūs žiūrite į dvi vienos užklausos kojas ir bilietas turėtų tai pasakyti.

Patikrinkite savo taisykles prieš kaltindami tunelį

Sąmoninga politika yra dažniausia priežastis, kodėl prievadas atsako viename tinkle, o kitame ne, ir tai yra mažiausiai įdomus galimas paaiškinimas. Prieigos taisyklės egzistuoja tam, kad leistų vieną šaltinį ir atmestų kitus, todėl išėjimo pasikeitimas yra būtent tas įvykis, kuriam jos buvo parašytos. Todėl kitokia būsena per VPN neparodo, kad teikėjas tikrina srautą. Ji parodo, kad jūsų šaltinio adresas dabar kitas, ir tai yra daug mažesnis teiginys.

Tas taisykles galima perskaityti serveryje, todėl perskaitykite jas, o ne spėliokite apie tinklo vidurį. Išvardykite filtro taisykles, kuriose minimas kuris nors iš dviejų adresų diapazonų, tada patikrinkite, ar ryšys apskritai pasiekė demoną:

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

Tuščias antrasis rezultatas yra informatyvus, nes niekas nepasiekė demono, o klausimas priklauso filtrui, saugos grupei ar pačiam maršrutui. Pataikymas reiškia, kad paslauga matė jūsų šaltinį ir pasirinko savo atsakymą, ir tas sprendimas paprastai užrašytas taisyklėje, kurią galite perskaityti. Nė vienas rezultatas neremia istorijos apie teikėją, ir abu pigiau patikrinti nei užfiksuoti paketus.

Skaitykite transportą, sertifikatą ir atsakymą atskirai

Trys sluoksniai sukuria tris stebėjimus, o zondas, kuris tikrina vieną jų, negali pranešti apie kitus du. Laikykite juos atskiromis eilutėmis įraše, o ne sulenkite į vieną nuosprendį, nes kiekviena eilutė nepavyksta savaip, o gedimo būdas pasako, kur žiūrėti toliau.

Viena komanda sukuria pirmas tris eilutes prieš jūsų valdomą paslaugą. Padėkite jos išvestį į įrašą šalia skenavimo, o ne į pokalbio žinutę:

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

Skaitykite išvestį iš eilės: rankos paspaudimas atsako į transporto klausimą, sertifikato subjektas – į vardo klausimą, o atsakymo turinys – į programos klausimą. Kai rankos paspaudimo eilutė pavyksta, o atsakymo eilutė ne, turite frontend'ą su sugedusiu upstream'u, o ne užblokuotą prievadą. Tai kitas bilietas nei tas, kurį atidarėte, ir verta tai pasakyti tiesiai.

Užbaikite įrašydami į bilietą keturis faktus: šaltinio adresą, skenavimo tipą, hostą, kuris atsakė, ir laiką. Viskas, ko reikia vėlesniam palyginimui, gyvena tuose keturiuose, o kas perims bylą toliau, neturės jūsų terminalo istorijos. Jei negalite užpildyti visų keturių, paleidimas nebaigtas.