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

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

ამ სახელმძღვანელოში გამოყენებული ბრძანებების უმეტესობა უნდა შესრულდეს sudo-ს საშუალებით, რომელიც ამოღებულია მოკლედ. გაითვალისწინეთ.

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

მე მაქვს Ubuntu 18.04, მაგრამ ვფიქრობ, მცირე ცვლილებებით სახელმძღვანელო შეიძლება გამოყენებულ იქნას სხვა დისტრიბუციებზე. თუმცა, ამ ტექსტში Linux == Ubuntu.

Cisco Connect

მათ, ვინც მუშაობს Windows-ზე ან MacOS-ზე, შეუძლია დაუკავშირდეს ჩვენს კორპორატიულ VPN-ს Cisco Connect-ის საშუალებით, რომელიც უნდა მიუთითოს კარიბჭის მისამართი და ყოველი დაკავშირებისას შეიყვანოთ პაროლი, რომელიც შედგება ფიქსირებული ნაწილისგან და Google Authenticator-ის მიერ გენერირებული კოდისგან.

Linux-ის შემთხვევაში, მე ვერ შევძელი Cisco Connect-ის გაშვება, მაგრამ მოვახერხე გუგლში რეკომენდაცია გამოეყენებინა openconnect, რომელიც სპეციალურად შეიქმნა Cisco Connect-ის ჩასანაცვლებლად.

გახსენით კავშირი

თეორიულად, Ubuntu-ს აქვს სპეციალური გრაფიკული ინტერფეისი openconnect-ისთვის, მაგრამ ეს არ მუშაობდა ჩემთვის. იქნებ ეს უკეთესობისკენ არის.

Ubuntu-ზე openconnect დაინსტალირებულია პაკეტის მენეჯერიდან.

apt install openconnect

ინსტალაციისთანავე, შეგიძლიათ სცადოთ VPN-თან დაკავშირება

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com არის ფიქტიური VPN-ის მისამართი
poxvuibr - ფიქტიური მომხმარებლის სახელი

openconnect მოგთხოვთ პაროლის შეყვანას, რომელიც, შეგახსენებთ, შედგება ფიქსირებული ნაწილისგან და კოდისგან Google Authenticator-ისგან და შემდეგ შეეცდება vpn-თან დაკავშირებას. თუ მუშაობს, გილოცავთ, შეგიძლიათ უსაფრთხოდ გამოტოვოთ შუა, რაც ძალიან მტკივნეულია და გადახვიდეთ ფონზე openconnect-ის გაშვებაზე. თუ ეს არ მუშაობს, შეგიძლიათ გააგრძელოთ. მიუხედავად იმისა, რომ თუ ის მუშაობდა, მაგალითად, სტუმრის Wi-Fi-დან სამსახურში დაკავშირებისას, მაშინ შეიძლება ძალიან ადრე იყოს გახარება; თქვენ უნდა შეეცადოთ გაიმეოროთ პროცედურა სახლიდან.

სერთიფიკატი

დიდია ალბათობა იმისა, რომ არაფერი დაიწყება და openconnect გამომავალი ასე გამოიყურება:

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found

Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

ერთის მხრივ, ეს უსიამოვნოა, რადგან VPN-თან კავშირი არ ყოფილა, მაგრამ, მეორეს მხრივ, როგორ მოვაგვაროთ ეს პრობლემა, პრინციპში, გასაგებია.

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

იმისათვის, რომ openconnect სერვერს დაუკავშირდეს, თქვენ უნდა ნათლად უთხრათ მას, რომელი სერთიფიკატი უნდა მოდიოდეს VPN სერვერიდან —servercert გასაღების გამოყენებით.

და თქვენ შეგიძლიათ გაიგოთ, რომელი სერთიფიკატი გამოგვიგზავნა სერვერმა უშუალოდ openconnect-დან დაბეჭდილი. აი ამ ნაწილიდან:

To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

ამ ბრძანებით შეგიძლიათ ხელახლა სცადოთ დაკავშირება

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

შესაძლოა ახლა ის მუშაობს, შემდეგ შეგიძლიათ ბოლომდე გადახვიდეთ. მაგრამ პირადად Ubunta-მ მაჩვენა ლეღვი ამ ფორმით

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

/etc/resolv.conf

# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53

/run/resolvconf/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.com

habr.com მოაგვარებს, მაგრამ თქვენ ვერ შეძლებთ იქ წასვლას. მისამართები, როგორიცაა jira.evilcorp.com, საერთოდ არ არის გადაწყვეტილი.

