Je, trafiki inapita kweli kupitia VPN? Jinsi ya kuthibitisha

Hitilafu mbili zinaonekana sawa kutoka ikoni ya trei: trafiki inayoingia kwenye handaki na trafiki inayozunguka kwa utulivu. Mteja anaonyesha Connected katika hali zote mbili, kwa sababu Connected inamaanisha tu kwamba kiolesura cha handaki kipo na mteja amesakinisha njia alizotaka. Ikiwa kifurushi kimoja cha programu moja kilitumia njia hizo ni swali tofauti, ambalo hujibiwa mahali pengine kwenye mrundikano. Vipimo vinne hutatua sehemu kubwa — utafutaji wa njia, kuruka kwa kwanza, kunasa kwenye adapta ya kimwili na uchunguzi kutoka nje — na mwonekano wa kikao kwenye seva hufunika mengine.

Anza na njia ambayo kifurushi kitachukua

Jedwali la njia ndilo uamuzi, kwa hiyo liulize kuhusu lengo moja badala ya kusoma lote na kukisia. Kwenye Linux, ip route get hutaja kiolesura na anwani ya chanzo ambavyo kiini kilichagua:

ip route get 203.0.113.10
ip route get 10.20.5.7

Kwenye Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 ni muhimu zaidi kuliko route print -4 kwa sababu hiyo hiyo: huripoti njia iliyoshinda, si njia zote zilizopo. Hata hivyo soma jedwali mara moja kwa ajili ya mstari wake 0.0.0.0. Jozi la /1 hapo linamaanisha mteja wa handaki kamili ameandika upya njia chaguo-msingi: chaguo redirect-gateway def1 la OpenVPN husakinisha 0.0.0.0/1 na 128.0.0.0/1 kupitia handaki, ambalo hushinda 0.0.0.0/0 iliyopo kwenye ulinganifu mrefu zaidi wa kiambishi awali bila kufuta njia chaguo-msingi ya kimwili. Ndiyo sababu njia mbili chaguo-msingi zinaweza kuwa pamoja wakati kila kitu bado kinaingia kwenye handaki.

Maelezo mawili hufanya jedwali kuwa la uongo. Kwanza, angalia kiambishi awali kilicholingana na si idadi ya njia chaguo-msingi, kwa sababu metrik ya kiolesura au jozi la /1 huamua mshindi. Pili, muunganisho uliopo tayari huhifadhi njia uliyoundwa nayo; baada ya handaki kupanda, kikao kilicho wazi kinaweza kuendelea kutumia njia ya zamani hadi kiwekwe upya, na ndiyo sababu kuunganisha tena kunaonekana kurekebisha tatizo la njia. Mteja anayefanya kazi — ps ax | grep openvpn — huthibitisha tu kwamba mchakato ulianza.

Fuatilia jina moja la ndani na jina moja la umma

Utafutaji wa njia huonyesha nia; njia huonyesha uwasilishaji. Ukiwa umeunganishwa, fuatilia jina ambalo lazima liwe la ndani na jina ambalo halipaswi kuwa, na linganisha kuruka kwa kwanza:

traceroute intranet.corp.example
traceroute 1.1.1.1

Kuruka kwa kwanza sawa kwa yote mawili kunamaanisha jina la ndani halikuingia kamwe kwenye handaki na hitilafu iko juu yake, kwa kawaida jina linalotatuliwa hadi anwani ya umma au njia ambayo haikusakinishwa kamwe. Ikiwa trafiki ya ndani inatoka kupitia 10.8.0.1 wakati ya umma inatoka kupitia 192.168.1.1, handaki iliyogawanywa inafanya kwa usahihi kile ilichosanidiwa kufanya. Ufuatiliaji unaofika lango la VPN kisha hurudisha tu muda wa kumalizika kwa kawaida ni tatizo la njia ya kurudi au ukuta wa moto wa seva, si njia ya upelekaji iliyokosekana.

ICMP iliyochujwa hufanya ukaguzi huu kuwa wa uongo: nyota kwenye ufuatiliaji wote wawili huonekana kama handaki lililokufa na kwa kawaida ni ukuta wa moto. Jaribu bandari ya TCP mahali unapoweza — traceroute -T -p 443 kwenye Linux — na kumbuka ufuatiliaji hausemi ni kitatuzi kipi kilijibu: jina linaweza kutatuliwa kienyeji na bado lifikiwe kupitia handaki.

Nasa kwenye adapta ya kimwili, si kwenye handaki

Kiungo cha kimwili ni mahali pekee panapoonyesha kile mtandao unachokiona kwa kweli. Handaki ikiwa juu, kikao cha kwenda ofisini kinapaswa kuonekana kama mzigo uliosimbwa ulioelekezwa kwa seva ya VPN, si kama muunganisho wa 10.20.5.7:

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

Kichujio cha kwanza kinanasa utatuzi wa majina unaotoka kienyeji, na hiyo ni uvujaji wa kawaida zaidi na wa kimya zaidi — ukurasa bado unapakia, kitatuzi kimeona ombi tu. Cha pili kinanasa trafiki ya kawaida kwenda anwani ya ndani ambayo inapaswa kuwepo ndani ya handaki tu. Kwenye Windows, pktmon hufanya kazi hiyo hiyo bila kiendeshi: pktmon filter add -p 53, kisha pktmon start --capture --pkt-size 128, kisha pktmon stop na pktmon format pktmon.etl -o capture.txt. Bendera hizi hutofautiana kidogo kati ya matoleo ya Windows, kwa hiyo angalia pktmon filter add /? kabla ya kuamini sintaksia.

