ის L2TP მისამართი IPCP-ია, არა DHCP იჯარა LAN-ზე

კავშირი ადის და ადაპტერი ოფისის დიაპაზონში მყოფ მისამართს აჩვენებს, ამიტომ ბუნებრივი დასკვნაა, რომ VPN-მა გაძლიათ LAN მისამართი და ამით LAN-ზე განათავსათ. ამის არც ერთი ნახევარი არ არის სრულიად სწორი. L2TP PPP სესიას ატარებს და PPP IPCP-ით აწარმოებს მოლაპარაკებას შიდა IPv4 მისამართზე. ეს მისამართი ორ მხარეს შორის შეთანხმებული სესიის პარამეტრია, არა ოფისის DHCP სერვერის მიერ გაცემული იჯარა, და მისი ფლობა ოფისის სადენზე მეზობლად არ გაქცევთ.

ორი მისამართი ერთ კავშირში

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

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

რას აკეთებს IPCP ზუსტად

IPCP PPP-ის IPv4 კონტროლის პროტოკოლია. თითოეული მხარე აგზავნის Configure-Request შეტყობინებებს სასურველი ოპციების აღწერით, და მისამართის ოპცია ერთ-ერთი მათგანია. კლიენტი, რომელსაც ჯერ მისამართი არ აქვს, ჩვეულებრივ 0.0.0.0-ით ითხოვს, და სერვერი პასუხობს Configure-Nak-ით, რომელიც ატარებს იმ მისამართს, რომელიც სურს კლიენტმა გამოიყენოს. შემდეგ კლიენტი ითხოვს ამ მისამართს და სესია ადის ლოკალური და დისტანციური მისამართით.

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

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

რატომ ვერ უპასუხებს LAN თქვენ

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

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

ჯერ სესია შეამოწმეთ, შემდეგ მარშრუტი

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

სამი ეტაპი ცალ-ცალკე შეინახეთ

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

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