VPN დაბლოკილია მხოლოდ ვებ ქსელში? იმუშავეთ ფენებად

კამპუსის ან სასტუმროს ქსელი, სადაც ბრაუზერი მუშაობს და ყოველი გვირაბი იღუპება, ერთი პრობლემა არ არის, ოთხი ფენაა. გზამ შეიძლება დაუშვას მხოლოდ TCP 443, მოითხოვოს ავთენტიფიცირებული პროქსი, შეამოწმოს ხელის ჩამორთმევა, ან უბრალოდ პოლიტიკით აკრძალოს დისტანციური წვდომა. მათი რიგრიგობით დამუშავება გიშლით ხელს იყიდოთ ახალი კლიენტი ქსელის წესის გამოსასწორებლად. ქვემოთ მოცემული სახელმძღვანელო დაახლოებით ათ წუთს იღებს და მთავრდება წერილობითი პასუხით, რომელმა ფენამ გიუარა.

დაამტკიცეთ, რომელი ფენა უარყოფს კავშირს

არ დაიწყოთ VPN კლიენტით. დაიწყეთ იმავე ჰოსტზე ჩვეულებრივი HTTPS მოთხოვნით და წაიკითხეთ დროის ფაზები, რადგან ჩავარდნილი ფაზა გეუბნებათ, რომელი მოწყობილობაა პასუხისმგებელი:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

პასუხი არ არის და connect დროც არ არის ნიშნავს, რომ TCP არასდროს დასრულებულა, ამიტომ თამაშშია ცეცხლის კედელი, პროქსის მოთხოვნა ან არასწორი დანიშნულება. connect დრო tls დროის გარეშე ნიშნავს, რომ შუაში რაღაცამ მიიღო კავშირი და შემდეგ შეაჩერა ხელის ჩამორთმევა, და ასე გამოიყურება შემოწმებელი პროქსი კლიენტის მხრიდან.

ახლა შეამოწმეთ სერტიფიკატი, რომელსაც რეალურად იღებთ. ეს არის ყველაზე სწრაფი გზა გაიგოთ, ესაუბრებით სერვერს თუ შუალედურ ყუთს, რომელმაც სესიას ხელახლა მოაწერა ხელი:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

წაიკითხეთ გამომცემლის ხაზი. თქვენი საკუთარი CA ნიშნავს, რომ სერვისს მიაღწიეთ; კორპორატიული ან მოწყობილობის გამომცემელი ნიშნავს, რომ ფილტრმა დაასრულა კავშირი და წყვეტს, რა იქნება შემდეგ. ჩაწერეთ ორივე გამოსავალი დროის ნიშნით, რადგან იგივე ტესტმა საათის შემდეგ სტუმრების ქსელში შეიძლება სხვა პასუხი მოგცეთ.

პროქსის გაცნობიერებული კლიენტი ცვლის პირველ პაკეტს და არა პოლიტიკას

თუ ქსელი მოითხოვს CONNECT-ს ავთენტიფიცირებული პროქსის მეშვეობით, ეს უნდა უთხრათ VPN კლიენტს, თორემ ცდილობს სოკეტის გახსნას მისამართზე, რომელსაც ვერ მარშრუტიზაციას უკეთებს. შეამოწმეთ პროქსი კლიენტისგან ცალკე, რათა წარუმატებლობას ერთი ახსნა ჰქონდეს:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

პირველი ბრძანება ამტკიცებს, რომ პროქსი დანიშნულებას გადაიტანს. მეორე კლიენტს სთხოვს გამოიყენოს TCP 443-ზე, ეს არის ერთადერთი ტრანსპორტი, რომელსაც მხოლოდ ვებ გზების უმეტესობა საერთოდ გაატარებს. თუ პირველი წარმატებულია და მეორე მაინც ვარდება, პროქსი არ არის დაბრკოლება.

ზოგი კლიენტი კითხულობს ოპერაციული სისტემის პროქსის გადაფარვის ნაცვლად, ზოგი კი არცერთს. შეამოწმეთ აპლიკაციის საკუთარი დოკუმენტაცია, სანამ ჩათვლით, რომ სისტემური პარამეტრი მოქმედებს. კლიენტი, რომელიც საბოლოო წერტილს წყვეტს იმ გამხსნელით, რომელსაც პროქსი არ ემსახურება, აქაც ვარდება, და ამიტომ DNS-ის ცვლილება შეიძლება გამოსწორებად მოგეჩვენოთ, როცა ეს მხოლოდ გვერდის ავლაა.

ყურადღება მიაქციეთ მართვის ნიმუშსაც. ფილტრირებულ ქსელს შეუძლია მიმწოდებლის ამოცნობის ჰოსტსახელს თავისი რაღაცით უპასუხოს, რაც ცვლის, რომელ პროქსის პროფილს ირჩევს კლიენტი. ნუ ააგებთ პროცესს ამ უცნაურობის ირგვლივ. ის ადგილის მიხედვით იცვლება, უტყობად იცვლება და ეს ის არ არის, რაც სხვისთვის შეგიძლიათ დაუჭიროთ მხარი.

პორტი 443 მისაღწევია, არა დაშვებული