რა მოხდა აქ ჩემთვის გაუგებარია. მაგრამ ექსპერიმენტი აჩვენებს, რომ თუ ხაზს დაამატეთ /etc/resolv.conf

nameserver 192.168.430.534

შემდეგ VPN-ის შიგნით მისამართები დაიწყებენ ჯადოსნურ გადაჭრას და თქვენ შეგიძლიათ გაიაროთ ისინი, ანუ ის, რასაც DNS ეძებს მისამართების გადასაჭრელად, გამოიყურება კონკრეტულად /etc/resolv.conf-ში და არა სადმე სხვაგან.

შეგიძლიათ გადაამოწმოთ, რომ არსებობს კავშირი VPN-თან და ის მუშაობს /etc/resolv.conf-ზე რაიმე ცვლილების შეტანის გარეშე; ამისათვის უბრალოდ შეიყვანეთ ბრაუზერში არა VPN რესურსის სიმბოლური სახელი, არამედ მისი IP მისამართი.

შედეგად, არსებობს ორი პრობლემა

• VPN-თან დაკავშირებისას მისი dns არ არის აღებული
• მთელი ტრაფიკი გადის VPN-ით, რომელიც არ იძლევა ინტერნეტში წვდომის საშუალებას

მე გეტყვით რა უნდა გააკეთოთ ახლა, მაგრამ ჯერ ცოტა ავტომატიზაცია.

პაროლის ფიქსირებული ნაწილის ავტომატური შეყვანა

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

პრობლემის საბოლოო გადაწყვეტა სტატიაში არ იყო მოყვანილი, მაგრამ შეგიძლიათ დარწმუნდეთ, რომ პაროლის ფიქსირებული ნაწილი ბევრჯერ არ უნდა შეიყვანოთ.

დავუშვათ, რომ პაროლის ფიქსირებული ნაწილი არის fixedPassword, ხოლო ნაწილი Google Authenticator-დან არის 567. მთელი პაროლი შეიძლება გადავიდეს openconnect-ზე სტანდარტული შეყვანის მეშვეობით --passwd-on-stdin არგუმენტის გამოყენებით.

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

ახლა თქვენ შეგიძლიათ მუდმივად დაუბრუნდეთ ბოლო შეყვანილ ბრძანებას და შეცვალოთ Google Authenticator-ის მხოლოდ ნაწილი.

კორპორატიული VPN არ გაძლევთ საშუალებას ისარგებლოთ ინტერნეტით.

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

ჩვენ როგორმე უნდა მოვაწყოთ ის ისე, რომ როდესაც თქვენ გჭირდებათ რესურსზე წვდომა შიდა ქსელიდან, Linux გადადის VPN-ზე, ხოლო როდესაც გჭირდებათ Habr-ზე გადასვლა, ის გადადის ინტერნეტში.

openconnect, vpn-თან კავშირის გაშვებისა და დამყარების შემდეგ, ახორციელებს სპეციალურ სკრიპტს, რომელიც მდებარეობს /usr/share/vpnc-scripts/vpnc-script-ში. ზოგიერთი ცვლადი გადაეცემა სკრიპტს შეყვანის სახით და ის აკონფიგურირებს VPN-ს. სამწუხაროდ, მე ვერ გავარკვიე, როგორ გავყო ტრაფიკის ნაკადები კორპორატიულ VPN-სა და დანარჩენ ინტერნეტს შორის მშობლიური სკრიპტის გამოყენებით.

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

ტრაფიკის გამიჯვნა vpn-slice-ის გამოყენებით

პირველ რიგში, თქვენ უნდა დააინსტალიროთ vpn-slice, თქვენ თავად უნდა გაარკვიოთ ეს. თუ კომენტარებში იქნება შეკითხვები, ამის შესახებ ცალკე პოსტს დავწერ. მაგრამ ეს არის პითონის რეგულარული პროგრამა, ასე რომ არ უნდა იყოს რაიმე სირთულე. დავაინსტალირე virtualenv-ის გამოყენებით.

და შემდეგ უნდა იქნას გამოყენებული კომუნალური პროგრამა -script გადამრთველის გამოყენებით, რომელიც მიუთითებს openconnect-ზე, რომ სტანდარტული სკრიპტის ნაცვლად, თქვენ უნდა გამოიყენოთ vpn-slice

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  " vpn.evilcorp.com 

