Արդյո՞ք տրաֆիկն իրոք անցնում է VPN-ով։ Ինչպես դա ստուգել
Երթուղու որոնումը, առաջին ցատկը, ֆիզիկական ադապտերի վրա գրառումը և դրսից հասցեի ստուգումը պատասխանում են հարցի տարբեր մասերին։
Երկու խափանում համակարգի սկուտեղի պատկերակից նույն տեսքն ունեն՝ թունել մտնող տրաֆիկը և դրա շուրջը լուռ անցնող տրաֆիկը։ Հաճախորդը երկու դեպքում էլ ցույց է տալիս Connected, քանի որ Connected-ը միայն նշանակում է, որ թունելի ինտերֆեյսը գոյություն ունի, և հաճախորդը տեղադրել է իր ուզած երթուղիները։ Արդյոք մեկ ծրագրի մեկ փաթեթը օգտագործել է այդ երթուղիները, առանձին հարց է, որին պատասխանում են ստեկի այլ տեղում։ Չորս չափումներ լուծում են դրա մեծ մասը՝ երթուղու որոնումը, առաջին ցատկը, ֆիզիկական ադապտերի վրա գրառումը և դրսից դիտարկումը, իսկ սերվերի սեփական նստաշրջանի տեսքը ծածկում է մնացածը։
Սկսեք այն երթուղուց, որը կվերցնի փաթեթը
Երթուղային աղյուսակը որոշումն է, ուստի հարցրեք նրան մեկ նպատակակետի մասին, փոխարենը ամբողջը կարդալու և գուշակելու: Linux-ում ip route get նշում է ինտերֆեյսը և աղբյուրի հասցեն, որոնք ընտրել է միջուկը։
ip route get 203.0.113.10
ip route get 10.20.5.7Windows-ում Find-NetRoute -RemoteIPAddress 203.0.113.10 ավելի օգտակար է, քան route print -4, նույն պատճառով՝ այն հաղորդում է հաղթած երթուղին, ոչ բոլոր գոյություն ունեցողները։ Միևնույն է, մեկ անգամ կարդացեք աղյուսակը իր 0.0.0.0 տողի համար։ Այնտեղ /1 զույգը նշանակում է, որ լրիվ թունելի հաճախորդը վերաշարադրել է լռելյայն երթուղին՝ OpenVPN-ի redirect-gateway def1 ընտրանքը թունելի միջով տեղադրում է 0.0.0.0/1 և 128.0.0.0/1, ինչը ամենաերկար նախածանցի համընկնմամբ հաղթում է գոյություն ունեցող 0.0.0.0/0-ին՝ չջնջելով ֆիզիկական լռելյայն երթուղին։ Այդ պատճառով երկու լռելյայն երթուղի կարող են գոյակցել, մինչ ամեն ինչ դեռ մտնում է թունել։
Երկու մանրամասն աղյուսակին ստախոս են դարձնում։ Առաջին՝ նայեք համընկած նախածանցին, ոչ լռելյայն երթուղիների քանակին, որովհետև հաղթողին որոշում են ինտերֆեյսի մետրիկան կամ /1 զույգը։ Երկրորդ՝ արդեն գոյություն ունեցող կապը պահպանում է այն ուղին, որով հաստատվել է, թունելը բարձրանալուց հետո բաց նստաշրջանը կարող է շարունակել օգտագործել հին երթուղին մինչև այն վերակայվի, և դրա համար է, որ վերամիացումը կարծես լուծում է երթուղավորման խնդիրը։ Աշխատող հաճախորդը՝ ps ax | grep openvpn, ապացուցում է միայն, որ գործընթացը մեկնարկել է։
Հետևեք մեկ ներքին և մեկ հանրային անվան
Երթուղու որոնումը ցույց է տալիս մտադրությունը, ուղին՝ առաքումը։ Միացած վիճակում հետևեք անվան, որը պետք է լինի ներքին, և անվան, որը չպետք է լինի, և համեմատեք առաջին ցատկը:
traceroute intranet.corp.example
traceroute 1.1.1.1Երկուսի համար նույն առաջին ցատկը նշանակում է, որ ներքին անունը երբեք չի մտել թունել, և խափանումը դրա վերևում է՝ սովորաբար հանրային հասցեի լուծվող անուն կամ երբեք չտեղադրված երթուղի։ Եթե ներքին տրաֆիկը դուրս է գալիս 10.8.0.1-ով, մինչ հանրայինը դուրս է գալիս 192.168.1.1-ով, ապա բաժանված թունելը անում է հենց այն, ինչի համար կարգավորվել է։ Այն հետքը, որը հասնում է VPN դարպասին և հետո վերադարձնում է միայն ժամանակի սպառումներ, սովորաբար վերադարձի ուղու կամ սերվերի հրային պատի խնդիր է, ոչ բացակայող փոխանցման երթուղի։
Զտված ICMP-ն այս ստուգումը ստախոս է դարձնում՝ աստղիկները երկու հետքերում մեռած թունելի տեսք ունեն և սովորաբար հրային պատ են։ Փորձեք TCP պորտ, որտեղ կարող եք՝ traceroute -T -p 443 Linux-ում, և հիշեք, որ հետքը չի ասում, թե որ լուծիչը պատասխանեց՝ անունը կարող է լուծվել տեղային և այնուամենայնիվ հասանելի լինել թունելով։
Գրառում արեք ֆիզիկական ադապտերի վրա, ոչ թունելի վրա
Ֆիզիկական կապը միակ տեղն է, որը ցույց է տալիս, թե ցանցն իրականում ինչ է տեսնում։ Թունելը բարձրացված վիճակում գրասենյակ գնացող նստաշրջանը պետք է երևա որպես VPN սերվերին հասցեագրված գաղտնագրված բեռ, այլ ոչ որպես կապ դեպի 10.20.5.7:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5Առաջին զտիչը բռնում է տեղային դուրս եկող անվան լուծումը, որը ամենատարածված և ամենալուռ արտահոսքն է՝ էջը դեռ բեռնվում է, լուծիչը պարզապես տեսել է հարցումը։ Երկրորդը բռնում է ներքին հասցեին ուղղված սովորական տրաֆիկը, որը պետք է գոյություն ունենա միայն թունելի ներսում։ Windows-ում pktmon նույն աշխատանքն է կատարում առանց վարորդի՝ pktmon filter add -p 53, հետո pktmon start --capture --pkt-size 128, հետո pktmon stop և pktmon format pktmon.etl -o capture.txt։ Այդ դրոշները փոքր-ինչ տարբերվում են Windows տարբերակների միջև, ուստի ստուգեք pktmon filter add /?-ը նախքան շարահյուսությանը վստահելը։
Գրառեք ֆիզիկական ինտերֆեյսը, որ գտնեք արտահոսքերը, թունելի վրա գրառումը պարունակում է այն փաթեթները, որոնք դուք արդեն կարծում եք, որ այնտեղ են, իսկ սերվերի վրա այն պարունակում է անընթեռնելի արտաքին փաթեթներ, որոնց աղբյուրը դարպասն է։ Ցանկացած ինտերֆեյսի բայթային հաշվիչները նկարագրում են փաթեթներ, ոչ ծրագրեր, տրաֆիկը գործընթացին վերագրելու համար անհրաժեշտ է մոնիտոր, որը սոկետները քարտեզագրում է գործընթացներին։
Հարցրեք արտաքին ծառայությանը, ապա նորից հարցրեք յուրաքանչյուր ծրագրի համար
Միակ ստուգումը, որն ապացուցում է ելքը, դրսից եկող պատասխանն է՝ ծառայություն, որը վերադարձնում է տեսած աղբյուրի հասցեն։ Գործարկեք այն շելից, որտեղ կարող եք ընտրել ինտերֆեյսը, և գործարկեք երկու անգամ:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipՏարբեր պատասխանները ձեզ ապացույց են տալիս երկու ուղիների համար և միջոց՝ փորձարկելու կոնկրետ ծրագիր՝ կապեք այն, կամ գործարկեք մեկ երթուղիով ցանցային անվանատարածքում, և տեսեք, թե հեռավոր կողմը որ հասցեն է գրանցում։ Նույնական պատասխանները հետաքրքիր խափանումն են՝ կամ կապումը չի գործել, կամ ինչ-որ բան հոսթի և հեռավոր կողմի միջև վերաշարադրում է աղբյուրի հասցեն մինչև այն հասնելը։ Windows-ում curl --interface-ը ուզում է ադապտերի հասցեն, ոչ նրա անունը։
VPN հասցեն հաղորդող զննարկիչը զննարկիչն է ապացուցում։ Փոստային հաճախորդը, փաթեթների կառավարիչը, պահուստավորման գործակալը կամ երկրորդ զննարկիչի պրոֆիլը կարող են յուրաքանչյուրն այլ ուղի վերցնել, հատկապես երբ պրոքսիի կարգավորումը կամ բաժանված թունելի երթուղին ծածկում է դրանցից մեկը։ Հասցեի փոփոխությունն ինքնին արտահոսքի ապացույց չէ՝ բեռնվածքի հավասարեցնողը կարող է այլ կերպ պատասխանել կախված տեսած ելքից, ուստի համեմատեք գրանցված աղբյուրի հասցեն, ոչ էջը։
Օգտագործեք սերվերի տեսքը՝ զույգին հաստատելու համար
Սերվերը պատասխանում է այլ հարցի՝ արդյոք զույգը միացած է, ինչքան է տեղափոխել և արդյոք նստաշրջանը վերագործարկվել է։ Այն զույգը, որը սերվերի վրա ակտիվ է, մինչ հաճախորդի հաշվիչները համարյա չեն շարժվում, նշանակում է, որ ծրագրի տրաֆիկը թունել չի մտնում, ինչ էլ ասել է հաճախորդի աղյուսակը։ Իսկ այն զույգը, որը շատ տվյալ է տեղափոխում մի օգտվողի համար, ով հայտնում է, որ ոչինչ չի աշխատում, այլ հետաքննություն է։
Այստեղ երկու թակարդ կա։ Դիմակավորված թունելը յուրաքանչյուր հոսք ցույց է տալիս այնպես, կարծես դարպասից է գալիս, ուստի մատյանները և յուրաքանչյուր հաճախորդի հաշվառումը միաձուլվում են մեկ հասցեի։ Իսկ հաճախորդը դիտվում է որպես տեղային հոսթ, ուստի այն հարցին, թե ինչ-որ մեկը VPN-ով ֆայլեր է պատճենում, պատասխանում են սերվերի վրա ֆայլերի համօգտագործման տրաֆիկը կամ սերվերի վրա հոսթի աուդիտը՝ թունելը դիտելը տալիս է վերջնակետեր և ծավալ, ոչ ֆայլերի անուններ։
Տարբերեք նախագծային որոշումը արտահոսքից
Ամեն ինչ, որ թունելից դուրս է, արտահոսք չէ։ Հղում-տեղային և հեռարձակվող տրաֆիկը նախագծով մնում է տեղային, multicast-ով գտնված տպիչը շարունակում է գովազդվել LAN-ում, իսկ DHCP-ն պետք է տեղային դուրս գա։ Կոնկրետ ինտերֆեյսին կապված ծրագիրը դիտավորյալ շրջանցում է երթուղային աղյուսակը, և դա փոխում է միայն հրային պատի կանոնը, անվանատարածքը կամ քաղաքականության երթուղին։
IPv6-ը ցանկում իր առանձին տողին արժանի է։ Միայն IPv4 կրող թունելը կրկնակի ստեկի հոսթին թողնում է երկրորդ օգտագործելի ուղի, և կրկնակի ստեկի նպատակակետը կնախընտրի այն՝ ներառյալ DNS-ը, եթե լուծիչը հասանելի է IPv6-ով։ Անջատեք IPv6-ը ադապտերի վրա կամ հաստատեք, որ թունելը կրում է այն, նախքան IPv4 արդյունքը ամբողջական համարելը։
Երբ ստուգումները չեն համընկնում, անհամաձայնությունը սովորաբար անվանում է խափանումը:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
Աշխատող կարգը՝ պահեք երթուղային աղյուսակը միանալուց առաջ և հետո, հետևեք մեկ ներքին և մեկ հանրային անվան, գրանցեք DNS-ը ֆիզիկական ադապտերի վրա, վերադարձրեք ելքի հասցեն շելից կոնկրետ ծրագրի համար, ապա կարդացեք սերվերը՝ ծավալի համար։ Եթե առաջին չորսը համընկնում են, թունելը կրում է այն, ինչ դուք կարծում եք, և մնացած խնդիրը դրա վերևում է։ Եթե դրանցից երկուսը չեն համընկնում, անհամաձայն զույգն է խափանումը, ոչ պատկերակը։