როგორ ხდება NAT-ის უკან მყოფი OpenVPN კლიენტი ინტერნეტის გასასვლელი

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

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

ორი სატრანსპორტო სესია, ერთი შიდა გზა

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

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

რას ამონტაჟებს iroute სინამდვილეში სერვერის შიგნით

ჰაბი ერთადერთი მოწყობილობაა, რომელიც წყვეტს, რომელი პარტნიორი რომელ დანიშნულებას ფლობს, და ამ გადაწყვეტილებას თავისივე მომხმარებლის სივრცის მარშრუტიზაციის ცხრილში იღებს, არა ბირთვისაში. გასასვლელისთვის exit-node სახელის მქონე client-config-dir ჩანაწერს შეუძლია იქ ნაგულისხმევი პრეფიქსი მოითხოვოს:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

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

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

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

გადაცემას გასასვლელის ბირთვი აკეთებს

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

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

დაბრუნების გზას წყაროს თარგმანი ყიდულობს

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

სად შეიძლება ჰაბმა დანერგოს და სად არა

client-to-client-ით და ტრადიციული მომხმარებლის სივრცის მონაცემთა გზით ჰაბი შიდა პაკეტებს პარტნიორებს შორის სერვერის პროცესის შიგნით გადასცემს. ისინი არასოდეს გაივლიან ჰაბის ბირთვის FORWARD ჯაჭვს, ამიტომ იქაური ბირთვის წესი ვერ შეზღუდავს პარტნიორებს შორის გავლას, რაც არ უნდა ფრთხილად იყოს დაწერილი. აღსრულება სერვერის საკუთარ პოლიტიკაში უნდა ცხოვრობდეს: ვის შეუძლია დაკავშირება, რომელ CCD ფაილს იღებს და საერთოდ ენიჭება თუ არა გასასვლელის ნაგულისხმევი საკუთრება.

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

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

უსაფრთხო მარცხი, როცა გასასვლელი ქრება

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

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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