--სკრიპტს გადაეცემა სტრიქონი ბრძანებით, რომელიც უნდა გამოიძახოთ სკრიპტის ნაცვლად. ./bin/vpn-slice - გზა vpn-slice შესრულებადი ფაილის 192.168.430.0/24 - მისამართების ნიღაბი, რომლებზეც უნდა გადახვიდეთ vpn-ში. აქ ვგულისხმობთ, რომ თუ მისამართი იწყება 192.168.430-ით, მაშინ ამ მისამართის რესურსი უნდა მოძებნოთ VPN-ში.

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

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

მასპინძლების ფაილის ავტომატური მოდიფიკაცია

თუ vpn-slice-ს თავაზიანად სთხოვენ, მაშინ VPN-ის ამაღლების შემდეგ, მას შეუძლია გადავიდეს მის DNS-ზე, მოძებნოს იქ საჭირო რესურსების IP მისამართები მათი სიმბოლური სახელებით და შეიყვანოს ისინი ჰოსტებში. VPN-ის გამორთვის შემდეგ, ეს მისამართები წაიშლება ჰოსტებიდან. ამისათვის თქვენ უნდა გადასცეთ სიმბოლური სახელები vpn-slice-ს არგუმენტებად. Ამგვარად.

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

ახლა ყველაფერი უნდა მუშაობდეს როგორც ოფისში, ასევე სანაპიროზე.

მოძებნეთ ყველა ქვედომენის მისამართი VPN-ის მიერ მოცემულ DNS-ში

თუ ქსელში რამდენიმე მისამართია, მაშინ ჰოსტების ფაილის ავტომატურად შეცვლის მიდგომა საკმაოდ კარგად მუშაობს. მაგრამ თუ ქსელში ბევრი რესურსია, მაშინ მუდმივად დაგჭირდებათ ხაზების დამატება, როგორიცაა zoidberg.test.evilcorp.com სკრიპტში zoidberg არის ერთ-ერთი ტესტის სკამი.

მაგრამ ახლა, როდესაც ჩვენ ცოტათი გვესმის, რატომ შეიძლება აღმოიფხვრას ეს საჭიროება.

თუ VPN-ის ამაღლების შემდეგ გადახედავთ /etc/hosts-ს, შეგიძლიათ ნახოთ ეს ხაზი

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED

და ახალი ხაზი დაემატა resolv.conf. მოკლედ, vpn-slice-მა რატომღაც განსაზღვრა სად მდებარეობს vpn-ის dns სერვერი.

ახლა ჩვენ უნდა დავრწმუნდეთ, რომ evilcorp.com-ზე დამთავრებული დომენის IP მისამართის გასარკვევად, Linux გადადის კორპორატიულ DNS-ზე და თუ რამე სხვაა საჭირო, მაშინ ნაგულისხმევზე.

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

ანუ, შეგიძლიათ დარწმუნდეთ, რომ Linux ყოველთვის მიდის ადგილობრივ DNS სერვერზე IP მისამართებისთვის, რომელიც თავის მხრივ, დომენის სახელიდან გამომდინარე, ეძებს IP-ს შესაბამის გარე DNS სერვერზე.

ქსელებთან და ქსელურ კავშირებთან დაკავშირებული ყველაფრის სამართავად, Ubuntu იყენებს NetworkManager-ს, ხოლო გრაფიკული ინტერფეისი, მაგალითად, Wi-Fi კავშირების შესარჩევად, მხოლოდ წინა ნაწილია.

ჩვენ დაგვჭირდება ასვლა მის კონფიგურაციაში.

1. შექმენით ფაილი /etc/NetworkManager/dnsmasq.d/evilcorp-ში

მისამართი=/.evilcorp.com/192.168.430.534

ყურადღება მიაქციეთ evilcorp-ის წინ არსებულ წერტილს. ეს სიგნალს აძლევს dnsmasq-ს, რომ evilcorp.com-ის ყველა ქვედომენი უნდა მოძებნოთ კორპორატიულ dns-ში.

1. უთხარით NetworkManager-ს გამოიყენოს dnsmasq სახელის გადაწყვეტისთვის

ქსელის მენეჯერის კონფიგურაცია მდებარეობს /etc/NetworkManager/NetworkManager.conf-ში, თქვენ უნდა დაამატოთ იქ:

[მთავარი] dns=dnsmasq

1. გადატვირთეთ NetworkManager

service network-manager restart

ახლა, VPN-თან დაკავშირების შემდეგ openconnect-ისა და vpn-slice-ის გამოყენებით, ip განისაზღვრება ნორმალურად, მაშინაც კი, თუ სიმბოლურ მისამართებს არ დაამატებთ არგუმენტებს vpnslice-ში.

