VPN სახელთა სივრცეში მყოფი აპლიკაცია LAN-იდან მიუწვდომელია

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

რატომ არაფერი პასუხობს LAN-ის მისამართზე

სახელთა სივრცე სრული ქსელური დასტაა: ინტერფეისები, მარშრუტები, firewall-ის წესები და პირადი loopback. ip netns exec-ის მეშვეობით გაშვებული პროცესი მხოლოდ ამ დასტას ხედავს და სხვა არაფერს, ამიტომ მისამართი, რომელზეც ის იკავშირებს, მხოლოდ სახელთა სივრცის შიგნით იხსნება. თავად ჰოსტის 127.0.0.1 სრულიად სხვა loopback-ია.

ამიტომ curl ჰოსტზე ვერ სრულდება, მაშინ როცა იგივე ბრძანება სახელთა სივრცის შიგნით წარმატებით მუშაობს. აპლიკაცია ჯანმრთელია; მისამართი უბრალოდ არ არსებობს ჰოსტის დასტაში.

გამოაქვეყნეთ ერთი პორტი socat ნახტომით

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

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

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

გამოიყენეთ veth წყვილი, როცა ერთზე მეტი პორტი გადის

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

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

ნუ დაამატებთ ნაგულისხმევ მარშრუტს ჰოსტის გავლით, თუ ციხის გატეხვას არ აპირებთ. გვირაბი უნდა დარჩეს გასასვლელად, ამიტომ წყვილის გავლით მხოლოდ გამოქვეყნებული სერვისის მისამართია ხელმისაწვდომი. მიეცით სახელთა სივრცეს საკუთარი resolver ფაილიც, რადგან ip netns exec კითხულობს /etc/netns/vpn/resolv.conf-ს და მის გარეშე ციხის შიგნით სახელების გარჩევა ცარიელია.

გამოსცადეთ სხვა მანქანიდან, არა ჰოსტიდან

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

ip netns exec vpn ss -lntp

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