Fer umferðin virkilega í gegnum VPN? Hvernig á að staðfesta það

Tveir gallar líta eins út frá tákninu í bakkanum: umferð sem fer inn í göngin og umferð sem fer hljóðlega fram hjá þeim. Biðlarinn sýnir Connected í báðum tilvikum, því Connected þýðir aðeins að viðmót ganganna sé til og að biðlarinn hafi sett upp þær leiðir sem hann vildi. Hvort eitt pakka frá einu forriti notaði þessar leiðir er sérstök spurning sem svarað er annars staðar í staflanum. Fjórar mælingar leysa mest af því — leitin að ferlinu, fyrsta stökkið, upptaka á líkamlega millistykkinu og athugun að utan — og setu-yfirlitið á netþjóninum nær yfir restina.

Byrjaðu á ferlinu sem pakkinn fer

Leiðatöfluna er ákvörðunin, svo spurðu hana um eitt áfangastað en ekki lesa alla töfluna og giska. Á Linux nefnir ip route get viðmótið og upprunavistfangið sem kjarninn valdi:

ip route get 203.0.113.10
ip route get 10.20.5.7

Á Windows er Find-NetRoute -RemoteIPAddress 203.0.113.10 gagnlegra en route print -4 af sömu ástæðu: það tilkynnir leiðina sem vann, ekki allar leiðir sem eru til. Lestu töfluna samt einu sinni vegna 0.0.0.0-línunnar. Par af /1 þar þýðir að biðlari heilra ganga endurskrifaði sjálfgefnu leiðina: valkosturinn redirect-gateway def1 í OpenVPN setur upp 0.0.0.0/1 og 128.0.0.0/1 í gegnum göngin, sem vinnur yfir núverandi 0.0.0.0/0 við lengstu forskeytissamsvörun án þess að eyða líkamlegu sjálfgefnu leiðinni. Þess vegna geta tvær sjálfgefnar leiðir verið til samtímis á meðan allt fer samt í göngin.

Tveir smáatriðir gera töfluna að lyginni. Fyrst, skoðaðu forskeytið sem passaði en ekki fjölda sjálfgefna leiða, því viðmótsmælikvarði eða /1-par ræður sigurvegaranum. Annað, tenging sem þegar er til heldur leiðinni sem hún var stofnuð með; eftir að göngin rísa getur opin seta haldið áfram að nota gömlu leiðina þar til hún er endurstillt, og þess vegna virðist endurtenging laga leiðarvandamál. Keyrandi biðlari — ps ax | grep openvpn — sannar aðeins að ferlið byrjaði.

Fylgdu einu innra og einu opinberu nafni

Leit að ferli sýnir ætlun; leiðin sýnir afhendingu. Fylgdu nafni sem verður að vera innra og nafni sem má ekki vera það, meðan þú ert tengdur, og berðu saman fyrsta stökkið:

traceroute intranet.corp.example
traceroute 1.1.1.1

Sama fyrsta stökk fyrir bæði þýðir að innra nafnið fór aldrei í göngin og gallinn er fyrir ofan það, venjulega nafn sem leysist í opinbert vistfang eða leið sem var aldrei sett upp. Ef innri umferð fer út um 10.8.0.1 á meðan opinber umferð fer út um 192.168.1.1, þá gerir klofin göng nákvæmlega það sem þau voru stillt fyrir. Slóð sem nær VPN-hliðinu og skilar svo bara tímaneyðslum er venjulega vandamál í bakleið eða eldvegg netþjóns, ekki vantar framsendingarleið.

Síað ICMP gerir þessa athugun að lyginni: stjörnur á báðum slóðum líta út eins og dauð göng og eru venjulega eldveggur. Prófaðu TCP-port þar sem þú getur — traceroute -T -p 443 á Linux — og mundu að slóðin segir ekkert um hvaða leysir svaraði: nafn getur leyst til á staðnum og samt verið aðgengilegt í gegnum göngin.

Taktu upp á líkamlega millistykkinu, ekki á göngunum

Líkamlegu tengingin er eini staðurinn sem sýnir hvað netið sér í raun. Þegar göngin eru uppi ætti seta til skrifstofunnar að birtast sem dulkóðuð hleðsla sem beint er að VPN-netþjóninum, ekki sem tenging við 10.20.5.7:

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

Fyrsta sían grípur nafnaleysingu sem fer út á staðnum, sem er algengasta og hljóðlátasta lekið — síðan hleðst samt, leysirinn sá bara fyrirspurnina. Sú seinni grípur venjulega umferð að innra vistfangi sem ætti aðeins að vera inni í göngunum. Á Windows gerir pktmon sama verk án rekls: pktmon filter add -p 53, svo pktmon start --capture --pkt-size 128, svo pktmon stop og pktmon format pktmon.etl -o capture.txt. Þessi fánar eru örlítið mismunandi milli Windows-útgáfa, svo athugaðu pktmon filter add /? áður en þú treystir setningafræðinni.