როგორ მივიღოთ წვდომა ინდივიდუალურ სერვისებზე VPN-ის საშუალებით

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

ჩვენი ფოსტა მდებარეობს mail.publicevilcorp.com-ზე, რაც ნიშნავს, რომ ის არ ექვემდებარება dnsmasq-ის წესებს და ფოსტის სერვერის მისამართის ძებნა ხდება საჯარო DNS-ის საშუალებით.

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

მისამართი=/mail.publicevilcorp.com/192.168.430.534

სიტუაცია საერთოდ არ შეცვლილა. ip იგივე დარჩა. სამსახურში უნდა წავსულიყავი.

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

მე ვიყენებ vpn-slice-ს VPN-ის გავლით მისამართებზე, რომლებიც იწყება 192.168.430-ით. ფოსტის სერვერს არა მხოლოდ აქვს სიმბოლური მისამართი, რომელიც არ არის evilcorp-ის ქვედომენი, მას ასევე არ აქვს IP მისამართი, რომელიც იწყება 192.168.430-ით. და რა თქმა უნდა, ის არ აძლევს არავის უფლებას გენერალური ქსელიდან მასთან მისვლა.

იმისათვის, რომ Linux-მა გაიაროს VPN და ფოსტის სერვერზე, თქვენ უნდა დაამატოთ ის ასევე vpn-slice-ში. ვთქვათ, ფოსტის მისამართია 555.555.555.555

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com 

სკრიპტი VPN ამაღლებისთვის ერთი არგუმენტით

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

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

თუ სკრიპტს დააყენებთ connect~evilcorp~-ში, შეგიძლიათ უბრალოდ ჩაწეროთ კონსოლში

connect_evil_corp 567987

მაგრამ ახლა თქვენ მაინც უნდა შეინახოთ კონსოლი, რომელშიც openconnect მუშაობს რატომღაც ღია

გაშვებული openconnect ფონზე

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

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

ახლა უბრალოდ გაუგებარია სად მიდის ჟურნალები. ზოგადად, ჩვენ ნამდვილად არ გვჭირდება ჟურნალები, მაგრამ თქვენ არასოდეს იცით. openconnect-ს შეუძლია მათი გადამისამართება syslog-ზე, სადაც ისინი დაცული და დაცული იქნება. თქვენ უნდა დაამატოთ –syslog გადამრთველი ბრძანებას

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

ასე რომ, გამოდის, რომ openconnect მუშაობს სადღაც ფონზე და არავის აწუხებს, მაგრამ გაუგებარია როგორ შეაჩეროს იგი. ანუ, თქვენ შეგიძლიათ, რა თქმა უნდა, გაფილტროთ ps გამომავალი grep-ის გამოყენებით და მოძებნოთ პროცესი, რომლის სახელი შეიცავს openconnect-ს, მაგრამ ეს რაღაცნაირად დამღლელია. მადლობა ავტორებსაც, ვინც ამაზე ფიქრობდა. Openconnect-ს აქვს გასაღები -pid-file, რომლითაც შეგიძლიათ openconnect-ს დაავალოთ ჩაწეროს მისი პროცესის იდენტიფიკატორი ფაილში.

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background  
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

ახლა თქვენ ყოველთვის შეგიძლიათ პროცესის მოკვლა ბრძანებით

kill $(cat ~/vpn-pid)

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

kill $(cat ~/vpn-pid)
#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

ახლა თქვენ შეგიძლიათ ჩართოთ თქვენი კომპიუტერი, გახსნათ კონსოლი და გაუშვათ ბრძანება, გადასცეთ მას კოდი Google Authenticator-იდან. ამის შემდეგ კონსოლი შეიძლება დამაგრდეს.

VPN სლაისის გარეშე. შემდგომი სიტყვის ნაცვლად

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

შედეგად, აღმოვაჩინე, რომ vpn-slice, ისევე როგორც მშობლიური სკრიპტი, ცვლის მარშრუტიზაციის ცხრილს ცალკეულ ქსელებში.

მარშრუტიზაციის მაგიდა

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

მარშრუტიზაციის ცხრილის სანახავად, თქვენ უნდა გაუშვათ ip route ბრძანება

default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 
192.168.430.0/24 dev tun0 scope link 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 
192.168.430.534 dev tun0 scope link 

