VPN ჟონავს, როცა შენი ტრაფიკის ნაწილი tunnel-ს გვერდს უვლის და მასში არ გადის. სამი გაჟონვა, რომლის შემოწმებაც ღირს, არის DNS (შენი მოთხოვნები ისევ შენი პროვაიდერის ან ლოკალური ქსელის resolver-თან მიდის), IPv6 (tunnel IPv4-ს ატარებს, შენი მოწყობილობა კი სიამოვნებით იყენებს საკუთარ IPv6 მისამართს) და WebRTC (ბრაუზერი მისამართს ააშკარავებს ზარებისა და peer-to-peer ფუნქციის მეშვეობით, რომელსაც ვიდეოსთვის იყენებს). შემოწმებას ხუთი წუთი სჭირდება: დაუკავშირდი, გახსენი DNS leak-ის ტესტი და გაუშვი გაფართოებული შემოწმება, გახსენი IPv6-ის ტესტის გვერდი, გახსენი WebRTC-ის ტესტის გვერდი და მოძებნე ყველაფერი, რაც შენს საკუთარ ქსელს ეკუთვნის. თუ რამე ეკუთვნის, გამოსავალი თითქმის ყოველთვის კლიენტის პარამეტრია და არა ახალი VPN.
დეტალებს მნიშვნელობა აქვს, რადგან "ჩემი DNS leak-ის ტესტი Google-ს აჩვენებს" გაჟონვა არ არის, "ჩემი ბრაუზერი მუშაობს, მაგრამ ჩემი თამაში tunnel-ს არ იყენებს" კი გაჟონვაა, და ტესტები მხოლოდ მაშინ გეხმარება, თუ იცი, რას უყურებ.
რა არის გაჟონვა და რატომ აქვს მნიშვნელობა#
როცა ბრაუზერში სახელს კრეფ, შენი მოწყობილობა DNS resolver-ს მის მისამართს ეკითხება. ვინც ამ resolver-ს მართავს, იღებს ყველა სახელის სიას, რომელსაც ეძებ, დროებით, ხოლო ვინც მისკენ მიმავალ გზაზე ზის, შეუძლია მოთხოვნების წაკითხვა და შეცვლა, თუ ისინი დაშიფრული არ არის. VPN-ის გარეშე ეს resolver ჩვეულებრივ შენი პროვაიდერისაა ან ის, რომელსაც ლოკალური ქსელი გაძლევს.
სრული tunnel-ის VPN ამ მოთხოვნებს tunnel-ით შორეულ ბოლოზე მდგარ resolver-თან უნდა აგზავნიდეს. DNS გაჟონვა ის შემთხვევაა, როცა tunnel ჩართულია, შენი ვებ-დათვალიერება მასში გადის, მოთხოვნები კი ისევ ლოკალურ resolver-თან მიდის. გვერდები დამალულია; სია იმისა, რას ეწვიე - არა.
IPv6-ისა და WebRTC-ის გაჟონვები ერთი მხრივ უარესია: ისინი შენს ნამდვილ მისამართს ააშკარავებენ და არა მხოლოდ მოთხოვნებს. ამას მნიშვნელობა აქვს, თუ VPN-ის აზრი ის იყო, რომ სერვისს არ დაენახა, საიდან უკავშირდები.
როგორ ხდება DNS გაჟონვები#
ოპერაციული სისტემა ყველა resolver-ს ეკითხება, რომელიც იცის. Windows, Windows 8-დან მოყოლებული, იყენებს smart multi-homed name resolution-ს: მას შეუძლია მოთხოვნა ყველა ქსელური ადაპტერით გააგზავნოს და პირველი პასუხი აიღოს. როცა VPN ადაპტერიც და wifi ადაპტერიც ჩართულია, ეს შენს მოთხოვნებს wifi ქსელის resolver-თანაც აგზავნის და tunnel-ისასთანაც. OpenVPN-ის block-outside-dns ოფცია სწორედ ამის შესაჩერებლად არსებობს: ის ამატებს firewall-ის წესებს, რომლებიც სხვა ადაპტერებზე DNS-ს აგდებენ, სანამ tunnel ჩართულია.
კლიენტი proxy-ა და არა VPN. ბევრი VLESS კლიენტი დესკტოპზე ნაგულისხმევად სისტემური proxy-ის რეჟიმშია. აპლიკაცია, რომელიც proxy-ს პატივს სცემს, ჰოსტის სახელს proxy-ს უგზავნის, რომელიც მას შორეულ ბოლოზე ხსნის - გაჟონვა არ არის. აპლიკაცია, რომელიც proxy-ს უგულებელყოფს, სახელს ლოკალურად ხსნის და პირდაპირ უკავშირდება. მისი DNS-იც და ტრაფიკიც ჟონავს, რაც DNS გაჟონვაზე დიდი პრობლემაა.
IPv6 resolver-ები. dual-stack ქსელში შენი მოწყობილობა IPv6 resolver-ებს როუტერის განცხადებებიდან (router advertisements) იგებს. თუ VPN მხოლოდ IPv4 DNS-ს გადააკონფიგურირებს, მოთხოვნები შეიძლება ლოკალური ქსელის IPv6 resolver-თან წავიდეს.
მოწყობილობაზე კონფიგურირებული დაშიფრული DNS. Android-ის Private DNS პარამეტრი, ან ბრაუზერის secure DNS, მოთხოვნებს შენ მიერ არჩეულ პროვაიდერთან აგზავნის. სრულ tunnel-ში ეს დაშიფრული მოთხოვნები tunnel-ით მოგზაურობს და ლოკალურ ქსელს არაფერს უმხელს; პროვაიდერი მათ მაინც ხედავს. split ან proxy სისტემაში ისინი შეიძლება პირდაპირ წავიდეს.
ქეშირებული პასუხები და ადრეული მოთხოვნები. სახელები, რომლებიც VPN-ის დაკავშირებამდე მოიძებნა, ქეშში რჩება, ხოლო აპლიკაციები, რომლებიც სინქრონიზაციას ქსელის გამოჩენისთანავე იწყებენ, მოთხოვნებს tunnel-ის ამუშავებამდე აკეთებენ. ეს დროითი გაჟონვაა, და სწორედ მას ეხება kill switch.
როგორ ამუშავებენ DNS-ს proxy კლიენტები#
Xray-ზე დაფუძნებულ კლიენტებს WireGuard-ის აპლიკაციაზე მეტი მოძრავი ნაწილი აქვთ, ამიტომ რეჟიმების ცოდნა გამოგადგება.
| კლიენტის რეჟიმი | ვინ ხსნის სახელებს | ტიპური გაჟონვა |
|---|---|---|
| სისტემური proxy, აპლიკაცია მას პატივს სცემს | სერვერი, ჰოსტის სახელიდან | ამ აპლიკაციისთვის არცერთი |
| სისტემური proxy, აპლიკაცია მას უგულებელყოფს | შენი მოწყობილობა, ლოკალურად | DNS და თავად ტრაფიკი |
| SOCKS proxy ბრაუზერში | ბრაუზერის პარამეტრზეა დამოკიდებული | DNS, თუ დისტანციური DNS გამორთულია |
| VPN ან TUN რეჟიმი | კლიენტი იჭერს DNS-ს და tunnel-ით აგზავნის | მხოლოდ თუ IPv6 ან სხვა ადაპტერი გვერდს უვლის |
SOCKS რეჟიმში Firefox-ს კავშირის პარამეტრებში კონკრეტული პარამეტრი აქვს, "Proxy DNS when using SOCKS v5"; როცა ის გამორთულია, Firefox სახელებს ლოკალურად ხსნის და proxy-ით მხოლოდ კავშირები გადის. Chrome ნაგულისხმევად ჰოსტის სახელებს SOCKS5 proxy-ს დისტანციურად გასახსნელად უგზავნის.
VPN ან TUN რეჟიმში sing-box-ზე ან Xray-ზე აგებული კლიენტები DNS-ს ვირტუალურ ინტერფეისზე იჭერენ. ზოგი "fake IP" სქემას იყენებს: კლიენტი ყოველ მოთხოვნას მყისიერად პასუხობს დროებითი მისამართით დაჯავშნილი დიაპაზონიდან, როგორიცაა 198.18.0.0/15, შემდეგ კი ნამდვილ სახელს სერვერზე ხსნის, როცა კავშირი მყარდება. თუ დაკავშირებისას nslookup-ის გამოტანაში ამ დიაპაზონის მისამართებს ხედავ, ეს კლიენტი ისე მუშაობს, როგორც ჩაფიქრებულია, და არა ხარვეზი.
კლიენტებს საკუთარი DNS პარამეტრებიც აქვთ - დისტანციური DNS, რომელიც tunnel-ით გამავალი ტრაფიკისთვის გამოიყენება, და პირდაპირი DNS, რომელიც მის გვერდის ავლით მარშრუტიზებული ტრაფიკისთვის. დისტანციური უნდა იყოს resolver, რომელსაც სერვერის გავლით მიწვდები. თუ დააყენე წესები, რომლებიც ლოკალურ საიტებს პირდაპირ აგზავნიან, მათი მოთხოვნების ლოკალურ resolver-თან წასვლა მოსალოდნელია; split tunnelling განმარტებით განიხილავს, როგორ ურთიერთქმედებს მარშრუტიზაციისა და DNS-ის წესები.
DNS გაჟონვების შემოწმება#
დაუკავშირდი VPN-ს, შემდეგ გამოიყენე ნებისმიერი ცნობილი ტესტის საიტი - dnsleaktest.com, browserleaks.com ან ipleak.net. ისინი ასე მუშაობენ: შენს ბრაუზერს აიძულებენ, მოძებნოს შემთხვევითი, უნიკალური სახელების სერია მათ მიერ კონტროლირებად დომენში, და აღრიცხავენ, რომელი resolver-ები ეკითხებიან მათ ავტორიტეტულ სერვერებს ამ სახელებს.
რას უნდა მიაქციო ყურადღება შედეგებში:
- კარგია: resolver-ები VPN სერვერის ქვეყანაში ან საჯარო resolver-ის კუთვნილი (Google, Cloudflare, Quad9), რომლის გამოყენებაც tunnel-ით შენს კლიენტს აქვს კონფიგურირებული.
- გაჟონვაა: ნებისმიერი resolver, რომელსაც შენი სახლის პროვაიდერი, მობილური ოპერატორი ან სასტუმროს ქსელი მართავს, ან ნებისმიერი resolver შენს ქვეყანაში, როცა სერვერი სხვაგანაა.
გაუშვი გაფართოებული ტესტი და არა სტანდარტული. სტანდარტული ტესტი რამდენიმე მოთხოვნას აკეთებს და შეიძლება გამორჩეს ადაპტერი, რომელიც მხოლოდ ზოგჯერ პასუხობს, და სწორედ ასე იქცევა Windows-ის multi-homed resolution.
იგივე ტერმინალიდანაც შეგიძლია. რამდენიმე DNS ოპერატორი სპეციალურ სახელს იმ resolver-ის მისამართით პასუხობს, რომელმაც იკითხა:
$ dig +short whoami.akamai.net$ dig +short TXT o-o.myaddr.l.google.comWindows-ზე dig-ის გარეშე:
nslookup whoami.akamai.netდაბეჭდილი მისამართი resolver-ის გამავალი მისამართია, როგორც Akamai-მ ან Google-მა დაინახა. ის VPN-ის მხარეს უნდა ეკუთვნოდეს და არა შენს პროვაიდერს. ეს ბრაუზერის გარდა სხვა აპლიკაციებსაც ამოწმებს, რადგან სისტემურ resolver-ს იყენებს.
IPv6 გაჟონვები#
ბევრი VPN სისტემა მხოლოდ IPv4-ს ატარებს. თუ შენი ქსელი შენს მოწყობილობას IPv6 მისამართს აძლევს და tunnel IPv6-თან დაკავშირებით არაფერს აკეთებს, ყოველი საიტი, რომელიც IPv6-ით მისაწვდომია, პირდაპირ, შენი ნამდვილი მისამართით იხსნება, ხოლო IPv4 საიტები tunnel-ით მიდის. Google, Facebook, Netflix, Cloudflare-ის უკან მდგარი საიტები და დიდი ვების დიდი ნაწილი IPv6-ით მისაწვდომია, ამიტომ ეს იშვიათი შემთხვევა არ არის.
შეამოწმე IPv6-ის ტესტის გვერდით (სტანდარტულია test-ipv6.com) ან ტერმინალიდან:
$ curl -4 https://ifconfig.me # VPN სერვერის მისამართი უნდა დაბეჭდოს$ curl -6 https://ifconfig.me # უნდა ჩავარდეს, ან შენი არაკუთვნილი მისამართი დაბეჭდოსგამოსავლები, უპირატესობის მიხედვით:
- კლიენტი, რომელიც IPv6-ს tunnel-ში მარშრუტიზებს. VPN, რომელსაც შორეულ ბოლოზე IPv6 აქვს, მას ატარებს; ის, რომელსაც არ აქვს, მაინც უნდა იჭერდეს
::/0-ს და აგდებდეს, რომ აპლიკაციები tunnel-ით IPv4-ზე გადავიდნენ. - კლიენტის პარამეტრი IPv6-ისთვის. რამდენიმე VLESS კლიენტს აქვს ოფცია, რომელიც აკონტროლებს, გამოიყენება თუ არა IPv6; დააყენე ისე, რომ IPv6 ან tunnel-ით წავიდეს, ან დაიბლოკოს.
- IPv6-ის გამორთვა ადაპტერზე, რომელსაც VPN-თან იყენებ. Windows-ზე ქსელური ადაპტერის თვისებებში მოხსენი მონიშვნა Internet Protocol Version 6 (TCP/IPv6)-ს. უხეშია, მაგრამ ეფექტური და ადვილად დასაბრუნებელი.
IPv6 და თამაშის სერვერები უფრო დეტალურად ხსნის, როგორ ირჩევენ dual-stack ქსელები ამ ორს შორის.
WebRTC გაჟონვები#
WebRTC არის ის, რასაც ბრაუზერები ვიდეოზარებისა და peer-to-peer კავშირებისთვის იყენებენ. ზარის დასამყარებლად ბრაუზერი კანდიდატ მისამართებს აგროვებს: თავის ლოკალურ მისამართებს და საჯაროს, როგორც მას STUN სერვერი ხედავს. ვებ-გვერდს შეუძლია ეს შეგროვება JavaScript-ის რამდენიმე ხაზით გამოიწვიოს და შედეგები წაიკითხოს, ისე, რომ ზარი არასდროს განხორციელდეს.
თანამედროვე ბრაუზერები ლოკალურ მისამართებს შემთხვევითი .local სახელების (mDNS) უკან მალავენ, ამიტომ შენი კერძო 192.168.x.x მისამართის წაკითხვის ძველი ხრიკი უმეტესად აღარ მუშაობს. საჯარო კანდიდატი კი ისევ იქ არის. სრული tunnel-ის VPN-ით STUN მოთხოვნა tunnel-ით მიდის და VPN სერვერის მისამართს აბრუნებს, რაც ნორმალურია. გაჟონვა ხდება, როცა STUN მოთხოვნა tunnel-ით არ მიდის: proxy რეჟიმში, რადგან WebRTC UDP-ს იყენებს და proxy-ს ხშირად უგულებელყოფს, ან IPv6-ით, რომელიც tunnel-ს გვერდს უვლის.
დაკავშირებულ მდგომარეობაში შეამოწმე browserleaks.com-ის WebRTC გვერდით ან ipleak.net-ით. თუ შენი ნამდვილი საჯარო მისამართი ჩანს, გამოასწორე მიზეზი (გამოიყენე VPN რეჟიმი proxy რეჟიმის ნაცვლად, დახურე IPv6-ის ხარვეზი) ან შეზღუდე WebRTC ბრაუზერში:
| ბრაუზერი | პარამეტრი |
|---|---|
| Firefox | media.peerconnection.enabled დაყენებული false-ზე about:config-ში (WebRTC-ს მთლიანად თიშავს) |
| Brave | კონფიდენციალურობისა და უსაფრთხოების პარამეტრები, WebRTC IP handling policy |
| Chrome და Edge | ჩაშენებული გადამრთველი არ აქვს; პოლიტიკას Google-ის WebRTC Network Limiter გაფართოება აყენებს |
WebRTC-ის გამორთვა ბრაუზერში ვიდეოზარებს აფუჭებს. handling policy-ის შეზღუდვა უფრო რბილი შუალედური გამოსავალია.
ხუთწუთიანი შემოწმების რუტინა#
გააკეთე ეს თითოეულ მოწყობილობაზე ერთხელ, კლიენტის ნებისმიერი განახლების შემდეგ, და ნებისმიერ ახალ ქსელში, რომელზე დაყრდნობასაც აპირებ.
- გათიშე VPN და გაჟონვის ტესტის გვერდიდან ჩაიწერე შენი ნამდვილი საჯარო IPv4 და IPv6 მისამართები და შენი პროვაიდერის resolver.
- დაუკავშირდი VPN-ს.
- გაუშვი DNS გაჟონვის გაფართოებული ტესტი. არცერთი პროვაიდერის ან ლოკალური ქსელის resolver.
- გაუშვი IPv6-ის ტესტი. ან IPv6 საერთოდ არ არის, ან ის შენი ნამდვილი არ არის.
- გაუშვი WebRTC-ის ტესტი. არანაირი ნამდვილი საჯარო მისამართი.
- ტერმინალიდან გაუშვი
dig +short whoami.akamai.net, რომ სისტემური resolver-იც შეამოწმო. - გახსენი აპლიკაცია, რომელიც ბრაუზერი არ არის - თამაშის launcher, ფოსტის კლიენტი - და შეამოწმე, რომ ის ჩართული VPN-ით მუშაობს. თუ proxy რეჟიმში მუშაობას წყვეტს, ის proxy-ს არასდროს იყენებდა.
Windows-ზე პარამეტრების შეცვლის შემდეგ გაასუფთავე ქეში, რომ ძველმა პასუხებმა შედეგი არ აგირიოს:
ipconfig /flushdnsგამოსავლები პლატფორმების მიხედვით#
| პლატფორმა | გავრცელებული გაჟონვა | გამოსავალი |
|---|---|---|
| Windows | Multi-homed DNS, proxy-ის უგულებელმყოფი აპლიკაციები | გამოიყენე კლიენტის VPN ან TUN რეჟიმი; გაასუფთავე ქეში; გამორთე IPv6 ადაპტერზე, თუ კლიენტი მას ვერ უმკლავდება |
| macOS | proxy რეჟიმი მხოლოდ ზოგ აპლიკაციას ფარავს | გამოიყენე VPN რეჟიმი; შეამოწმე IPv6 |
| Android | Private DNS, აპლიკაციები tunnel-ის ამუშავებამდე | Always-on და block connections without VPN; გადახედე Private DNS პარამეტრებს |
| iOS | ტრაფიკი VPN-ის გაშვებამდე | ხელახლა დაუკავშირდი ქსელებთან მიერთების შემდეგ; შეამოწმე კლიენტის on-demand ოფციები |
| Linux | systemd-resolved არასწორ link-ს იყენებს | დააყენე tunnel-ის ინტერფეისი ნაგულისხმევ DNS მარშრუტად; შეამოწმე resolvectl status-ით |
VPN-ის kill switch და always-on განიხილავს დროით გაჟონვებს - რა იპარება, სანამ VPN ხელახლა უკავშირდება - რასაც მშვიდ მომენტში ჩატარებული გაჟონვის ტესტი ვერასდროს აჩვენებს.
გაჟონვები და კერძო სერვერი#
კერძო სერვერზე, რომელსაც შენ მართავ, "resolver შორეულ ბოლოზე" არის ის, რასაც შენი სერვერი იყენებს, ხოლო მისამართი, რომელსაც საიტები ხედავენ, შენი სერვერისაა. RE:NODE-ის კერძო VPN ხაზზე სერვერი Xray-ს იყენებს VLESS-ითა და Reality-ით, აქვს საკუთარი მისამართი და გასაღები, მასზე სხვა არავინაა, და გერმანიაშია - ასე რომ სწორი ტესტის შედეგი გერმანულ მისამართს აჩვენებს და არცერთ resolver-ს შენი პროვაიდერისგან. Windows-ის Renode VPN აპლიკაცია იმ ბმულით უკავშირდება, რომელსაც სერვერი ბეჭდავს; ტელეფონებსა და Mac-ებზე იგივე ბმული v2rayNG-ში, Hiddify-ში, Streisand-ში ან Shadowrocket-ში ჩაისმება, და ზემოთ აღწერილი გაჟონვის ტესტები თითოეულ მათგანზე ერთნაირად ვრცელდება. VLESS კლიენტის დაყენების გზამკვლევი თითოეული კლიენტის რეჟიმებს განიხილავს.
FAQ#
ჩემი DNS leak-ის ტესტი Cloudflare-ის ან Google-ის resolver-ებს აჩვენებს. ეს გაჟონვაა?
თავისთავად არა. გაჟონვაა, თუ ამ resolver-ებს შენი ქსელიდან პირდაპირ მიწვდები და არა tunnel-ით. თუ ტესტი მათ VPN სერვერის რეგიონში აჩვენებს, ან შენს კლიენტს ისინი დისტანციურ DNS-ად აქვს კონფიგურირებული, ეს tunnel-ის მუშაობაა.
შეუძლია ვებსაიტს ჩართული VPN-ის დროს WebRTC-ით ჩემი ნამდვილი IP დაინახოს?
მხოლოდ თუ WebRTC-ის ტრაფიკი tunnel-ს გვერდს უვლის, რაც ხდება მხოლოდ proxy რეჟიმებში და tunnel-ს გარეთ დარჩენილი IPv6-ით. სრული tunnel-ით მისამართი, რომელსაც ის პოულობს, VPN სერვერისაა. შეამოწმე და ნუ ივარაუდებ.
ანაცვლებს დაშიფრული DNS გაჟონვების შემოწმების საჭიროებას?
არა. დაშიფრული DNS მოთხოვნების შიგთავსს ლოკალური ქსელისგან მალავს, მაგრამ თუ ის tunnel-ს გვერდს უვლის, DNS პროვაიდერს მაინც შენს ნამდვილ მისამართს უმხელს, და IPv6-ისა თუ WebRTC-ისთვის არაფერს აკეთებს. შეამოწმე მისი ჩართვით.
რატომ გადის ჩემი გაჟონვის ტესტი სახლში და ვერ გადის სასტუმროში?
სხვადასხვა ქსელი სხვადასხვა resolver-სა და სხვადასხვა IPv6 კონფიგურაციას გასცემს. სასტუმრო IPv6-ით ააშკარავებს IPv6 გაჟონვას, რომელიც შენს მხოლოდ IPv4-იან სახლის ქსელს არასდროს უჩვენებია. შეამოწმე თითოეულ ქსელში, რომელზეც ხარ დამოკიდებული.
უბრალოდ ყველგან გამოვრთო IPv6?
მხოლოდ იმ მოწყობილობებსა და ადაპტერებზე, სადაც შენი VPN მას ვერ უმკლავდება. პრობლემა IPv6 არ არის; პრობლემა tunnel-ია, რომელიც მას უგულებელყოფს. კლიენტი, რომელიც IPv6-ს tunnel-ში იჭერს ან ბლოკავს, უფრო სუფთა გამოსავალია.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.