ერთი LAN ქვექსელი გაატარე OpenVPN-ით და შეინარჩუნე ნაგულისხმევი მარშრუტი
შეინარჩუნე LAN-ის ნაგულისხმევი მარშრუტი, სანამ ერთი ქვექსელი გვირაბში გადის. შეადარე პოლიტიკის ცხრილი მთავარი ცხრილის ცვლილებებს, შემდეგ აირჩიე NAT ან მარშრუტი სერვერის მხარეს.
მოწყობილობები, რომლებიც LAN-ისთვის მარშრუტიზაციას აკეთებენ და ამავდროულად VPN-ს აკავშირებენ, საკუთარ თავთან ერთსა და იმავე კამათში ხვდებიან: გვირაბს სურს ნაგულისხმევი მარშრუტის ფლობა, და LAN-ს ის უკან სჭირდება. როცა OpenVPN უკავშირდება, მას შეუძლია დააყენოს ნაგულისხმევი მარშრუტი გვირაბის გავლით ან წყვილი ნახევრად-ნაგულისხმევი მარშრუტი, რაც სწორია ლეპტოპისთვის და არასწორია იმ კარიბჭისთვის, რომლის მეზობლები მისი LAN მისამართიდან პასუხებს ელოდებიან. პასუხი VPN-ის გამოტოვება არ არის. პასუხი ის არის, რომ ორ გადაწყვეტილებას სხვადასხვა ცხრილი მივცეთ.
ერთი ნაგულისხმევი მარშრუტი, ორი მფლობელი
გადამისამართებულ ტრაფიკსა და ლოკალურად წარმოქმნილ ტრაფიკს ერთი და იმავე გზის გავლა არ სჭირდება. LAN-ის კლიენტებს გვირაბი მხოლოდ თქვენ მიერ არჩეული დანიშნულებისთვის სჭირდებათ, ხოლო თვით ჰოსტის მართვის სესიებს და ამ კლიენტებისთვის გაგზავნილ პასუხებს LAN-ის ნაგულისხმევი მარშრუტი სჭირდება. ორივეს მთავარ ცხრილში შერევა ორ სხვადასხვა კითხვაზე ერთ პასუხს აძალებს.
OpenVPN-ს ზუსტად ამისთვის აქვს გადამრთველი. route-noexec ხელს უშლის კლიენტს მთავარ ცხრილს საერთოდ შეეხოს, და მნიშვნელობები, რომლებსაც გამოიყენებდა, ექსპორტირდება route-up სკრიპტში როგორც route_vpn_gateway, dev და ინტერფეისის მისამართები. შემდეგ თქვენ წყვეტთ, რომელი ცხრილი მიიღებს რომელ მარშრუტს, კოდში, რომელსაც მოგვიანებით წაიკითხავთ.
პოლიტიკის ცხრილი მთავარი ცხრილის გადაწერის წინააღმდეგ
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
ცალკე ცხრილი ერთადერთი ვარიანტია, რომელიც ერთ ქვექსელს სცდება. დაარქვი მას სახელი ერთხელ, შემდეგ მიმართე სახელით, რომ არავის მოუწიოს რიცხვის დამახსოვრება:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnაქ მოცემული მისამართები ჩანაცვლებითია. სანამ რამეს გაუშვებ, შეცვალე LAN-ის პრეფიქსი, გვირაბის კარიბჭე და მოწყობილობის სახელი შენი განლაგებიდან.
წესი ჰოსტსაც უნდა შეესაბამებოდეს
წესი, რომელიც მხოლოდ LAN-ის პრეფიქსს ემთხვევა, გადამისამართებულ პაკეტებს ფარავს. ის არ ფარავს ტრაფიკს, რომელსაც თვით კარიბჭე ქმნის, და არ ფარავს LAN-ის კლიენტებისთვის დაბრუნებულ პასუხებს, რომლებიც წყაროდ კარიბჭის LAN-ის მისამართს ატარებენ. ეს ძებნები main-ში ვარდება და მაინც შეიძლება გვირაბიდან გავიდეს.
დაამატე მეორე წესი კარიბჭის საკუთარი LAN-ის მისამართისთვის, ან გააფართოვე პირველი წესი სიმრავლემდე, რომელიც ორივეს მოიცავს. რიგი მნიშვნელოვანია: უფრო კონკრეტული წესი წინ დადე და შედეგი შეამოწმე ძებნით, რომელიც წყაროს ცხადად ასახელებს.
ip route get 203.0.113.9 from 192.168.50.1თუ ეს გვირაბის მოწყობილობას აჩვენებს იმ დანიშნულებისთვის, რომელიც ლოკალურად უნდა დარჩეს, წესების სიმრავლე მცდარია, მიუხედავად იმისა, რას შეიცავს ცხრილი.
NAT თუ მარშრუტი მოპირდაპირე მხარეს
VPN სერვერმა იცის გვირაბის ქვექსელი და სხვა არაფერი. LAN-ის წყაროს მისამართით მოსულ პაკეტებს დაბრუნების გზა არ აქვთ, თუ ვინმემ არ უზრუნველყო ის, და მის უზრუნველსაყოფად ზუსტად ორი გზა არსებობს. სერვერზე LAN-ის პრეფიქსისთვის მარშრუტის დამატება საწყის წყაროს ბოლომდე ხილულად ტოვებს, რაც აუდიტირებულ დიზაინს ჩვეულებრივ სურს. კარიბჭეზე ნიღბვა წყაროს გვირაბის მისამართზე გადაწერს და სერვერის თანამშრომლობას არ საჭიროებს.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEაირჩიე NAT, როცა სერვერს არ აკონტროლებ და იქ მარშრუტებს ვერ დაამატებ. აირჩიე მარშრუტი სერვერის მხარეს, როცა ჟურნალები, წვდომის კონტროლი ან დაბრუნების გზის სიმეტრია მნიშვნელოვანია, რადგან ნიღბვა შლის საწყის მისამართს ყველაფრიდან, რასაც მოპირდაპირე მხარე იწერს.
ნებისმიერ შემთხვევაში გადამისამართება ჩართული უნდა იყოს, და მკაცრმა უკუ-გზის ფილტრაციამ შეიძლება პასუხი ჩამოაგდოს, როცა main ამ წყაროსთვის გვირაბს არ აირჩევდა. გვირაბის დადანაშაულებამდე შეამოწმე ეფექტური მნიშვნელობა.
გახადე გაყოფა გამძლე ხელახალი დაკავშირების მიმართ
ხელით დამატებული წესები და მარშრუტები ქრება ინტერფეისის ხელახლა შექმნისას, და მოძველებულმა ცხრილის ჩანაწერმა შეიძლება იმ სესიაზე დიდხანს იცოცხლოს, რომელმაც ის გაამართლა. ჩასვი ცხრილის წესი, გვირაბის მარშრუტი და ნიღბვის ჩანაწერი კლიენტის route-up სკრიპტში და სკრიპტის დასაწყისში გაასუფთავე ცხრილი, რომ ძველმა კარიბჭემ ახალ სესიაში ვერ იცოცხლოს.
შეამოწმე ორივე ბოლოდან: ძებნა კარიბჭეზე LAN-ის წყაროთი, და რეალური მოთხოვნა LAN-ის კლიენტიდან დანიშნულებისკენ, რომელიც გვირაბში უნდა გაიაროს. მარშრუტი, რომელიც არსებობს, მაგრამ არასდროს აირჩევა, თავს ისე იქცევა, თითქოს მარშრუტი საერთოდ არ არის, სანამ მრიცხველებს წაიკითხავ.