Waarom verander poortskandering se resultate agter ’n VPN-uitgang?
Verander die uitgang en ’n poort kan anders antwoord sonder dat die diens beweeg. Skei die waarneming van die pad van die inventaris wat jy werklik nodig het.
Voer dieselfde poortkontrole uit vanaf ’n kantoorlyn en vanaf ’n VPN-uitgang, en die twee antwoorde kan verskil oor ’n adres wat niemand verander het nie. Daardie gaping kom van die roete en van watter gasheer geantwoord het, nie van die diens wat op of af is nie. Drie vrae skei daardie verklarings: wat die probe werklik gevra het, watter gasheer dit beantwoord het, en wat jou eie bediener aangeteken het. Werk dit in daardie volgorde deur en skryf elke antwoord neer voordat jy na die volgende een beweeg.
Maak die probe reg voordat jy twee lopies vergelyk
’n Toestandwoord is net vergelykbaar met ’n ander toestandwoord wanneer albei uit dieselfde eksperiment gekom het. Vyf velde pen een vas: die bronadres wat die ander kant gesien het, die opgeloste bestemming, die poort, die skanderingstipe en die tyd. Verander enigeen daarvan en jy het ’n tweede eksperiment gedoen eerder as om die eerste een twee keer te meet.
Kontroleer die bron voor enigiets anders, want ’n VPN-kliënt kan op wees terwyl verkeer steeds oor die fisiese koppelvlak vertrek. Vra die ander kant wat hy sien, en vra dan die kernel watter koppelvlak hy gekies het:
curl -s https://ifconfig.me
ip route get 203.0.113.20Twee adresse op verskillende netwerke beteken die verklaring is reeds in die hand, en die res van hierdie kontroles sal dit net bevestig. Wanneer hulle ooreenstem, vang die probe met die rede-vlag aan, sodat die toestand terugkom gekoppel aan ’n verklaring eerder as om alleen as ’n blote woord te staan. Die skanderingstipe hoort ook in daardie rekord, want dit beskryf wat gevra is eerder as wat teruggekom het. ’n Toestand sonder bron, sonder metode en sonder tydstempel kan met niks vergelyk word nie:
nmap -sT -p 443,8443 --reason 203.0.113.20Hou daardie uitset langs die rekord eerder as in ’n terugrolbuffer wat die volgende persoon nie kan sien nie. Twee eerlike skanderings wat verskil, is net ’n argument wanneer niemand die voorwaardes neergeskryf het nie. Met die voorwaardes vasgestel, stem die resultate óf ooreen en die vraag is gesluit, óf hulle verskil en die verskil is ’n feit oor die pad.
Vind uit watter gasheer die handskud voltooi het
’n Voltooide handskud bewys dat een of ander gasheer dit voltooi het, en daardie gasheer hoef nie die proses te wees wat jy in gedagte het nie. ’n Lasbalanseerder, ’n omgekeerde instaanbediener of ’n SYN-instaanbediener kan antwoord voordat die werklike bediener betrokke is, wat gewone ontwerp is eerder as ’n simptoom. ’n Geldige sertifikaat vir die verwagte naam vernou dit ook nie, want ’n sertifikaat beskryf ’n diensverhouding en sê niks oor watter masjien die verbinding beëindig het nie.
Die Nmap-verwysing vir poorttoestande beskou dit as basies: ’n toestand teken aan wat ’n probe vanaf sy stuurpunt kon waarneem, nie ’n eienskap van die poort nie. Lees ’n toestandwoord so en twee lopies wat verskil het, begin konsekwent eerder as teenstrydig lyk, terwyl die vraag verskuif van of die poort oop is na wie voor hom gestaan het.
Beantwoord die tweede vraag by die agterkant eerder as van buite. ’n Voorkant wat verbindings aanvaar en dan nie sy opstroom kan bereik nie, lewer presies die uiterlike beeld van ’n gesonde diens met ’n stadige toepassing. Net die opstroom se eie rekord skei die twee gevalle:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Die logreël wys die kliëntadres wat die toepassing werklik gesien het, en die tweede opdrag wys of die proses wat poort 443 hou jou toepassing is of iets voor hom. As daardie twee verskil oor watter adres gekoppel het, kyk jy na twee bene van een versoek en die kaartjie behoort dit te sê.
Kontroleer jou eie reëls voordat jy die tonnel blameer
Doelbewuste beleid is die algemeenste rede waarom ’n poort op een netwerk antwoord en op ’n ander nie, en dit is die minste interessante verklaring wat beskikbaar is. Toegangsreëls bestaan om een bron toe te laat en die res te laat val, so ’n verandering van uitgang is juis die gebeurtenis waarvoor hulle geskryf is. ’n Ander toestand deur ’n VPN wys dus nie dat die verskaffer verkeer ondersoek nie. Dit wys dat jou bronadres nou anders is, wat ’n veel kleiner bewering is.
Daardie reëls is op die bediener leesbaar, so lees hulle eerder as om oor die middel van die netwerk te spekuleer. Lys die filterreëls wat enigeen van die adresreekse noem, en kyk dan of die verbinding die daemon enigsins bereik het:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113’n Leë tweede resultaat is insiggewend, want niks het die daemon bereik nie en die vraag hoort by ’n filter, ’n sekuriteitsgroep of die pad self. ’n Treffer beteken die diens het jou bron gesien en sy antwoord gekies, en daardie besluit staan gewoonlik in ’n reël wat jy kan lees. Nie een van die uitkomste ondersteun ’n verhaal oor die verskaffer nie, en albei is goedkoper om na te gaan as ’n pakkie-opname.
Lees vervoer, sertifikaat en antwoord afsonderlik
Drie lae lewer drie waarnemings, en ’n probe wat een daarvan toets, kan nie oor die ander twee verslag doen nie. Hou hulle as afsonderlike lyne in die rekord eerder as om hulle in ’n enkele uitspraak saam te vou, want elke lyn faal op sy eie manier en die foutmodus sê jou waar om volgende te kyk.
| 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 |
Een opdrag lewer die eerste drie rye teen ’n diens wat jy beheer. Sit sy uitset in die rekord langs die skandering eerder as in ’n kletsboodskap:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lees die uitset in volgorde: die handskud beantwoord die vervoervraag, die sertifikaatonderwerp beantwoord die naamvraag, en die antwoordliggaam beantwoord die toepassingsvraag. Wanneer die handskudreël slaag en die antwoordreël nie, het jy ’n voorkant met ’n gebroke opstroom eerder as ’n geblokkeerde poort. Dit is ’n ander kaartjie as die een wat jy oopgemaak het, en dit is die moeite werd om dit duidelik te sê.
Sluit af deur vier feite in die kaartjie te skryf: bronadres, skanderingstipe, die gasheer wat geantwoord het, en die tyd. Alles wat ’n latere vergelyking nodig het, leef in daardie vier, en wie die saak volgende optel, sal nie jou terminaalgeskiedenis hê nie. As jy nie al vier kan invul nie, is die lopie nie klaar nie.