Dev Container ვერ აღწევს მხოლოდ VPN-ით ხელმისაწვდომ ჰოსტამდე: სად უნდა ვეძებოთ

პირადი API იხსნება თქვენი სამუშაო მაგიდის ბრაუზერში და მარცხდება განვითარების კონტეინერში. ეს წინააღმდეგობა არ არის და იშვიათად თავად VPN არის მიზეზი. ბრაუზერის მოთხოვნა და წარუმატებელი მოთხოვნა სხვადასხვა პროცესმა გაგზავნა, სხვადასხვა resolver-ებით, proxy-ებით და მარშრუტებით, და ხშირად სრულიად სხვადასხვა ქსელური სახელების სივრციდან. „ჩემს ლეპტოპზე“ შეიძლება ნიშნავდეს Windows-ის ჰოსტს, WSL-ის დისტრიბუციას, Docker Desktop-ის ვირტუალურ მანქანას და კონტეინერს იმ VM-ის შიგნით — ოთხი კონტექსტი, რომელთაგან თითოეულს ერთი და იმავე ჰოსტის სახელზე სხვადასხვა პასუხი შეუძლია გასცეს. სანამ ერთ პარამეტრსაც შეეხებით, დაადგინეთ, რომელს იყენებს წარუმატებელი პროცესი.

იპოვეთ პროცესი, სანამ პარამეტრს შეცვლით

დაიწყეთ კონტეინერის ძრავით და არა VPN კლიენტით. ჰკითხეთ, რომელ კონტექსტს ესაუბრება ბრძანების ხაზი და რომელ ოპერაციულ სისტემაზე მუშაობს ეს ძრავა, რადგან სამუშაო მაგიდის VM-ის მიერ მართული Linux კონტეინერი სხვა გზას გადის, ვიდრე ადგილობრივი daemon-ის მიერ მართული:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows-ზე wsl -l -v გეუბნებათ, მუშაობს თუ არა დისტრიბუცია WSL 2-ის ქვეშ, რაც მას საკუთარი ვირტუალური კომუტატორის უკან აყენებს. ეს დეტალი წყვეტს, ჰოსტის მარშრუტიზაციის ცხრილს იზიარებს კონტეინერი თუ ზის NAT-ის უკან, რომელსაც ჰოსტამდე მისასვლელად გადამისამართებული პორტი ან ჰოსტის სახელი სჭირდება.

ერთი მოთხოვნა მუდმივად შეინახეთ და შეადარეთ

აირჩიეთ ერთი უვნებელი საბოლოო წერტილი პირად ჰოსტზე და გამოიყენეთ იგი ყოველი შედარებისთვის: ბრაუზერიდან, ჰოსტის ტერმინალიდან, WSL-ის დისტრიბუციიდან და კონტეინერის შიგნიდან. ყოველი ცდისთვის ჩაწერეთ ოთხი რამ: ამოხსნილი მისამართი, გამოიყენეს თუ არა proxy, მარცხის კლასი და გასული დრო. სახელის ძიება, კავშირის დამყარება, TLS-ის ვალიდაცია და HTTP სტატუსი ოთხი განსხვავებული პრობლემაა და მათი „არ მუშაობს“-ში შერევა მთელ დილას ფლანგავს.

შედარება ჩაატარეთ წარუმატებელი კონტეინერის შიგნით, დროის ლიმიტით, რომ ჩუმმა firewall-მა ტერმინალი წუთობით არ დააკავოს. ახალი კონტეინერი ამრავლებს ძრავის ქსელურ კონტექსტს, მაგრამ არა აპლიკაციის კონტეინერის სახელთა სივრცეს, proxy ცვლადებს ან resolver-ს, ამიტომ docker exec რეალურ კონტეინერში ავტორიტეტული ტესტია, ხოლო გვერდითი კონტეინერი მხოლოდ იმის იზოლირების გზაა, განსხვავება ძრავშია თუ კონტეინერში:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine-ის საბაზისო იმიჯს busybox აქვს და curl არ აქვს, და სწორედ ასეთი დეტალი ამარცხებს კოპირებულ დიაგნოსტიკურ ბლოკს: აირჩიეთ იმიჯი კლიენტით, ან დაამატეთ იგი იმავე გაშვებაში. უკავშირო საჯარო საიტებთან შედარება არაფერს არ აცალკევებს. თუ https://example.com კონტეინერიდან მუშაობს, თქვენ ისწავლეთ, რომ კონტეინერს ინტერნეტზე წვდომა აქვს და არაფერი იმის შესახებ, აღწევს თუ არა ის პირად მისამართს გვირაბის გავლით. ანალოგიურად, ახალი ტერმინალის გახსნა მხოლოდ იმას ამტკიცებს, რომ ახალი ტერმინალი მუშაობს და არა იმას, რომ ის წარუმატებელ აპლიკაციასთან ერთსა და იმავე გაშვების გარემოს იზიარებს.

Docker Desktop-ს VPN-თან მუშაობა შეუძლია

Docker-ის საკუთარი დოკუმენტაცია VPN-ისა და ჰოსტთან დაკავშირების შესახებ ამას მხარდაჭერილ კონფიგურაციად აღწერს და გულწრფელი შეჯამებაა, რომ ის მუშაობს და არა ავტომატურად გატეხილია. ნუ ჩათვლით, რომ სამუშაო მაგიდის VM დიზაინით გვერდს უვლის ჰოსტის გვირაბს; ბევრ კონფიგურაციაში ტრაფიკი სწორად მიჰყვება ჰოსტის გვირაბს და სწორედ ამიტომ „Docker უგულებელყოფს VPN-ს“ ლეგენდა თავდაჯერებულ და არასწორ რჩევებს წარმოშობს.

რაც კვლავ მნიშვნელოვანია, არის გამოყენებული backend, კლიენტის split-tunnel პოლიტიკა და ის resolver კონფიგურაცია, რომელიც VM-მა მიიღო. VPN კლიენტი, რომელიც მარშრუტებს აყენებს, მაგრამ არა DNS-ს, ან უბიძგებს DNS სერვერს, რომელსაც VM ვერ აღწევს, სახელის ძიების მარცხს იწვევს კონტეინერის შიგნით, მაშინ როცა ჰოსტი მუშაობს, რადგან მას დამატებითი resolver ან ქეშირებული პასუხი აქვს. ეს resolver-ის პრობლემაა კონტეინერის კოსტიუმში. ის გადაურჩება VPN-ის ყოველ ხელახალ დაკავშირებას, რომელსაც ცდით, რადგან გვირაბი უკვე ატარებს იმ ტრაფიკს, რომლის ტარებაც სთხოვეთ.

მისამართების გადაფარვა და MTU სხვადასხვა მარცხია

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

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

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

Proxy კონფიგურაცია პროცესის მიხედვითაა და არა მანქანის

კონტეინერის შიგნით localhost ამ კონტეინერის საკუთარ ქსელურ კონტექსტს ასახელებს, ამიტომ ჰოსტზე მომუშავე proxy იქ ამ სახელით ხელმისაწვდომი არ არის. Docker Desktop ჰოსტზე წვდომისთვის გთავაზობთ host.docker.internal-ს, ხოლო Linux-ზე თქვენ მას ცხადად ამატებთ --add-host=host.docker.internal:host-gateway-ით. ყოველ შემთხვევაში, ეს სახელი გაძლევთ მარშრუტს ჰოსტამდე; ის proxy სერვისს არ ქმნის და მისი გამოყენების უფლებასაც არ გაძლევთ.

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

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