Kulkeeko liikenne todella VPN:n läpi? Näin varmistat sen

Kaksi vikaa näyttävät ilmaisinalueen kuvakkeesta samoilta: liikenne, joka menee tunneliin, ja liikenne, joka kiertää sen hiljaa. Asiakas näyttää Connected molemmissa tapauksissa, koska Connected tarkoittaa vain, että tunnelin liitäntä on olemassa ja että asiakas asensi haluamansa reitit. Käyttikö yhden sovelluksen yksi paketti noita reittejä, on erillinen kysymys, johon vastataan pinon toisessa kohdassa. Neljä mittausta ratkaisee suurimman osan — reittihaku, ensimmäinen hyppy, kaappaus fyysiseltä sovittimelta ja havainto ulkoa — ja palvelimen oma istuntonäkymä kattaa loput.

Aloita reitistä, jonka paketti ottaa

Reititystaulu on päätös, joten kysy siltä yhdestä kohteesta sen sijaan että lukisit koko taulun ja arvailisit. Linuxissa ip route get nimeää liitännän ja lähdeosoitteen, jotka ydin valitsi:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windowsissa Find-NetRoute -RemoteIPAddress 203.0.113.10 on samasta syystä hyödyllisempi kuin route print -4: se ilmoittaa reitin, joka voitti, ei kaikkia olemassa olevia reittejä. Lue taulu silti kerran sen 0.0.0.0-rivin vuoksi. /1-pari siellä tarkoittaa, että täystunnelin asiakas kirjoitti oletusreitin uudelleen: OpenVPN:n redirect-gateway def1 asentaa 0.0.0.0/1 ja 128.0.0.0/1 tunnelin kautta, mikä voittaa olemassa olevan 0.0.0.0/0 pisimmän etuliitteen täsmäytyksellä poistamatta fyysistä oletusreittiä. Siksi kaksi oletusreittiä voi olla rinnakkain, kun kaikki menee silti tunneliin.

Kaksi yksityiskohtaa tekevät taulusta valehtelevan. Ensinnäkin, katso täsmännyt etuliite eikä oletusreittien määrää, koska liitännän metriikka tai /1-pari ratkaisee voittajan. Toiseksi, jo olemassa oleva yhteys säilyttää polun, jolla se muodostettiin; tunnelin noustua avoin istunto voi jatkaa vanhan reitin käyttöä, kunnes se nollataan, ja siksi uudelleenyhdistäminen näyttää korjaavan reititysongelman. Käynnissä oleva asiakas — ps ax | grep openvpn — todistaa vain, että prosessi käynnistyi.

Jäljitä yksi sisäinen ja yksi julkinen nimi

Reittihaku näyttää aikomuksen; polku näyttää toimituksen. Jäljitä nimi, jonka on oltava sisäinen, ja nimi, jonka ei pidä olla, kun olet yhteydessä, ja vertaa ensimmäistä hyppyä:

traceroute intranet.corp.example
traceroute 1.1.1.1

Sama ensimmäinen hyppy molemmille tarkoittaa, että sisäinen nimi ei koskaan tullut tunneliin ja vika on sen yläpuolella, tavallisesti nimi, joka ratkeaa julkiseksi osoitteeksi, tai reitti, jota ei koskaan asennettu. Jos sisäinen liikenne lähtee 10.8.0.1 kautta ja julkinen 192.168.1.1 kautta, jaettu tunneli tekee täsmälleen sen, mihin se määritettiin. Jälki, joka saavuttaa VPN-yhdyskäytävän ja palauttaa sitten vain aikakatkaisuja, on tavallisesti paluupolun tai palvelimen palomuurin ongelma, ei puuttuva edelleenlähetysreitti.

Suodatettu ICMP tekee tästä tarkistuksesta valehtelevan: tähdet molemmissa jäljissä näyttävät kuolleelta tunnelilta ja ovat tavallisesti palomuuri. Testaa TCP-porttia missä voit — traceroute -T -p 443 Linuxissa — ja muista, että jälki ei kerro, mikä resolveri vastasi: nimi voi ratketa paikallisesti ja olla silti saavutettavissa tunnelin kautta.

Kaappaa fyysiseltä sovittimelta, ei tunnelilta

Fyysinen linkki on ainoa paikka, joka näyttää, mitä verkko todella näkee. Tunnelin ollessa pystyssä toimistoon menevän istunnon pitäisi näkyä VPN-palvelimelle osoitettuna salattuna hyötykuormana, ei yhteytenä 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Ensimmäinen suodatin nappaa paikallisesti lähtevän nimien ratkaisun, joka on yleisin ja hiljaisin vuoto — sivu latautuu silti, resolveri vain näki kyselyn. Toinen nappaa tavallisen liikenteen sisäiseen osoitteeseen, jonka pitäisi olla olemassa vain tunnelin sisällä. Windowsissa pktmon tekee saman työn ilman ajuria: pktmon filter add -p 53, sitten pktmon start --capture --pkt-size 128, sitten pktmon stop ja pktmon format pktmon.etl -o capture.txt. Nämä liput eroavat hieman Windows-versioiden välillä, joten tarkista pktmon filter add /? ennen kuin luotat syntaksiin.

