Zašto se rezultati skeniranja portova mijenjaju iza VPN izlaza?
Promijenite izlaz i port može odgovoriti drugačije, a da se usluga ne pomjeri. Odvojite posmatranje puta od inventara koji vam je stvarno potreban.
Pokrenite istu provjeru porta sa uredske linije i sa VPN izlaza, pa se dva odgovora mogu razići o adresi koju niko nije mijenjao. Taj jaz dolazi od rute i od toga koji je host odgovorio, a ne od toga je li usluga uključena ili isključena. Tri pitanja razdvajaju ta objašnjenja: šta je sonda zapravo pitala, koji host je na to odgovorio i šta je zabilježio vaš vlastiti server. Prođite kroz njih tim redom i zapišite svaki odgovor prije nego pređete na sljedeći.
Popravite sondu prije nego uporedite dva pokretanja
Riječ stanja uporediva je s drugom riječju stanja samo kada su obje proizašle iz istog eksperimenta. Pet polja to fiksira: izvorna adresa koju je daleka strana vidjela, razriješeno odredište, port, tip skeniranja i vrijeme. Promijenite bilo koje od njih i izveli ste drugi eksperiment umjesto da ste prvi mjerili dvaput.
Provjerite izvor prije svega ostalog, jer VPN klijent može biti uključen dok saobraćaj ipak izlazi preko fizičkog interfejsa. Pitajte daleku stranu šta vidi, a zatim pitajte kernel koji je interfejs odabrao:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dvije adrese na različitim mrežama znače da je objašnjenje već u ruci, a ostatak ovih provjera će ga samo potvrditi. Kada se slažu, snimite sondu s uključenom zastavicom razloga, da se stanje vrati vezano za objašnjenje umjesto da stoji samo kao gola riječ. Tip skeniranja takođe pripada tom zapisu, jer opisuje šta je traženo, a ne šta se vratilo. Stanje bez izvora, bez metode i bez vremenske oznake ne može se ni s čim uporediti:
nmap -sT -p 443,8443 --reason 203.0.113.20Držite taj izlaz uz zapis, a ne u baferu za skrolovanje koji sljedeća osoba ne može vidjeti. Dva poštena skeniranja koja se razilaze spor su samo kada niko nije zapisao uslove. Kad su uslovi fiksirani, ili se rezultati slažu i pitanje je zatvoreno, ili se razlikuju i razlika je činjenica o putu.
Saznajte koji je host završio rukovanje
Završeno rukovanje dokazuje da ga je neki host završio, a taj host ne mora biti proces koji imate na umu. Balanser opterećenja, obrnuti proxy ili SYN proxy mogu odgovoriti prije nego što pravi server uopšte učestvuje, što je uobičajen dizajn, a ne simptom. Važeći certifikat za očekivano ime takođe to ne sužava, jer certifikat opisuje odnos usluge i ništa ne govori o tome koja je mašina prekinula vezu.
Nmap referenca za stanja portova to smatra osnovnim: stanje bilježi šta je sonda mogla posmatrati s mjesta s kojeg je poslata, a ne svojstvo porta. Čitajte riječ stanja tako i dva pokretanja koja su se razilazila počinju izgledati dosljedno, a ne protivrječno, dok se pitanje pomjera sa toga je li port otvoren na to ko je stajao ispred njega.
Odgovorite na drugo pitanje na backendu, a ne izvana. Frontend koji prihvata veze i zatim ne uspijeva doći do svog upstreama proizvodi tačno vanjsku sliku zdrave usluge sa sporom aplikacijom. Samo vlastiti zapis upstreama razdvaja ta dva slučaja:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Linija dnevnika pokazuje adresu klijenta koju je aplikacija stvarno vidjela, a druga komanda pokazuje je li proces koji drži port 443 vaša aplikacija ili nešto ispred nje. Ako se to dvoje razilaze oko toga koja se adresa povezala, gledate dvije noge jednog zahtjeva i tiket bi to trebao reći.
Provjerite vlastita pravila prije nego okrivite tunel
Namjerna politika najčešći je razlog da port odgovara na jednoj mreži, a ne na drugoj, i najnezanimljivije je objašnjenje koje imate. Pravila pristupa postoje da dopuste jedan izvor i odbace ostale, pa je promjena izlaza upravo događaj za koji su napisana. Zato drugačije stanje kroz VPN ne pokazuje da provajder pregleda saobraćaj. Ono pokazuje da je vaša izvorna adresa sada drugačija, što je mnogo manja tvrdnja.
Ta pravila se mogu pročitati na serveru, pa ih pročitajte umjesto da nagađate o sredini mreže. Nabrojte filter pravila koja spominju bilo koji od dva raspona adresa, zatim provjerite je li veza uopšte stigla do daemona:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Prazan drugi rezultat je informativan, jer ništa nije stiglo do daemona i pitanje pripada filteru, sigurnosnoj grupi ili samom putu. Pogodak znači da je usluga vidjela vaš izvor i odabrala svoj odgovor, a ta odluka je obično zapisana u pravilu koje možete pročitati. Nijedan ishod ne podržava priču o provajderu, a oba se provjeravaju jeftinije od hvatanja paketa.
Čitajte transport, certifikat i odgovor odvojeno
Tri sloja proizvode tri posmatranja, a sonda koja testira jedno od njih ne može izvijestiti o druga dva. Držite ih kao odvojene linije u zapisu umjesto da ih savijate u jednu presudu, jer svaka linija pada na svoj način i način kvara vam govori gdje dalje gledati.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Jedna komanda proizvodi prva tri reda prema usluzi koju kontrolišete. Stavite njen izlaz u zapis uz skeniranje, a ne u chat poruku:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Čitajte izlaz redom: rukovanje odgovara na pitanje transporta, subjekat certifikata odgovara na pitanje imena, a tijelo odgovora odgovara na pitanje aplikacije. Kada linija rukovanja uspije, a linija odgovora ne, imate frontend sa slomljenim upstreamom, a ne blokiran port. To je drugačiji tiket od onog koji ste otvorili i vrijedi to reći jasno.
Završite tako što ćete u tiket zapisati četiri činjenice: izvornu adresu, tip skeniranja, host koji je odgovorio i vrijeme. Sve što kasnijem poređenju treba živi u te četiri, a ko sljedeći preuzme slučaj neće imati vašu historiju terminala. Ako ne možete popuniti sva četiri, pokretanje nije završeno.