pfSense OpenVPN: სხვა მარშრუტიზატორის მიღმა არსებულ ქსელზე მისვლა

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

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

ერთი პაკეტი, სამი მარშრუტიზაციის გადაწყვეტილება

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

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

მიეცით კლიენტს პრეფიქსი, და არა ვარაუდი

pfSense SSL/TLS სერვერზე, რომლის IPv4 გვირაბის ქსელი /30-ზე დიდია, IPv4 Local network(s) ველი დაკავშირებისას კლიენტებზე მარშრუტებს ანაწილებს. დაამატეთ ქვედა დონის პრეფიქსი იქ, ნაცვლად იმისა, რომ დაეყრდნოთ კლიენტს მისი გამოგონების იმედს. შემდეგ, დაკავშირების შემდეგ, წაიკითხეთ კლიენტის ფაქტობრივი ცხრილი, რადგან route-nopull-ის მქონე პროფილს ან მარშრუტის ფილტრს შეუძლია უგულებელყოს ის, რაც სერვერმა გაგზავნა. სერვერი შეიძლება სრულიად სწორი იყოს, მაშინ როცა კლიენტი არაფერს აყენებს.

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

მიმართეთ pfSense შიდა მარშრუტიზატორზე

pfSense-ში სტატიკურ მარშრუტს სჭირდება განსაზღვრული და მისაწვდომი კარიბჭე, და ამ კარიბჭისთვის არჩეული ინტერფეისი უნდა იყოს ის, რომელიც ნამდვილად აღწევს მას, როგორც აღწერს Netgate-ის სტატიკური მარშრუტების გზამკვლევი. საილუსტრაციო განლაგებაში ტრანზიტული ბმული არის 192.168.77.1 ფაირვოლზე და 192.168.77.2 შიდა მარშრუტიზატორზე, ხოლო სერვისის ქსელი — 172.16.30.0/25 მის უკან. შემდეგ მარშრუტი ასახელებს პრეფიქსს და შემდეგ ნახტომს, და არა სერვისის მისამართს. შორეული ქსელის მისამართის კარიბჭედ გამოყენება გავრცელებული გზაა ისეთი მარშრუტის ასაგებად, რომელიც სწორად გამოიყურება და არსად გადასცემს.

ინტერფეისისთვის სახელის მიცემა არ აღწერს მის მიღმა არსებულ ქსელებს. სტატიკური მარშრუტი სწორედ ეს აღწერაა.

შორეულმა მხარემ უნდა იცოდეს აუზი

ქვედა მარშრუტიზატორს სჭირდება დაბრუნების მარშრუტი აუზისთვის, ამ მაგალითში 10.55.0.0/24 192.168.77.1-ის გავლით, თუ ნაგულისხმევი მარშრუტი ან დინამიკური პროტოკოლი უკვე არ იძლევა მას. სერვისის ჰოსტის საკუთარი კარიბჭე უნდა მიდიოდეს იმ მარშრუტიზატორისკენ, რაც ჩვეულებრივ მართალია, როცა მარშრუტიზატორი მისი ნაგულისხმევი კარიბჭეა, და მცდარი, როცა ჰოსტი ხელით იყო კონფიგურირებული. ფაირვოლზე პოლიტიკით მარშრუტიზაციამ შეიძლება გვერდი აუაროს ცხრილს კონკრეტული ტრაფიკისთვის, ამიტომ, სანამ დაასკვნით, რომ მარშრუტი არასწორია, შეამოწმეთ, ირჩევს თუ არა წესი სხვა კარიბჭეს.

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

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

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