Docker-ისა და VM-ის ტრაფიკი OpenVPN-ის უკან: მარშრუტი თუ გადანომვლა?

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

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

ორი ხარვეზი, რომლებიც ერთნაირად გამოიყურება

პირველი დაბრუნების გზის პრობლემაა. გამოქვეყნებული პორტი კონტეინერში გადაითარგმნება, მოთხოვნა მოდის და პასუხი ჰოსტის ნაგულისხმევი მარშრუტით იგზავნება, რომელიც OpenVPN კლიენტს tun0-ზე აქვს მიმართული. პასუხი გამოდის მისამართიდან, რომელსაც დისტანციური მხარე არ ელოდება, და ის უგულებელყოფილია. მეორე პრეფიქსების შეჯახებაა: Docker-ის ნაგულისხმევი ხიდი ფლობს 172.17.0.0/16-ს, ხოლო კორპორატიული გვირაბი იმავე დიაპაზონს უბიძგებს.

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

გადაწყვიტე სამი კითხვით

კითხვა პირველი: ქრება ხარვეზი, როცა VPN-ს აჩერებ? თუ გვირაბის გამორთვისას ყველაფერი მუშაობს, დაბრუნების გზა ეჭვქვეშ დააყენე. კითხვა მეორე: გვიჩვენებს ip route show table all იგივე პრეფიქსს ორჯერ, ერთხელ ხიდზე და ერთხელ tun0-ზე? ეს არის შეჯახება. კითხვა მესამე: დაზარალებული მისამართი კონტეინერია, NAT სტუმარი თუ ხიდით დაკავშირებული სტუმარი?

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

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

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

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

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

დაადასტურე ip route get 1.1.1.1 from 172.22.0.3-ით. პასუხმა ხიდის ინტერფეისი უნდა დაასახელოს, და არა tun0. ასე დამატებული წესები გადატვირთვისას ქრება, ამიტომ ჩაწერე ისინი იმ unit-ში ან ქსელურ კავშირში, რომელიც კონტეინერს ფლობს.

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

პრეფიქსების შეჯახება: გადანომრე ხიდი

მარშრუტების ცხრილი ერთ პრეფიქსს ერთ ადგილას აგზავნის. თუ VPN 172.17.0.0/16-ს უბიძგებს, ხოლო Docker-ის ხიდი უკვე იქ არის, იმარჯვებს უფრო დაბალი მეტრიკა: Docker თავის დაკავშირებულ მარშრუტს მეტრიკა 0-ზე აყენებს, ხოლო უბიძგებული მარშრუტი 50-ზე მოდის. მაშინ გვირაბი გატეხილად გამოიყურება, სანამ Docker აგრძელებს მუშაობას, ან პირიქით, დაყენების რიგის მიხედვით. გადანომრე ხიდი მეტრიკასთან ბრძოლის ნაცვლად.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

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

VM-ებს ისევ სხვა პასუხი სჭირდებათ

ნაგულისხმევ NAT ქსელში მყოფი libvirt სტუმარი ჰოსტის მარშრუტიზაციას იმკვიდრებს და გარეთ გასვლას წყვეტს, როგორც კი ჰოსტის გვირაბი ნაგულისხმევ მარშრუტს დაიკავებს. სტუმრის ხიდზე ან macvtap მოწყობილობაზე გადაყვანა მას ფიზიკურ ქსელში საკუთარ გზას აძლევს. virt-manager-ში დაამატე ტექნიკა, აირჩიე Network, წყაროდ დააყენე macvtap ჰოსტის მოწყობილობა, მოდელად დატოვე virtio, შემდეგ გამორთე ძველი NAT ინტერფეისი.

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

სტუმრისთვის, რომელსაც მხოლოდ ჰოსტის LAN სჭირდება, გამყიდველის კლიენტს შეიძლება ჰქონდეს დაკარგული გადამრთველი: Mullvad-ის შემთხვევაში mullvad lan set allow აღადგენს ლოკალურ ხელმისაწვდომობას libvirt-ზე ხელის შეუხებლად. ხოლო როცა კონტეინერი მხოლოდ გვირაბით უნდა იყოს ხელმისაწვდომი, მიამაგრე გამოქვეყნებული პორტი გვირაბის მისამართს, -p 10.8.0.5:8080:8080, ყოველ მისამართზე გამოქვეყნების ნაცვლად.