აქ თითოეული ხაზი პასუხისმგებელია იმაზე, თუ სად უნდა წახვიდეთ, რათა გაგზავნოთ შეტყობინება ზოგიერთ მისამართზე. პირველი არის აღწერა, თუ სად უნდა დაიწყოს მისამართი. იმისათვის, რომ გაიგოთ, თუ როგორ უნდა დადგინდეს, რომ 192.168.0.0/16 ნიშნავს, რომ მისამართი უნდა დაიწყოს 192.168-ით, თქვენ უნდა მოძებნოთ Google-ში რა არის IP მისამართის ნიღაბი. dev-ის შემდეგ არის ადაპტერის სახელი, რომელზეც უნდა გაიგზავნოს შეტყობინება.

VPN-სთვის Linux-მა შექმნა ვირტუალური ადაპტერი - tun0. ხაზი უზრუნველყოფს, რომ ტრაფიკი 192.168-დან დაწყებული ყველა მისამართისთვის გადის მასზე

192.168.0.0/16 dev tun0 scope link 

თქვენ ასევე შეგიძლიათ ნახოთ მარშრუტიზაციის ცხრილის მიმდინარე მდგომარეობა ბრძანების გამოყენებით მარშრუტი -n (IP მისამართები ჭკვიანურად ანონიმურია) ეს ბრძანება აწარმოებს შედეგებს სხვა ფორმით და ზოგადად მოძველებულია, მაგრამ მისი გამომავალი ხშირად გვხვდება სახელმძღვანელოებში ინტერნეტში და თქვენ უნდა შეძლოთ მისი წაკითხვა.

სად უნდა დაიწყოს მარშრუტის IP მისამართი, ეს შეიძლება გავიგოთ Destination და Genmask სვეტების კომბინაციიდან. IP მისამართის ის ნაწილები, რომლებიც შეესაბამება Genmask-ის 255 ნომრებს, გათვალისწინებულია, მაგრამ ის, სადაც არის 0, არა. ანუ Destination 192.168.0.0 და Genmask 255.255.255.0 კომბინაცია ნიშნავს, რომ თუ მისამართი იწყება 192.168.0-ით, მაშინ მასზე მოთხოვნა წავა ამ მარშრუტზე. და თუ დანიშნულების ადგილი 192.168.0.0 მაგრამ Genmask 255.255.0.0, მაშინ 192.168-ით დაწყებული მისამართების მოთხოვნები გადის ამ მარშრუტზე

იმის გასარკვევად, თუ რას აკეთებს რეალურად vpn-slice, გადავწყვიტე გადავხედო ცხრილების მდგომარეობას ადრე და შემდეგ

VPN-ის ჩართვამდე ასე იყო

route -n 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0

openconnect-ის დარეკვის შემდეგ vpn-slice-ის გარეშე გახდა ასე

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

და openconnect-ის დარეკვის შემდეგ vpn-slice-თან ერთად

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

ჩანს, რომ თუ არ იყენებთ vpn-slice-ს, მაშინ openconnect ცალსახად წერს, რომ ყველა მისამართზე, გარდა კონკრეტულად მითითებულისა, უნდა იყოს წვდომა vpn-ის საშუალებით.

სწორედ აქ:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

იქ, მის გვერდით, დაუყოვნებლივ არის მითითებული სხვა გზა, რომელიც უნდა იქნას გამოყენებული, თუ მისამართი, რომლის გავლასაც Linux ცდილობს, არ ემთხვევა ცხრილის არცერთ ნიღაბს.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

აქ უკვე წერია, რომ ამ შემთხვევაში საჭიროა სტანდარტული Wi-Fi ადაპტერის გამოყენება.

მე მჯერა, რომ VPN ბილიკი გამოიყენება, რადგან ის პირველია მარშრუტიზაციის ცხრილში.

და თეორიულად, თუ თქვენ ამოიღებთ ამ ნაგულისხმევ გზას მარშრუტიზაციის ცხრილიდან, მაშინ dnsmasq openconnect-თან ერთად უნდა უზრუნველყოთ ნორმალური მუშაობა.

მე ვეცადე

route del default

და ყველაფერი მუშაობდა.

მოთხოვნის მარშრუტიზაცია ფოსტის სერვერზე vpn-slice-ის გარეშე

მაგრამ მე ასევე მაქვს ფოსტის სერვერი მისამართით 555.555.555.555, რომელზეც ასევე საჭიროა წვდომა VPN-ით. მისკენ მიმავალი მარშრუტი ასევე უნდა დაემატოს ხელით.

ip route add 555.555.555.555 via dev tun0

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

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

წყარო: www.habr.com