Kaappaa fyysinen liitäntä löytääksesi vuotoja; tunnelilta kaapattu sisältää ne paketit, joiden jo uskot olevan siellä, ja palvelimella se sisältää lukukelvottomia ulompia paketteja, joiden lähde on yhdyskäytävä. Minkä tahansa liitännän tavulaskurit kuvaavat paketteja, eivät ohjelmia; liikenteen kohdistaminen prosessille vaatii monitorin, joka yhdistää socketit prosesseihin.

Kysy ulkoiselta palvelulta ja kysy sitten uudelleen jokaiselta sovellukselta

Ainoa tarkistus, joka todistaa lähdön, on vastaus ulkoa: palvelu, joka kaikuu näkemänsä lähdeosoitteen. Aja se komentotulkista, jossa voit valita liitännän, ja aja se kahdesti:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Eri vastaukset antavat todisteen molemmista poluista ja tavan testata tiettyä sovellusta: sido se, tai aja se verkkonimiavaruudessa yhdellä reitillä, ja katso, minkä osoitteen kaukaisin pää tallentaa. Samanlaiset vastaukset ovat se mielenkiintoinen vika: joko sidonta ei vaikuttanut, tai jokin isäntäkoneen ja kaukaisen pään välissä kirjoittaa lähdeosoitteen uudelleen ennen saapumista. Windowsissa curl --interface haluaa sovittimen osoitteen eikä sen nimeä.

Selain, joka ilmoittaa VPN-osoitteen, todistaa selaimen. Sähköpostiohjelma, paketinhallinta, varmuuskopiointiohjelma tai toinen selainprofiili voivat kukin kulkea eri polkua, erityisesti kun välityspalvelinasetus tai jaetun tunnelin reitti kattaa yhden niistä. Osoitteen muutos ei ole sinänsä todiste vuodosta: kuormantasaaja voi vastata eri tavoin näkemänsä lähdön mukaan, joten vertaa tallennettua lähdeosoitetta, älä sivua.

Vahvista verrokki palvelimen näkymän avulla

Palvelin vastaa toiseen kysymykseen: onko verrokki yhteydessä, kuinka paljon se on välittänyt ja käynnistettiinkö istunto uudelleen. Verrokki, joka on palvelimella aktiivinen, kun asiakkaan laskurit tuskin liikkuvat, tarkoittaa, että sovelluksen liikenne ei tule tunneliin, mitä asiakkaan taulu sitten sanoikin. Verrokki, joka siirtää paljon dataa käyttäjälle, joka ilmoittaa, ettei mikään toimi, on toinen tutkimus.

Tässä väijyy kaksi ansaa. Naamioitu tunneli saa jokaisen virtauksen näyttämään yhdyskäytävästä tulevalta, joten lokit ja asiakaskohtainen kirjanpito luhistuvat yhteen osoitteeseen. Ja asiakasta kohdellaan paikallisena isäntänä, joten kysymykseen siitä, kopioiko joku tiedostoja VPN:n kautta, vastaa palvelimen tiedostonjakoliikenne tai palvelimen isäntätarkastus — tunnelin tarkkailu antaa päätepisteet ja määrän, ei tiedostonimiä.

Erottele suunnittelupäätös vuodosta

Kaikki tunnelin ulkopuolella ei ole vuotoa. Linkkipaikallinen ja lähetysliikenne pysyy suunnittelun mukaan paikallisena, multicastin kautta löydetty tulostin jatkaa ilmoittamista lähiverkossa ja DHCP:n on lähdettävä paikallisesti. Tiettyyn liitäntään sidottu sovellus ohittaa reititystaulun tarkoituksella, ja vain palomuurisääntö, nimiavaruus tai käytäntöreitti muuttaa sitä.

IPv6 ansaitsee oman rivinsä tarkistuslistalla. Tunneli, joka kuljettaa vain IPv4:tä, jättää kaksoispino-isännälle toisen käyttökelpoisen polun, ja kaksoispinokohde suosii sitä — myös DNS:n, jos resolveri on tavoitettavissa IPv6:n kautta. Poista IPv6 käytöstä sovittimelta tai varmista, että tunneli kuljettaa sitä, ennen kuin pidät IPv4-tulosta täydellisenä.

Kun tarkistukset ovat eri mieltä, erimielisyys yleensä nimeää vian:

Toimiva järjestys: tallenna reititystaulu ennen yhteyttä ja sen jälkeen, jäljitä yksi sisäinen ja yksi julkinen nimi, kaappaa DNS fyysiseltä sovittimelta, kaiu lähtöosoite komentotulkista kyseiselle sovellukselle ja lue sitten palvelin määrän osalta. Jos neljä ensimmäistä ovat yhtä mieltä, tunneli kuljettaa sitä, mitä luulet, ja jäljellä oleva ongelma on sen yläpuolella. Jos kaksi niistä on eri mieltä, erimielinen pari on vika, ei kuvake.