Taktu upp líkamlega viðmótið til að finna leka; upptaka á göngunum inniheldur pakkana sem þú telur nú þegar vera þar, og á netþjóni inniheldur hún ólæsilega ytri pakka sem eiga uppruna sinn í hliðinu. Bætateljarar á hvaða viðmóti sem er lýsa pökkum, ekki forritum; að tengja umferð við ferli krefst eftirlits sem varpar sokkum á ferli.

Spurðu ytri þjónustu, og spurðu hana svo aftur fyrir hvert forrit

Eina athugunin sem sannar útgönguna er svar að utan: þjónusta sem endurómar upprunavistfangið sem hún sá. Keyrðu hana úr skel, þar sem þú getur valið viðmótið, og keyrðu hana tvisvar:

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

Mismunandi svör gefa þér sönnun fyrir báðum leiðum og leið til að prófa tiltekið forrit: binda það, eða keyra það í netnafnrými með einni leið, og sjá hvaða vistfang fjarlægi endinn skráir. Eins svör eru áhugaverði gallinn: annaðhvort virkaði bindingin ekki, eða eitthvað milli hýsisins og fjarlæga endans endurskrifar upprunavistfangið áður en það kemur. Á Windows vill curl --interface vistfang millistykkisins en ekki nafn þess.

Vafri sem tilkynnir VPN-vistfangið sannar vafrann. Póstforrit, pakkastjóri, öryggisafritunarbúnaður eða annað vafraprófíll geta hvert farið aðra leið, sérstaklega þegar proxy-stilling eða leið klofinna ganga nær yfir eina þeirra. Vistfangsbreyting er ekki sönnun leka út af fyrir sig: hleðslujafnari getur svarað öðruvísi eftir því hvaða útgang hann sá, svo berðu saman skráða upprunavistfangið, ekki síðuna.

Notaðu yfirlit netþjónsins til að staðfesta jafningjann

Netþjónninn svarar annarri spurningu: hvort jafningi sé tengdur, hversu mikið hann hefur borið og hvort setan hafi endurræst. Jafningi sem er virkur á netþjóninum á meðan teljarar biðlarans hreyfast varla þýðir að umferð forritsins fer ekki í göngin, hvað sem tafla biðlarans sagði. Jafningi sem færir mikið gagn fyrir notanda sem segir að ekkert virki er önnur rannsókn.

Hér leynast tvær gildrur. Grímuð göng láta hvert flæði líta út eins og það komi frá hliðinu, svo annálar og reikningsskil hvers biðlara falla saman á eitt vistfang. Og biðlari er meðhöndlaður sem staðbundin hýsill, svo spurningu um hvort einhver afriti skrár í gegnum VPN er svarað með skráardeilingarumferð á netþjóninum eða hýsileftirliti á netþjóninum — að fylgjast með göngunum gefur endapunkta og magn, ekki skráarnöfn.

Greindu hönnunarákvörðun frá leka

Ekki er allt utan ganganna leki. Tengil-staðbundið og dreifiumferð helst staðbundið að hönnun, prentari sem finnst með multicast heldur áfram að auglýsa sig á LAN, og DHCP verður að fara út á staðnum. Forrit sem er bundið við tiltekið viðmót fer fram hjá leiðatöflunni viljandi, og aðeins eldveggjarregla, nafnrými eða stefnuleið breytir því.

IPv6 á skilið sína eigin línu á gátlistanum. Göng sem flytja bara IPv4 skilja eftir tvístafla hýsil með aðra nothæfa leið, og tvístafla áfangastaður mun velja hana — þar á meðal DNS, ef hægt er að ná leysinum yfir IPv6. Slökktu á IPv6 á millistykkinu eða staðfestu að göngin flytji það áður en þú telur IPv4-niðurstöðu fullnægjandi.

Þegar athuganirnar eru ósammála nefnir ósamræmið venjulega gallann:

Röð sem virkar: vistaðu leiðatöfluna fyrir og eftir tengingu, fylgdu einu innra og einu opinberu nafni, taktu upp DNS á líkamlega millistykkinu, endurómaðu útgangsvistfangið úr skelinni fyrir tiltekið forrit og lestu svo netþjóninn með tilliti til magns. Ef fyrstu fjögur eru sammála flytja göngin það sem þú heldur og vandamálið sem eftir er er fyrir ofan þau. Ef tvö þeirra eru ósammála er parið sem er ósammála gallinn, ekki táknið.