გვირაბის TLS-ში გახვევა 443-ზე ხსნის მისაღწევობას და სხვა არაფერს. პორტის შემმოწმებელი ფილტრი გაატარებს; ხელის ჩამორთმევის ანაბეჭდის ამღები ფილტრი არა, და დაშიფრული კლიენტური მისალმება სერვერის სახელს მალავს მხოლოდ მაშინ, როცა ორივე მხარე უჭერს მხარს. გაუშვით ტესტი და გაიგეთ, როგორი ფილტრის უკან ხართ, იმედის ნაცვლად.

არსებობს შესრულების ფასიც, რომელსაც ადამიანები მოგვიანებით აღმოაჩენენ. საიმედო ტრანსპორტი საიმედო ტრანსპორტის შიგნით აძლიერებს დანაკარგს, რადგან შიდა დასტა ხელახლა აგზავნის სეგმენტებს, რომლებიც გარე დასტამ უკვე ხელახლა გაგზავნა. სუფთა ხაზზე ვერავინ ამჩნევს. გადატვირთულ კამპუსურ უსადენო ქსელში გვირაბი უვარგისი ხდება ზუსტად მაშინ, როცა გჭირდებათ, და გრაფიკი პაკეტების დანაკარგს ჰგავს, თუმცა განზრახ არაფერი იყრება.

UDP ჩვეულებრივ პირველი მსხვერპლია, და ღირს ამის დადასტურება და არა დაშვება. თუ WireGuard ან ნაგულისხმევი OpenVPN არასდროს ასრულებს ხელის ჩამორთმევას, სანამ TCP 443 მუშაობს, ქსელი UDP-ს ყრის და გასაღებების ხელახალი გენერაცია ამას ვერ შეცვლის:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

ცარიელი ხელის ჩამორთმევის დროის ნიშანი გუშინ მომუშავე პარტნიორის გვერდით UDP-ის პასუხია. ორი DNS მოთხოვნა სხვა კითხვას პასუხობს: თუ ლოკალური გამხსნელი და საჯარო გამხსნელი არ თანხმდებიან საბოლოო წერტილის მისამართზე, თქვენ მართავენ და ტრანსპორტის არგუმენტი არასწორია.

გადაამოწმეთ, რა დატოვა მანქანამ სინამდვილეში

კლიენტის ჟურნალები აღწერენ, რისიც კლიენტს სჯერა. ჩანაწერი აღწერს, რა დაინახა ქსელმა, და ამ ორის სხვაობა ის ადგილია, სადაც ამ შემთხვევების უმეტესობა იხსნება:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

თუ ხედავთ SYN პაკეტებს და SYN-ACK არ არის, ბლოკი ზემოთაა და კლიენტი უდანაშაულოა. თუ ხედავთ დასრულებულ ხელის ჩამორთმევას მისამართზე, რომელიც სერვერისა არ არის, ესაუბრებით პროქსის ან ჩამჭერს. თუ საერთოდ არაფერს ხედავთ, შეამოწმეთ, რომ სწორ ინტერფეისზე ჩაწერეთ, სანამ რამეს დაასკვნით.

სოკეტების სია უფრო დახვეწილ შემთხვევას იჭერს: მეორე გვირაბი, რომელიც უკვე ფლობს ნაგულისხმევ მარშრუტს. ორი კლიენტი, რომლებიც მარშრუტიზაციის ცხრილისთვის იბრძვიან, წარმოქმნიან წყვეტილ წარუმატებლობებს, რომლებიც ზუსტად დაბლოკილ ქსელს ჰგავს, და ჩანაწერი აჩვენებს ტრაფიკს, რომელიც გადის ინტერფეისიდან, რომელსაც არ ელოდით.

უკან დაბრუნება და ის შენიშვნა, რომლის შენახვაც ღირს

გააუქმეთ ცვლილებები იმის საწინააღმდეგო რიგით, როგორც გააკეთეთ. წაშალეთ პროქსის ცვლადები, გააჩერეთ ხელით გაშვებული კლიენტი და მოხსენით დამატებული ნებისმიერი მარშრუტის ან გამხსნელის გადაფარვა:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

ხელით გაშვებული კლიენტის მუშაობის დატოვება ის გზაა, რომლითაც ლეპტოპი შემდეგ ოფისის ვიზიტზე გატეხილი ქსელით რჩება. ჭურვის პროფილში დატოვებული პროქსის ცვლადები კვირების შემდეგ უკავშირო ხელსაწყოებს ტეხავს, და ვინც მათ ამუშავებს, ორ მოვლენას არ დააკავშირებს.

შემდეგ დაწერეთ ოთხი ხაზი: ქსელი, დროის ნიშანი, ჩავარდნილი ფაზა და ნანახი გამომცემელი. გზა, რომელიც ერთ კამპუსში მუშაობს და შემდეგში ვარდება, ნორმალურია, და შემდეგმა ადამიანმა უნდა იცოდეს, სხვაობა პროქსი, გამხსნელი თუ ფილტრი იყო. თუ პასუხია, რომ ქსელი კრძალავს დისტანციურ წვდომას, იქ გაჩერდით და ადმინისტრატორს სთხოვეთ მხარდაჭერილი გზა, წაუკითხავ პოლიტიკაში გვერდის ავლის წაღების ნაცვლად.