რატომ ჩერდება PPTP და L2TP/IPsec მომხმარებლის სახელის მოთხოვნამდე?
მომხმარებლის სახელის მოთხოვნის არარსებობა ნიშნავს, რომ PPP არასოდეს დაწყებულა, ამიტომ ხარვეზი ტრანსპორტში, გასაღების გაცვლაში ან გვირაბის აწყობაშია. გადაამოწმეთ ეტაპების რიგი ხელახლა დაყენებამდე.
მომხმარებლის სახელის მოთხოვნის არარსებობა დიაგნოსტიკური საჩუქარია: PPP ჯერ არ დაწყებულა, ამიტომ ანგარიში, პაროლი და დომენის პოლიტიკა ჯერ არ გამოკითხულა. PPTP ან L2TP/IPsec კავშირში კლიენტი სამოწმებს ითხოვს მხოლოდ მას შემდეგ, რაც გვირაბი არსებობს და სერვერმა PPP სესია დაიწყო. ყველაფერი, რაც შეიძლება ჩავარდეს ამ მომენტამდე, ტრანსპორტია, გასაღების გაცვლა ან გვირაბის აწყობა, რაც გაცილებით მცირე არეა, ვიდრე «VPN გატეხილია».
დაკარგული მოთხოვნა ხარვეზს სამ ეტაპამდე ამცირებს
ჩაწერეთ ბოლო ეტაპი, რომელიც თვალსაჩინოდ წარმატებით დასრულდა, რადგან თითოეულს განსხვავებული მფლობელი და განსხვავებული გადაწყვეტა აქვს. ანგარიშის პარამეტრების გამოცნობა, როცა ორი ეტაპით ადრე ხართ ჩარჩენილი, ის გზაა, რომლითაც შუადღე ქრება.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
კლიენტი, რომელსაც მოთხოვნის გარეშე დრო ამოეწურა, არასოდეს მიუღია IPsec ასოციაცია, ამიტომ ხარვეზი IKE-შია ან იმაში, აღწევს თუ არა თქვენი პაკეტები კარიბჭეს. ის, რომელიც აცხადებს სამოწმებების გადამოწმებას და შემდეგ ვარდება, შეტყობინების მინიშნებაზე უფრო შორს მივიდა. მოთხოვნის შემდეგ უარი PPP ავთენტიფიკაციაა და მისი ადგილი ანგარიშის სტატიაშია, არა ამაში.
პირველი ეტაპი: პროტოკოლი, რომელსაც ქსელური ეკრანი ჩუმად ყრის
PPTP-ს სჭირდება TCP 1723 საკონტროლო არხისთვის და IP პროტოკოლი 47 მონაცემთა გზისთვის, და ორივე ცალ-ცალკე მოგზაურობს. ბევრი ქსელი 1723-ს გადასცემს და პროტოკოლ 47-ს ყრის, რაც ქმნის გვირაბს, რომელიც მოლაპარაკებას აწარმოებს და შემდეგ საერთოდ არაფერს გადააქვს. NAT-ის მაკეთებელ მარშრუტიზატორს GRE-მხარდაჭერილი გატარებაც სჭირდება, და მხოლოდ IPv6-ზე დაფუძნებული წვდომის გზა ვერც ერთ კონფიგურაციაში ვერ გადაიტანს PPTP-ს.
L2TP IPsec-ის თავზე ხარჯავს პორტ 500-ს IKE-სთვის და პორტ 4500-ს NAT-ის გადალახვისთვის, შემდეგ თავად L2TP ტრაფიკს 1701-ში ახვევს, ხოლო ESP დაცულ დატვირთვას ატარებს, როცა ასოციაცია არსებობს. დაუშვით ორი საკონტროლო პორტი, მაგრამ არა ESP, და მიიღებთ ზუსტად სათაურის სიმპტომს: თვალსაჩინო წინსვლა, შემდეგ მკვდარი კლიენტი ნებისმიერ სამოწმებელ დიალოგამდე. ტელეფონის ჰოთსპოტიდან ტესტირება იაფი გზაა კლიენტის პრობლემის გზის პრობლემისგან გასაყოფად.
მეორე ეტაპი: გასაღები, რომელიც გასაღები არ არის, წინადადება, რომელიც არ შემოთავაზებულა
წინასწარ გაზიარებული გასაღები, რომელიც არ ემთხვევა, სწრაფად და ჩუმად ვარდება, და ჩვეულებრივი ვარიანტია გასაღები, რომელიც ეკრანზე სწორად გამოიყურება, მაგრამ ჩასმული სტრიქონის წყვეტას ან ბოლოში ჰარეს ატარებს. Linux კლიენტზე დიალოგი სავალდებულოდ სიმართლის წყარო არ არის: NetworkManager-ის L2TP დანამატი საიდუმლოებებს ინახავს ფაილებში /etc/ipsec.d/-ის ქვეშ, და ძველი თითო-კავშირის ფაილი, რომელსაც /etc/ipsec.secrets ჯერ კიდევ მოიცავს, გამოყენებული იქნება ახლახან აკრეფილი ფაილის ნაცვლად. დააკოპირეთ ეს ფაილი უსაფრთხო ადგილას, ამოიღეთ იგი ჩართვის გზიდან და შემდეგ ხელახლა აკრიფეთ გასაღები ხელით.
ამ ეტაპის მეორე ნახევარი წინადადებაა. ორივე მხარემ უნდა შეთანხმდეს ერთსა და იმავე 1-ლი ფაზის ალგორითმების ნაკრებზე — დაშიფვრა, მთლიანობა და Diffie-Hellman ჯგუფი — და 2-ე ფაზის შესაბამის ESP გარდაქმნებზე, წინააღმდეგ შემთხვევაში ასოციაცია საერთოდ არ ყალიბდება. კარიბჭე, რომელიც მხოლოდ 3DES-ს, SHA1-ს და MODP1024-ს გვთავაზობს, უარყოფს უფრო ძლიერ ალგორითმებზე დაყენებულ კლიენტს, და მისი ჟურნალი ასახელებს უარყოფილ გარდაქმნას. ჟურნალი ასახელებს შეუთანხმებლობას, თუ წაიკითხავთ მას სერვისის კიდევ ერთხელ გადატვირთვის ნაცვლად. ფორუმის თემიდან ალგორითმების სტრიქონის კოპირების ნაცვლად ჰკითხეთ კარიბჭეს, რომელ გარდაქმნებზე იმოლაპარაკებს იგი სინამდვილეში: მის მისამართზე მიმართული ike-scan აბრუნებს იმ გარდაქმნებს, რომლებზეც იმოლაპარაკებს. თუ ერთადერთი შეთავაზება ისეთი კრიპტოგრაფიაა, რომელსაც თქვენი პოლიტიკა აღარ უშვებს, გამოსწორება კარიბჭეს ეკუთვნის და არა კლიენტის დაქვეითებას.
Windows-ში გასაღები და ავთენტიფიკაციის მეთოდი VPN პროფილში ცხოვრობს, და შეუთანხმებლობა ვლინდება სამოწმებების მოთხოვნამდე და არა შემდეგ. სადაც მიმღები Windows Server-ია, დაადასტურეთ, რომ დისტანციური წვდომის როლი დაყენებულია, სერტიფიკატი ემთხვევა სახელს, რომელზეც კლიენტები უკავშირდებიან, და არც ერთი პორტის ფილტრი არ არის ზემოთ მოცემულ პროტოკოლებზე ვიწრო.
მესამე ეტაპი: გვირაბი არსებობს და PPP არ იწყება
როცა IKE დასრულდა და მოთხოვნა მაინც არ ჩნდება, შეხედეთ გვირაბის დემონს და არა ქსელურ ეკრანს. L2TP-ს სჭირდება რაღაც, რაც UDP 1701-ზე უსმენს — xl2tpd ან kl2tpd Linux-ში, დისტანციური წვდომის სერვისი Windows-ში — და დაყენებული, მაგრამ გაჩერებული სერვისი კლიენტის მხრიდან ზუსტად ისე გამოიყურება, როგორც ჩამოგდებული პაკეტი. შეამოწმეთ მსმენელი, სანამ ხელახლა გახსნით უკვე გადამოწმებულ წესებს. შემდეგ PPP-მ უნდა იმოლაპარაკოს, და პირველი LCP გაცვლა არის ის ადგილი, სადაც ჩუმი წარუმატებლობა ჩვეულებრივ ეშვება.
ამ ეტაპის ერთი ხაფანგი საერთოდ არ არის ქსელური ხარვეზი: Windows ერთდროულად მხოლოდ ერთ კავშირს უშვებს მოცემული ტიპის VPN-ზე, ამიტომ მეორე მცდელობა აბრუნებს 937 შეცდომას, «ამ ტიპის სხვა კავშირი გამოიყენება». ეს ლოკალური წესია, და მის გვერდის ავლის გზა სხვა მოწყობილობა, სხვა ტიპის გვირაბი ან უკვე არსებული ერთადერთი კავშირის გაზიარებაა.
წაიკითხეთ ჟურნალი ეტაპების რიგით და არა გამოცნობით
შეაჩერეთ კლიენტი, ხელახლა გაუშვით და წაიკითხეთ კომპონენტები იმ რიგით, რომლითაც ისინი ჟურნალს წერენ. ეს ნიშნავს ჯერ IPsec დემონი — strongSwan ან Libreswan, და ipsec --version გეუბნებათ რომელი — შემდეგ L2TP დემონი, შემდეგ pppd. რომელი კომპონენტიც ბოლოს წერდა ხარვეზამდე, ის მიუთითებს გამოსაკვლევ ეტაპზე, რადგან ყველაფერი, რაც მის შემდეგ მოდის თანმიმდევრობაში, საერთოდ არ გაშვებულა.
გადაამოწმეთ ახალი კავშირით და არა შენახული სესიით, რადგან ქეშიდან ხელახლა მიერთებულმა კლიენტმა შეიძლება გამოტოვოს გაცვლის ნაწილები და გაამრავლოს მოძველებული შედეგი. დაადასტურეთ წვდომადობა, გასაღების გაცვლა, გვირაბი და PPP სათითაოდ, ამ რიგით. მაშინ დაკარგული მოთხოვნა წყვეტს საიდუმლოებას და ხდება სიის მეორე ხაზი, რომელზეც ნამდვილად შეიძლება მუშაობა. ეს სია ასევე არის ის, რასაც ქსელის გუნდს გადასცემთ, რომელსაც სხვა შემთხვევაში სთხოვდნენ ქსელური ეკრანის შემოწმებას ხარვეზის გამო, რომელიც არგაშვებულ დემონში ცხოვრობს.