Nasa kiolesura cha kimwili ili kupata uvujaji; kunasa kwenye handaki kuna vifurushi unavyodhani tayari viko hapo, na kwenye seva kuna vifurushi vya nje visivyosomeka ambavyo chanzo chake ni lango. Vihesabu vya baiti kwenye kiolesura chochote hueleza vifurushi, si programu; ili kuhusisha trafiki na mchakato inahitajika kifuatiliaji kinachounganisha soketi na michakato.

Uliza huduma ya nje, kisha uliza tena kwa kila programu

Ukaguzi pekee unaothibitisha utokaji ni jibu kutoka nje: huduma inayorudisha anwani ya chanzo iliyoiona. Iendeshe kutoka shell, ambapo unaweza kuchagua kiolesura, na iendeshe mara mbili:

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

Majibu tofauti hukupa uthibitisho wa njia zote mbili na njia ya kujaribu programu mahususi: ifunge, au iendeshe katika nafasi ya jina la mtandao yenye njia moja, na uone ni anwani gani mwisho wa mbali unasajili. Majibu yanayofanana ndiyo hitilafu ya kuvutia: ama ufungaji haukufanya kazi, au kitu kati ya mwenyeji na mwisho wa mbali kinaandika upya anwani ya chanzo kabla ya kufika. Kwenye Windows, curl --interface inataka anwani ya adapta si jina lake.

Kivinjari kinachoripoti anwani ya VPN huthibitisha kivinjari. Mteja wa barua pepe, msimamizi wa vifurushi, wakala wa nakala rudufu au profaili ya pili ya kivinjari kila mmoja anaweza kuchukua njia tofauti, hasa wakati mipangilio ya proksi au njia ya handaki iliyogawanywa inafunika mmoja wao. Mabadiliko ya anwani si uthibitisho wa uvujaji wenyewe: kipatanishi cha mzigo kinaweza kujibu tofauti kulingana na utokaji uliouona, kwa hiyo linganisha anwani ya chanzo iliyosajiliwa, si ukurasa.

Tumia mwonekano wa seva kuthibitisha rika

Seva hujibu swali lingine: ikiwa rika ameunganishwa, kiasi gani amebeba na ikiwa kikao kilianza upya. Rika aliye hai kwenye seva wakati vihesabu vya mteja karibu havijasogea inamaanisha trafiki ya programu haiingii kwenye handaki, chochote kile jedwali la mteja lililosema. Na rika anayesogeza data nyingi kwa mtumiaji anayeripoti kuwa hakuna kinachofanya kazi ni uchunguzi mwingine.

Hapa kuna mitego miwili. Handaki iliyofichwa hufanya kila mtiririko uonekane kama unatoka kwenye lango, kwa hiyo kumbukumbu na uhasibu kwa kila mteja huanguka kwenye anwani moja. Na mteja huchukuliwa kama mwenyeji wa kienyeji, kwa hiyo swali la kama mtu ananakili faili kupitia VPN hujibiwa na trafiki ya kushiriki faili kwenye seva au ukaguzi wa mwenyeji kwenye seva — kuchunguza handaki hutoa vituo na kiasi, si majina ya faili.

Tofautisha uamuzi wa muundo na uvujaji

Si kila kitu nje ya handaki ni uvujaji. Trafiki ya kiungo cha kienyeji na utangazaji hubaki ya kienyeji kwa muundo, printa inayopatikana kwa multicast huendelea kutangaza kwenye LAN, na DHCP lazima itoke kienyeji. Programu iliyofungwa kwa kiolesura mahususi hupita jedwali la njia kwa makusudi, na ni sheria ya ukuta wa moto, nafasi ya jina au njia ya sera pekee inayobadilisha hilo.

IPv6 inastahili mstari wake kwenye orodha ya ukaguzi. Handaki inayobeba IPv4 pekee huiachia mwenyeji wa stakki mbili njia ya pili inayoweza kutumika, na lengo la stakki mbili litaipendelea — ikiwa ni pamoja na DNS, ikiwa kitatuzi kinafikiwa kwa IPv6. Zima IPv6 kwenye adapta au thibitisha kwamba handaki inaibeba kabla ya kuchukua matokeo ya IPv4 kama kamili.

Wakati ukaguzi haukubaliani, kutokubaliana kwa kawaida hutaja hitilafu:

Mpangilio unaofanya kazi: hifadhi jedwali la njia kabla na baada ya kuunganisha, fuatilia jina moja la ndani na moja la umma, nasa DNS kwenye adapta ya kimwili, rudisha anwani ya utokaji kutoka shell kwa programu mahususi, kisha soma seva kwa kiasi. Ikiwa nne za kwanza zinakubaliana, handaki inabeba unachofikiri na tatizo lililobaki liko juu yake. Ikiwa mbili hazikubaliani, jozi isiyokubaliana ndiyo hitilafu, si ikoni.