Haluat tietää, mihin kohteisiin yhdistetty asiakas pääsee, joten avaat komentotulkin VPN-palvelimella ja kirjoitat ss. Mitään hyödyllistä ei ilmesty, ja johtopäätös rikkinäisestä tunnelista seuraa hieman liian helposti. Reitittävä OpenVPN-yhdyskäytävä välittää asiakkaan paketteja; se ei lopeta niiden TCP-yhteyksiä eikä omista niille kytkimiä. Todiste asuu muualla, ja se missä riippuu siitä, miten liikennettä käsitellään sen jälkeen kun se lähtee tunnelista.

Päätä, mitä järjestelyä katsot

Kaksi tavallista muotoa tuottavat täysin erilaiset todisteet. Reitittävä yhdyskäytävä purkaa kapseloinnin, välittää ja tekee mahdollisesti lähdeosoitteen käännöksen, joten asiakkaan yhteys jatkuu päästä päähän ilman paikallista kytkintä.

Välityspalvelin lopettaa liikenteen: se hyväksyy yhteyden ja avaa sitten oman ylävirran yhteytensä. Siinä järjestelyssä yhdelle pyynnölle on kaksi yhteyttä, ja niiden välinen yhteys on olemassa vain välityspalvelimen omissa tiedoissa. Tieto siitä, kumman näistä otit käyttöön, ratkaisee, pitäisikö sinun lukea ytimen virtaustilaa vai sovelluksen lokeja.

Suurin osa sekaannuksesta tulee arvailusta. Vahvista muoto ennen työkalun valintaa. Lue ensin palvelimen kokoonpanosta välityspalvelindirektiivi, koska sen läsnäolo muuttaa jokaista myöhempää vaihetta. Ilman sitä pakettien polku on reititys ja ytimen virtaustila on todisteesi.

Sido osoite ensin istuntoon

Aloita palvelimen istuntotilasta ja tunnista asiakkaan nykyinen sisäinen osoite. Poolin osoitteet kierrätetään, joten osoite sinänsä on vuokra, ei henkilö.

Kirjaa aika ja todennettu henkilöllisyys yhteen ja huomioi, piiloutuuko asiakkaan taakse kokonainen lähiverkko. Jos etäpää reitittää aliverkon, näkemäsi sisäiset osoitteet voivat olla alkuperäisiä isäntiä tai käännettyjä.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Tämä pari vastaa kahteen kysymykseen kerralla: mitä etuliitettä tunnelin rajapinta palvelee ja mikä istunto oli aktiivinen sinua kiinnostavalla aikavälillä. Tee tämä ennen minkään virtausmerkinnän tulkintaa, koska väärään istuntoon kiinnitetty vakuuttava monikko on pahempi kuin ei todistetta lainkaan.

Lue virtaustaulukko reitittävällä yhdyskäytävällä

Kun osoite ja aikaväli on vahvistettu, seurattujen yhteyksien vain luku -listaus näyttää, mitä yhdyskäytävä välittää sen puolesta. Suodata alkuperäisen lähteen mukaan, jotta et lue koko taulukkoa.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Jokainen merkintä sisältää kaksi monikkoa, alkuperäisen ja vastauksen, jotka ovat yhden virtauksen kaksi suuntaa eivätkä kaksi sovellusta. Lähdeosoitteen käännöspolulla alkuperäinen monikko säilyttää tunnelin osoitteen, kun taas vastauspuoli näyttää käännetyn yhdyskäytävän osoitteen, ja juuri se saa tulosteen näyttämään ensi silmäyksellä väärältä.

Käsittele listausta elävänä tilana, älä historiana. Lyhyet virtaukset ovat ehkä jo vanhentuneet, seuraamaton liikenne ei koskaan ilmesty, ja toinen verkon nimiavaruus näyttää toisen taulukon. conntrack-viite dokumentoi suodattimet ja kaksisuuntaisen tulosteen.

Yksi rajattu tallennus lukeman vahvistamiseksi

Jos tunnelin rajapinta näkyy siellä, minne katsot, yksi rajattu tallennus ratkaisee, ovatko tunnistamasi paketit ne, jotka ovat johdolla. Pidä suodatin kapeana ja pakettiraja pienenä.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Vertaa aikaleimoja, protokollaa ja portteja virtausmerkintään ja pyyntöön, jonka teit testinä. NAT:n jälkeen otettu tallennus näyttää vain yhdyskäytävän julkisen osoitteen, kun taas tunnelin puoli voi yhä näyttää asiakkaan osoitteen, ja tuo ero on tietoa, ei ristiriita.

Jos rajapinta ei näe mitään, tarkista datapolku ennen kuin päättelet asiakkaan olevan toimettomana: asiakkaiden välinen liikenne ja eräät purkupolut eivät koskaan kulje seuraamasi pisteen kautta.

Välityspalvelimen lokit ja näkemäsi rajat

Kun välityspalvelin on polulla, sen ylävirran kytkimet näkyvät kytkintaulukossa, mutta ne eivät vastaa yksi yhteen VPN-asiakkaita, erityisesti poolauksen tai multipleksoinnin kanssa. Käytä välityspalvelimen määritettyä tapahtumalokia asiakkaan identiteetin, kohteen, aikaleiman ja tallentamansa pyyntötunnisteen korreloimiseen.

Tarkista käyttöön otetun version lokituskokoonpano sen sijaan, että olettaisit jokaisen pyynnön kirjautuvan oletuksena.

Lopuksi ole tarkka laajuudesta. Kohdeosoite ja portti ovat metatietoa, eivät URL eikä sivun sisältöä, koska sisäinen HTTPS-istunto säilyttää oman suojauksensa tunnelista riippumatta. Raportoi, mitä havaitsit, mistä havaintopisteestä ja mihin aikaan.

Aiheeseen liittyvät artikkelit