VPN-ის რომელი ეტაპი ჩავარდა: IPsec, L2TP კონტროლი თუ PPP ავთენტიფიკაცია
იპოვეთ ბოლო წარმატებული ეტაპი და შეასწორეთ მხოლოდ ის ფენა: IPsec, L2TP საკონტროლო არხი, PPP ავთენტიფიკაცია ან მისამართის მინიჭება.
პაროლი შეცვალეთ და არაფერი შეიცვალა, რადგან ხარვეზი არასდროს PPP-ში ყოფილა. L2TP/IPsec ერთი კავშირის შეცდომას აცნობს ხუთ სრულიად განსხვავებულ გადაცემაზე და თითოეულ გადაცემას თავისი შეკეთება აქვს. იმუშავეთ უკუღმა: იპოვეთ ბოლო ეტაპი, რომელიც წარმატებით დასრულდა, და შეცვალეთ მხოლოდ ის, რაც მის შემდეგ მოდის. ქვემოთ მოცემული რიგი ასევე განსაზღვრავს, რომელი მტკიცებულება შეაგროვოთ პირველად.
უპასუხეთ ოთხ კითხვას რიგრიგობით
აიძულეთ ახალი მცდელობა, რადგან ზოგიერთი კლიენტი წინა შეცდომას აჩვენებს მანამ, სანამ პროფილი გაითიშება და ხელახლა დაუკავშირდება. შემდეგ უპასუხეთ: იყო თუ არა IPsec უსაფრთხოების ასოციაცია, გამოჩნდა თუ არა L2TP საკონტროლო კავშირი და ზარი, მიაღწია თუ არა PPP ავთენტიფიკაციის გადაწყვეტილებას და მისცა თუ არა IPCP კლიენტს მისამართი? პირველი არა არის ის ეტაპი, რომელსაც ასწორებთ. ყველაფერი მის შემდეგ შეუმოწმებელია, ამიტომ უარყოფილი მომხმარებლის სახელი არაფერს ამტკიცებს, როცა ასოციაცია არასდროს არსებობდა.
შედარებამდე ორივე მხარეს საათები დაასინქრონეთ. ხელახალი მცდელობა, რომელმაც IPsec გაასუფთავა და PPP-ზე ჩავარდა, ერთ ხარვეზად გამოიყურება, როცა კლიენტი მხოლოდ ბოლო შეტყობინებას აჩვენებს და სერვერის ჟურნალი ჯერ კიდევ ინახავს წინა მცდელობას. წაიკითხეთ დროის ნიშნის მიხედვით, არა ყველაზე ხმამაღალი ხაზის მიხედვით.
როცა მხოლოდ მომხმარებლის ეკრანის სურათი გაქვთ, დაეყრდენით ყველაზე იაფ გაყოფას: არასწორი წინასწარ გაზიარებული გასაღები და xl2tpd, რომელიც არასდროს პასუხობს, Windows-ის დიალოგში ერთსა და იმავე ტექსტს იძლევა, თუმცა ერთს ორივე მხარეს შეცვლილი საიდუმლო სჭირდება, მეორეს კი სერვერზე გაშვებული დემონი ან firewall-ის წესი. შუაში მდგომი მოწყობილობა ვერ ჩააგდებს შიდა 1701-ს მას შემდეგ, რაც transport რეჟიმის IPsec მას შემოახვია, ამიტომ ნუ ეძებთ გზის ფილტრს, რომელიც არ არსებობს.
რას ფლობს სინამდვილეში თითოეული ფენა
IPsec იცავს პაკეტებს ორ პარტნიორს შორის; L2TP ატარებს PPP სესიას ამ დაცული გზის შიგნით, ამიტომ RFC 3193 საკუთარი გვირაბის ნაცვლად transport რეჟიმს განსაზღვრავს. კლიენტის ეტიკეტი ამბობს L2TP, ამიტომ გვირაბი და შესვლა ერთ მექანიზმად აღიქმება. ასე არ არის: L2TP საკონტროლო კავშირი ავთენტიფიცირებს გვირაბის ბოლოებს იქ, სადაც განლაგება მას რთავს, ხოლო PPP ცალკე ავთენტიფიცირებს მომხმარებელს CHAP-ით, PAP-ით ან MS-CHAPv2-ით სერვერის პოლიტიკის მიხედვით.
ეს გაყოფა ხსნის ორ საიდუმლოს, რომლებსაც ხალხი გამუდმებით ურევს. წინასწარ გაზიარებული გასაღები ავთენტიფიცირებს IPsec პარტნიორებს. მომხმარებლის სახელი და პაროლი მომხმარებელს PPP-ისთვის იდენტიფიცირებს. Windows-ის გაზიარებული საიდუმლოს ხელახლა აკრეფა პროფილზე, რომელიც სერტიფიკატებით ავთენტიფიცირდება, ჩავარდნილ ეტაპზე არაფერს ცვლის, ხოლო PPP პაროლის რედაქტირება ვერ მოგვცემს დაკარგულ დაცულ არხს. იგივე თავშეკავება ეხება იდენტობის შემოწმებას: ნუ გამორთავთ პარტნიორის იდენტობას ან სერტიფიკატის ვალიდაციას გვირაბის მისაღებად, რადგან მაშინ გზა უკავშირდება და არა პარტნიორი.
ავთენტიფიკაცია PPP-ის დასასრულიც არ არის. მომხმარებლის მიღების შემდეგ IPCP აწარმოებს მოლაპარაკებას კლიენტის მისამართზე და იმ DNS და WINS პარამეტრებზე, რომელთა გაცემაც სერვერს სურს. კლიენტმა შეიძლება გაიაროს CHAP ან MS-CHAPv2 და მაინც დარჩეს მისამართის გარეშე, რაც PPP-ის შიგნით ხარვეზია და არა მარშრუტიზაციის პრობლემა. IPsec-ის გარეშე ჩვეულებრივი L2TP ძალაში რჩება და დაუცველია, ამიტომ წარმატებული კავშირი არასდროს ამტკიცებს, რომ ტრაფიკი დაცულია; შეამოწმეთ, რას მოითხოვს სერვერი და არა კლიენტის ეტიკეტი.
გადაწყვიტეთ პირველი დაკარგული ეტაპის მიხედვით
ცხრილი წაიკითხეთ პირველი დაკარგული ელემენტის მიხედვით, მარცხნიდან მარჯვნივ. მარჯვენა სვეტი ერთადერთი სამუშაოა, რომელიც ამ მომენტში ღირს; ყველაფერი მისგან მარცხნივ უკვე დამტკიცებულია და მისი ხელახლა ტესტირება შეფერხების ფანჯარას წვავს ინფორმაციის დამატების გარეშე.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
სამი სტრიქონი გაფრთხილებას იმსახურებს. 1701-ის სტრიქონი არის ადგილი, სადაც NAT-ის უკან მდგომი Windows კლიენტები ჩვეულებრივ ხვდებიან: ასოციაცია სრულდება, შემდეგ არაფერი მოდის და მიზეზი ინკაპსულაციაა და არა ცუდი პაროლი. IPCP-ის სტრიქონი არის ის, რომელსაც არასწორად კითხულობენ მარშრუტის პრობლემად, რადგან Windows დაკარგულ მისამართს 720 შეცდომაში ახვევს და tray-ის ხატულა მხოლოდ ამბობს, რომ კავშირი ჩავარდა; ეს ხარვეზი ავთენტიფიკაციის შემდეგ და მარშრუტიზაციამდეა. ბოლო სტრიქონი საერთოდ არ არის IPsec-ის ხარვეზი, თუმცა ხატულა ამბობს, რომ გათიშულია.
ბრძანებები, რომლებიც ფენებს ჰყოფს
strongSwan-ის მქონე Linux სერვერზე swanctl --list-sas ჩამოთვლის დამყარებულ ასოციაციებს პარტნიორის იდენტობით, ხოლო ipsec statusall ფარავს ძველ strongSwan და libreswan ჰოსტებს. მის ქვეშ ip xfrm state აჩვენებს ბირთვის ფაქტობრივ ასოციაციებს, ხოლო ss -lunp | grep 1701 ამტკიცებს, სად არის xl2tpd მიბმული. გაუშვით xl2tpd -D წინა პლანზე, რომ ნახოთ საკონტროლო კავშირები და ზარები, და ჩართეთ pppd-ის გამართვა /etc/ppp/options.xl2tpd-ში შემოთავაზებული მეთოდისა და პასუხის სანახავად.
როცა ჟურნალები წარმატებულ ავთენტიფიკაციას აჩვენებს, შემდეგი კითხვაა, დასრულდა თუ არა IPCP. შეამოწმეთ, ხომ არ აქვს ip range-ს /etc/xl2tpd/xl2tpd.conf-ის [lns default] განყოფილებაში ჯერ კიდევ თავისუფალი მისამართები და ხომ არ ატარებს /etc/ppp/options.xl2tpd ნამდვილად ms-dns-სა და ms-wins-ს, თუ კლიენტი მათ ელოდება. ამოწურული პული და დაკარგული DNS პარამეტრი მავთულზე განსხვავებულად ჩანს: პირველი კლიენტს მისამართის გარეშე და 720-ით ტოვებს, მეორე მისამართს აძლევს, მაგრამ გამხსნელს არა, ამიტომ სახელები ჩავარდება, სანამ ნედლ მისამართებზე ping მუშაობს. არც ერთი არ სწორდება პაროლის ხელახლა შეყვანით.
კლიენტზე NetworkManager-ის L2TP დანამატი pppd-ის საუბარს ჟურნალში წერს, ამიტომ journalctl -u NetworkManager -b ჩვეულებრივ ჰყოფს გვირაბი აწეულია, ავთენტიფიკაცია უარყოფილია მდგომარეობას საერთოდ გვირაბი არ არის მდგომარეობისგან. Windows-ზე Get-VpnConnection პროფილის რეალურ ავთენტიფიკაციის პარამეტრებს აცნობს, ხოლო Event Viewer-ში Application-ის ქვეშ მყოფი RasClient მოვლენები ჩავარდნილ კომპონენტს ასახელებს. როცა დიალოგი ძალიან ბუნდოვანია, ჩართეთ netsh ras set tracing * enable.
ჩანაწერები ერთ სიფრთხილეს მოითხოვს. transport რეჟიმის IPsec-ით შიდა UDP 1701 დაშიფრულია, ამიტომ გარე ინტერფეისზე ჩანაწერი აჩვენებს ESP-ს, ან NAT-T-ის ქვეშ UDP 4500-ს და საერთოდ არა L2TP-ს. 1701-ის არარსებობა ჩანაწერში მოსალოდნელია და არ არის დაბლოკილი პორტის მტკიცებულება; აკვირდით, მოძრაობს თუ არა ESP ან 4500 მრიცხველები.
NAT, MTU და მარშრუტები: სად გატყუებთ სტეკი
NAT ვარაუდებს ამსხვრევს მანამ, სანამ რამე ავთენტიფიცირდება. ESP საკუთარი IP პროტოკოლია, ამიტომ მთარგმნელი მოწყობილობა მას ყრის, თუ პარტნიორები არ ინკაპსულირებენ; სწორედ ამას იძლევა UDP 4500. Windows სერვერზე, რომელიც თავად დგას სახლის როუტერის ან ღრუბლოვანი NAT-კარიბჭის უკან, IPsec ეტაპი 789 შეცდომით ჩავარდება, სანამ PolicyAgent გასაღების ქვეშ AssumeUDPEncapsulationContextOnSendRule არ დაყენდება 2-ზე და მანქანა არ გადაიტვირთება, და ხარვეზი დახურული პორტისგან განურჩეველი რჩება. NAT-ის უკან მყოფი კლიენტები უფრო ადვილები არიან: სერვერზე საჯარო მისამართის არსებობისას UDP 4500-ზე NAT-T მათ ატარებს და ეს მნიშვნელობა არ მონაწილეობს.
როცა PPP აწეულია, შავი ხვრელის MTU მკვდარ გვირაბს ბაძავს: პატარა პაკეტები გადის, TLS-ის ხელის ჩამორთმევა ან გვერდის ჩატვირთვა იკიდება და კლიენტმა შეიძლება კვლავ დაკავშირებული გამოაჩინოს. სერვერის დადანაშაულებამდე დაწიეთ ინტერფეისის MTU ან შეავიწროვეთ MSS კარიბჭეში. გაყოფილი გვირაბის მარშრუტიზაცია სხვა თაღლითია; არასწორი ნიღბით გაგზავნილი ქვექსელი გვირაბს ჯანსაღად და ერთ აპლიკაციას მიუწვდომლად ტოვებს. პირადი ჰოსტის სახელი თავის ნაბიჯს ამატებს: თუ მოთხოვნა ლოკალური გამხსნელით გადის, სახელი ვერ იხსნება მანამ, სანამ რომელიმე მარშრუტი შემოწმდება.
შემოწმების სია სანამ რწმუნებებს შეეხებით
სია რიგრიგობით გაიარეთ და გაჩერდით პირველ ჩავარდნილ პუნქტზე. თითოეული ნაბიჯი იაფია და თითოეული გამორიცხავს შესწორებათა მთელ კლასს.
- დაადასტურეთ, რომ ასოციაცია ორივე მხარეს არსებობს, შედარებული პარტნიორის იდენტობით და არა დაკავშირებულის ეტიკეტით.
- დაადასტურეთ, რომ UDP 1701 აღწევს xl2tpd-მდე; ზარის გარეშე ასოციაცია თქვენი ხარვეზია.
- წაიკითხეთ PPP-ის განაჩენი და, თუ ავთენტიფიცირდა, IPCP-ის შედეგი, სანამ ჩათვლით, რომ პაროლი არასწორია.
- მხოლოდ ახლა შეიყვანეთ რწმუნებები ხელახლა იმ ფორმატში, რომელსაც სერვერი ელოდება, რადგან დომენის პრეფიქსი ანგარიშს ცვლის.
- თუ კვლავ ჩავარდა, ჩაწერეთ ორივე მხარე გასწორებული დროის ნიშნებით და შეადარეთ ეტაპობრივად.
მეორე ნაბიჯზე გაჩერება ნიშნავს გზის ან ინკაპსულაციის პრობლემას და პაროლის არც ერთი შესწორება არ გაამოძრავებს მას. მესამე ნაბიჯზე გაჩერება ნიშნავს, რომ ჟურნალი უკვე ასახელებს მეთოდს ან მისამართების პულს, რომელიც უნდა გამოსწორდეს. ორივე შემთხვევაში შემდეგი ცვლილება ის არის, რომელსაც თავად დაასაბუთებთ, და წყვეტთ იმ პარამეტრებში ტრიალს, რომლებიც არასდროს მონაწილეობდნენ.