Nmapin raakaskannaus epäonnistuu VPN:n yli, mutta -sT-yhteys toimii?
Raaka pakettiskannaus ja tavallinen TCP-yhteys tarvitsevat eri oikeudet. Aja ensin yhteystarkistus, lue jokainen valitsin kirjaimellisesti ja pysähdy sitten tulokseen.
Sivu latautuu tunnelin läpi, samalla kun porttiskannaus ilmoittaa isännän olevan alhaalla, ja ensimmäinen vaisto on, että VPN estää jotain. Yleensä se ei estä mitään uutta. Kaksi testiä pyytävät käyttöjärjestelmältä eri ominaisuuksia, ja vain toinen niistä tarvitsee raakaa pakettipääsyä. Selvitä, mikä ominaisuus petti, ennen kuin kosket tunnelia.
Erota ominaisuus tunnelista
Tavallinen sovellus pyytää ydintä avaamaan TCP-yhteyden, ja ydin suorittaa kättelyn ilman erityisoikeutta. Raakaskannaus rakentaa paketit itse, mikä vaatii alustasta riippuen raakapistokkeen tai kaappausajurin. Ne ovat lupia ja ajureita koskevia kysymyksiä, ja ne ovat olemassa riippumatta siitä, onko VPN yhdistetty.
Tämä ero selittää tavallisen epäsymmetrian. curl onnistuu, koska pistokkeen polku toimii, kun taas SYN-skannaus epäonnistuu, koska prosessi ei voi avata raakapistoketta tunnelin rajapinnalla. Se selittää myös päinvastaisen tapauksen, jossa raakaskannaus ilmoittaa suodatetuksi, koska polku pudottaa kokeen, kun taas sovelluksen polku pysyy kunnossa.
Kumpikaan tulos ei kuvaa etäpalvelua. Molemmat kuvaavat yhtä polkua yhden menetelmän alla, joten pidä menetelmä kiinni johtopäätöksessä.
Aja yhteystarkistus yhdellä hyväksytyllä isännällä
Valitse ainoa isäntä, jonka tehtäväsi kattaa, ja käytä sitten tilaa, joka ei tarvitse raakapääsyä. Esimerkin kohde tässä on 198.51.100.24, dokumentaatiotila, joka on varattu tämänlaiseen havainnollistamiseen.
Yksi rivi, yksi isäntä, yksi portti, ei löytövaihetta:
nmap -sT -Pn -p 443 --unprivileged 198.51.100.24-sT valitsee täyden TCP-yhteyden, joten se käy läpi saman ytimen polun kuin sovellus ja ei tarvitse kaappausajuria. -Pn ohittaa isäntien löytämisen; nmap tekee silti paikallisen segmentin kohteille linkkikerroksen selvityksen, joten valitsin ei ole lupaus nollasta alustavasta liikenteestä. --unprivileged kertoo nmapille, että sen tulee olettaa, ettei sillä ole raakoja tai nuuskintaoikeuksia, mikä muuttaa menetelmää eikä myönnä mitään.
Lue jokainen valitsin yhtenä muutoksena, ei korjauksena
Käsittele jokaista valintaa väitteenä menetelmästä. Mikään valitsimista -sT, -Pn tai --unprivileged ei lisää reittiä, avaa etäpalomuuria tai validoi varmennetta. Yhteysskannaus suorittaa myös oikean kättelyn, jonka palvelu kirjaa, joten hyväksytty tarkistus ja hyväksymätön läpikäynti näyttävät palvelimelta samalta paitsi laajuudeltaan ja tahdiltaan. Valintojen pinoaminen, kunnes tuloste muuttuu, on tapa, jolla menetelmäongelma kirjataan verkkohavainnoksi.
Kun tuloste sanoo suljettu, jokin vastasi nollauksella, ja se on eri havainto kuin hiljaisuus. Kun tuloste sanoo suodatettu, laite pudotti kokeen tai sen vastauksen, ja VPN voi olla sattumaa. Kirjoita täsmällinen sanamuoto muistiin, koska löytövaiheen tuomio ja kokeen tason vika osoittavat eri kerroksiin.
Jos etuoikeutettu tila on todella tarpeen, alustan omistaja päättää, tuetaanko oikeutta, ajuria ja rajapintajärjestelyä. Saman kutsun korottaminen ei muuta sen menetelmää.
Pysähdy kuljetustulokseen ja testaa sitten palvelu
Valmis kättely vastaa yhteen kysymykseen yhdestä osoitteesta, portista, lähteestä ja hetkestä. Se ei todista, että taustajärjestelmä on kunnossa, koska kuormantasaaja tai edessä oleva välityspalvelin voi hyväksyä yhteyden, kun taas sen takana oleva sovellus on alhaalla.
Jatka palvelun omalla asiakasohjelmalla, jotta TLS-identiteetti ja sovelluksen käyttäytyminen havaitaan erillisinä tosiasioina:
openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/healthVielä yksi tapa pitää tuloksen hyödyllisenä. Kirjaa tarkka komento, käytetty lähdeosoite ja aika, koska kuljetustulosta ilman tätä kontekstia ei voi toistaa eikä verrata.
Jos varmenne nimeää isännän, jota et odottanut, kuljetus toimi eikä reititys ollut koskaan ongelma; vika on virtuaalihostingissa tai DNS:ssä. Jos kättely epäonnistuu, kirjaa paikallinen virhemerkkijono sen sijaan, että yleistät tunnelista. Pidä laajuusmerkintä tuloksen vieressä, koska seuraavan henkilön on tiedettävä, mikä menetelmä sen tuotti.