Miksi porttiskannauksen tulokset muuttuvat VPN-poistumissolmun takana?

Aja sama porttitarkistus toimistolinjalta ja VPN-poistumissolmusta, niin kaksi vastausta voivat olla eri mieltä osoitteesta, jota kukaan ei muuttanut. Tämä ero tulee reitistä ja siitä, mikä isäntä vastasi, ei siitä, onko palvelu käynnissä. Kolme kysymystä erottavat nämä selitykset: mitä anturi itse asiassa kysyi, mikä isäntä vastasi siihen ja mitä oma palvelimesi kirjasi. Käy ne läpi tässä järjestyksessä ja kirjoita jokainen vastaus ennen seuraavaan siirtymistä.

Korjaa anturi ennen kuin vertailet kahta ajoa

Tilasanata on vertailukelpoinen toisen tilasanan kanssa vain, kun molemmat ovat peräisin samasta kokeesta. Viisi kenttää kiinnittää sen: lähdeosoite, jonka kaukopää näki, ratkaistu kohde, portti, skannaustyyppi ja aika. Muuta mitä tahansa niistä, niin olet tehnyt toisen kokeen sen sijaan, että olisit mitannut ensimmäisen kahdesti.

Tarkista lähde ennen kaikkea muuta, koska VPN-asiakas voi olla käynnissä, vaikka liikenne lähtee yhä fyysisen liitännän kautta. Kysy kaukopäältä, mitä se näkee, ja kysy sitten ytimeltä, minkä liitännän se valitsi:

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

Kaksi osoitetta eri verkoissa tarkoittaa, että selitys on jo käsissä, ja loput näistä tarkistuksista vain vahvistavat sen. Kun ne täsmäävät, tallenna anturi syylipukeilla varustettuna, jotta tila palaa selitykseen sidottuna eikä seiso yksin paljaana sanana. Skannaustyyppi kuuluu myös siihen tallenteeseen, koska se kuvaa sitä, mitä kysyttiin, ei sitä, mitä tuli takaisin. Tilaa ilman lähdettä, menetelmää ja aikaleimaa ei voi verrata mihinkään:

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

Pidä tuo tuloste tallenteen vieressä äläkä vierityspuskurissa, jota seuraava ihminen ei näe. Kaksi rehellistä skannausta, jotka ovat eri mieltä, ovat väittely vain silloin, kun kukaan ei kirjoittanut ehtoja muistiin. Kun ehdot on kiinnitetty, joko tulokset täsmäävät ja kysymys on suljettu, tai ne eroavat ja ero on tosiasia reitistä.

Selvitä, mikä isäntä päätti kättelyn

Päätetty kättely todistaa, että jokin isäntä päätti sen, eikä sen isännän tarvitse olla se prosessi, joka sinulla on mielessä. Kuormantasaaja, käänteinen välityspalvelin tai SYN-välityspalvelin voivat vastata ennen kuin varsinainen palvelin osallistuu, mikä on tavallista suunnittelua eikä oire. Voimassa oleva varmenne odotetulle nimelle ei myöskään rajaa tätä, koska varmenne kuvaa palvelusuhdetta eikä kerro mitään siitä, mikä kone päätti yhteyden.

Nmapin porttitilojen viite pitää tätä perusasiana: tila kirjaa sen, mitä anturi saattoi havaita lähetyspaikastaan, ei portin ominaisuutta. Lue tilasanaa näin, niin kaksi erimielistä ajoa alkavat näyttää johdonmukaisilta eivätkä ristiriitaisilta, samalla kun kysymys siirtyy siitä, onko portti auki, siihen, kuka sen edessä seisoi.

Vastaa toiseen kysymykseen backendissa äläkä ulkopuolelta. Etupää, joka ottaa yhteyksiä vastaan ja jää sitten saavuttamatta ylävirtaansa, tuottaa täsmälleen terveen palvelun ulkoisen kuvan hitaalla sovelluksella. Vain ylävirran oma tallenne erottaa kaksi tapausta:

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

Lokirivi näyttää asiakasosoitteen, jonka sovellus todella näki, ja toinen komento näyttää, onko porttia 443 pitävä prosessi sinun sovelluksesi vai jotain sen edessä. Jos ne kaksi ovat eri mieltä siitä, mikä osoite yhdisti, katsot yhden pyynnön kahta jalkaa ja tiketin pitäisi sanoa niin.

Tarkista omat sääntösi ennen kuin syytät tunnelia

Tarkoituksellinen käytäntö on yleisin syy siihen, että portti vastaa yhdessä verkossa eikä toisessa, ja se on vähiten kiinnostava saatavilla oleva selitys. Pääsykäytännöt ovat olemassa, jotta yksi lähde sallitaan ja loput pudotetaan, joten poistumisen muutos on täsmälleen se tapahtuma, jota varten ne kirjoitettiin. Siksi erilainen tila VPN:n kautta ei osoita, että palveluntarjoaja tarkastaa liikennettä. Se osoittaa, että lähdeosoitteesi on nyt erilainen, mikä on paljon pienempi väite.

Nuo säännöt voi lukea palvelimelta, joten lue ne sen sijaan, että spekuloit verkon keskiosaa. Listaa suodatinsäännöt, jotka mainitsevat jommankumman osoitealueen, ja tarkista sitten, pääsikö yhteys lainkaan daemonille:

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

Tyhjä toinen tulos on valaiseva, koska mikään ei päässyt daemonille ja kysymys kuuluu suodattimelle, suojausryhmälle tai itse reitille. Osuma tarkoittaa, että palvelu näki lähteesi ja valitsi vastauksensa, ja se päätös on yleensä kirjoitettu sääntöön, jonka voit lukea. Kumpikaan tulos ei tue tarinaa palveluntarjoajasta, ja molemmat on halvempi tarkistaa kuin paketin sieppaus.

Lue kuljetus, varmenne ja vastaus erikseen

Kolme kerrosta tuottaa kolme havaintoa, eikä anturi, joka testaa yhtä niistä, voi raportoida kahdesta muusta. Pidä ne erillisinä riveinä tallenteessa sen sijaan, että taitat ne yhdeksi tuomioksi, koska jokainen rivi epäonnistuu omalla tavallaan ja epäonnistumisen tapa kertoo, minne seuraavaksi katsoa.

Yksi komento tuottaa kolme ensimmäistä riviä palvelua vastaan, jota hallitset. Laita sen tuloste tallenteeseen skannauksen viereen äläkä chatviestiin:

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

Lue tuloste järjestyksessä: kättely vastaa kuljetuskysymykseen, varmenteen kohde vastaa nimikysymykseen ja vastauksen runko vastaa sovelluskysymykseen. Kun kättelyrivi onnistuu ja vastausrivi ei, sinulla on etupää, jonka ylävirta on rikki, ei estetty portti. Se on eri tiketti kuin avaamasi, ja se kannattaa sanoa selvästi.

Lopeta kirjoittamalla tikettiin neljä tosiasiaa: lähdeosoite, skannaustyyppi, vastannut isäntä ja aika. Kaikki, mitä myöhempi vertailu tarvitsee, elää noissa neljässä, eikä seuraava tapauksen ottaja saa päätelaitteesi historiaa. Jos et pysty täyttämään kaikkia neljää, ajo ei ole valmis.