MikroTik-ის PPTP იწყვეტს? გაასწორეთ მარშრუტი სერვერამდე

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

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

სიმპტომი: უკავშირდება, ტრაფიკს გადასცემს, ჩერდება

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

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

რატომ ყლაპავს გვირაბი საკუთარ პაკეტებს

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

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

მიამაგრეთ სერვერის მისამართი WAN-ს

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

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

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

ან აუკრძალეთ გვირაბს ნაგულისხმევის მითვისება

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

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

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

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

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

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

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