შეუსაბამეთ Linux VPN კლიენტი ძველი მოწყობილობის პროტოკოლს

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

ჩაიწერეთ, რას აქვეყნებს დისტანციური მხარე

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

სახელმძღვანელო და თავად მოწყობილობის ფაირვოლის წესები უფრო საიმედოა, ვიდრე პროტოკოლის სახელი მის შესვლის გვერდზე. IPsec-ის რეკლამირებული მოწყობილობა შეიძლება მხოლოდ IKEv1-ზე საუბრობდეს, და firmware-ის გამოშვება, რომელიც არავის გამოუყენებია, შეიძლება იყოს ის, რაც საბოლოოდ IKEv2-ს ამატებს. დაადასტურეთ მონაცემთა გზაც და კონფიგურაციის პორტიც, რადგან სწორედ აქ განსხვავდებიან ძველი აღჭურვილობა და თანამედროვე ქსელები. ამ ნაბიჯში შეცდომა ნიშნავს თქვენი კლიენტის გამართვას იმ ფუნქციის წინააღმდეგ, რომელიც მეორე მხარეს არასდროს ჰქონია.

PPTP: დაამტკიცეთ GRE, სანამ pppd-ს შეცვლით

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

pppd call branch-office
tcpdump -ni any proto gre -c 5

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

L2TP/IPsec: ერთი შესაბამისი შეთავაზება ამარცხებს ათ ცდას

წაიკითხეთ დემონის ჟურნალი და არა სამუშაო მაგიდის დიალოგი, რადგან დიალოგი რამდენიმე სხვადასხვა მარცხს ერთ შეტყობინებაში აერთიანებს. NO_PROPOSAL_CHOSEN შეცდომა პირველ ფაზას ეკუთვნის: კლიენტმა შემოგვთავაზა დაშიფვრა, ჰეში ან Diffie-Hellman ჯგუფი, რომელსაც სერვერი არ მიიღებს. ჩამოთვალეთ, რას უჭერს მხარს მოწყობილობა და დაწერეთ ერთი შესაბამისი შეთავაზება, რადგან შემთხვევითი კომბინაციები ჩვეულებრივ იმავე შეცდომას უფრო ნელა იძლევიან. სამუშაო მაგიდაზე პრაქტიკული კლიენტია NetworkManager L2TP დამატება strongSwan-ის ან Libreswan-ის ქვეშ.

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

აგრესიული IKEv1 XAuth-ით, და პორტალის შემთხვევა

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

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

strongSwan-ის ძველი გამოშვებები იყენებდნენ xauth=client-ს იქ, სადაც ვერსია 5 იყენებს leftauth2=xauth-ს, ამიტომ კოპირებული ფრაგმენტი შეიძლება მხოლოდ სინტაქსის გამო ჩავარდეს. TLS პორტალისთვის openconnect, რომელიც AnyConnect პროტოკოლზე საუბრობს, უმკლავდება Cisco-ს და უმეტეს გადარქმეულ ბრენდებს, და მას სჭირდება TUN მოწყობილობა და მისი კონფიგურაციის უფლებები. გადასცეთ პორტალის მისამართი ზუსტად ისე, როგორც ბრაუზერი აჩვენებს, მათ შორის ნებისმიერი გზა, რომელსაც მოწყობილობა ელის, შემდეგ კი შეამოწმეთ მინიჭებული მისამართი, სანამ მის უკან რამეს გამოსცდით. ინტერფეისის წინასწარ შექმნა კონფიგურაციის დროს სიურპრიზების ერთ კლასს აშორებს.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

დაუკავშირდით, შემდეგ გადაამოწმეთ ფიქსირებული თანმიმდევრობით

გაუშვით ზუსტად ერთი VPN მენეჯერი ერთდროულად, რადგან NetworkManager-ის პროფილი და ხელით გაშვებული დემონი იბრძოლებენ მარშრუტებისა და DNS-ისთვის. ჩამოწიეთ პროფილი, სანამ ხელით კავშირს გამოსცდით, და დაადასტურეთ, რომ ძველი გვირაბის ინტერფეისი არ გადარჩენილა. შემდეგ გადაამოწმეთ ამ თანმიმდევრობით: გვირაბის მისამართი, მარშრუტი ერთადერთ შიდა ჰოსტამდე, რომელიც გჭირდებათ, სახელების ამოხსნა და ბოლოს რეალური მოთხოვნა. მწვანე ხატი ამტკიცებს ავთენტიფიკაციას და სხვა არაფერს.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

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