მართლა გადის ტრაფიკი 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 ფიზიკურ ადაპტერზე, დააბრუნეთ გასასვლელის მისამართი შელიდან კონკრეტული აპლიკაციისთვის, შემდეგ წაიკითხეთ სერვერი მოცულობისთვის. თუ პირველი ოთხი თანხვდება, გვირაბი იმას ატარებს, რასაც ფიქრობთ, და დარჩენილი პრობლემა მის ზემოთაა. თუ ორი მათგანი არ თანხვდება, შეუთანხმებელი წყვილია ხარვეზი და არა ხატულა.