OpenVPN-ის კლიენტები ერთმანეთს ვერ ხედავენ: subnet თუ net30?
კლიენტები სერვერს აღწევენ, მაგრამ ერთმანეთს არა. გაყავით ხარვეზი ერთი ping-ით, შემდეგ აირჩიეთ subnet ტოპოლოგია, client-to-client ან ხიდად ჩასმული TAP სეგმენტი.
ორი დაუკავშირებელი ხარვეზი ერთსა და იმავე საჩივარს იწვევს. პირველში ერთი კლიენტი მეორეს ვერც გვირაბის მისამართით აღწევს, რადგან მისამართები ერთ subnet-ში არ არიან ან სერვერი თანასწორთა შორის ტრაფიკს არ გადასცემს. მეორეში ping მუშაობს და აპლიკაციის მოწყობილობების სია ცარიელი რჩება, რადგან აღმოჩენა ეყრდნობა broadcast-ს, რომელსაც მე-3 დონის გვირაბი ვერ ატარებს. ერთი ping ჰყოფს მათ, და თითოეულის გამოსწორება სულაც არ ჰგავს მეორის გამოსწორებას.
ერთი ping ყოფს პრობლემას ორად
ერთი კლიენტიდან დაარეკეთ ping მეორის გვირაბის მისამართზე, არა მის სახელზე და არა მის LAN მისამართზე. თუ ეს ვერ მოხერხდა, პრობლემა გადაცემა ან მისამართებაა, და აღმოჩენა უადგილოა, სანამ ეს არ გამოსწორდება. თუ მოხერხდა, გადაცემა უკვე მუშაობს და დარჩენილი ხარვეზი broadcast ან სახელების ამოხსნაა.
ip addr show tun0უპირველეს ყოვლისა წაიკითხეთ კლიენტის ინტერფეისი, რადგან ქსელის ნიღაბი ასახელებს ტოპოლოგიას. /24 ან სხვა subnet ნიღაბი ნიშნავს საერთო აუზს; /30 თანასწორის მისამართით ნიშნავს ძველ წერტილ-წერტილ განლაგებას, სადაც თითოეულ კლიენტს ზუსტად ერთი მეზობელი ჰყავს, სერვერი.
net30 subnet-ის წინააღმდეგ, წაკითხული კლიენტის მხრიდან
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30-ის შემთხვევაში სერვერი გასცემს პატარა ბლოკს თითო კლიენტზე, ამიტომ მეორე კლიენტის გვირაბის მისამართზე მარშრუტი არ არსებობს, თუ სერვერი მას არ გადასცემს. subnet-ის შემთხვევაში მთელი აუზი ერთი ქსელია, ყოველ კლიენტს შეუძლია ყველას მიმართოს, და სერვერი მათ შორის გადასცემს. ამიტომ სერვერის ერთი კონფიგურაცია შეიძლება ჯანსაღად გამოიყურებოდეს, სანამ თანასწორთა შორის ping ვარდება: არაფერია გატეხილი, კლიენტები უბრალოდ ერთ ქსელში არ არიან. კლიენტი ხედავს მომუშავე კავშირს და უპასუხო თანასწორის მისამართს, რაც firewall-ად იკითხება, სინამდვილეში კი მისამართების განლაგებაა.
დირექტივის შეცვლა სერვერის მხრიდან რედაქტირება და გადატვირთვაა, და ეხება შემდეგ კავშირს და არა უკვე გახსნილ სესიებს. ხელახლა დაუკავშირეთ კლიენტები ცვლილების შეფასებამდე. თუ მოწყობილობა კონფიგურაციას ვებ ინტერფეისიდან ხელახლა აგენერირებს, ჩაწერეთ დირექტივა, ფაილი და თარიღი, და რედაქტირება ინტერფეისიდან გააკეთეთ, როცა ის არსებობს, რადგან გადაშენება ხელით რედაქტირებას შემდეგ შენახვაზე გადააწერს.
client-to-client ცალკე კარიბჭეა
ერთ subnet-ის შიგნითაც კი სერვერი აგდებს პაკეტებს, რომლებიც ერთი კლიენტიდან მოდის და მეორეზეა მიმართული, თუ client-to-client არ არის დაყენებული. ეს საკვანძო სიტყვა სერვერს თანასწორთა ტრაფიკის გადამცემად აქცევს, ნაცვლად მხოლოდ მიმღები ბოლო წერტილისა. ეს არის მეორე პირობა, რომელსაც ადამიანები ტოპოლოგიის გამოსწორების შემდეგ გამოტოვებენ.
ეს არ ვრცელდება broadcast-ზე. პარამეტრი unicast-ს გადასცემს კლიენტებს შორის; ის გვირაბს საერთო სეგმენტად არ აქცევს, და მისი არც ერთი რაოდენობა multicast აღმოჩენის მოთხოვნას ყველა თანასწორს არ მიაწვდის.
TUN TAP-ის წინააღმდეგ, და რისი ტარება შეუძლია თითოეულს
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap მოწყობილობის LAN-ში ხიდად ჩასმა დისტანციურ კლიენტებს ოფისის broadcast დომენში ათავსებს, რაც აღმოჩენას სრულად წყვეტს. ფასია პლატფორმები, რომლებიც TAP-ს არ ახორციელებენ, სერვერზე აუცილებელი ხიდი, და მარცხის დომენი, სადაც ოფისის კაბელზე broadcast ქარიშხალი ყველა დისტანციურ ლეპტოპს აღწევს.
ორი ან სამი სამუშაო სადგურისთვის, რომლებსაც სახელების ამოხსნა სჭირდებათ, hosts ჩანაწერი ან unicast მისამართი გაცილებით იაფია ხიდზე. TAP-ს მიმართეთ მაშინ, როცა პროტოკოლი, რომელსაც ვერ შეცვლით, მე-2 დონის აღმოჩენაზეა დამოკიდებული, და არა ადრე.
იმავე subnet-ის კლიენტები ხიდის გარეშე
LAN დიაპაზონიდან მისამართის მიცემა კლიენტს კაბელზე არ აყენებს. სერვერი გვირაბსა და Ethernet-ს შორის მარშრუტიზაციას აკეთებს, ამიტომ ამ მისამართის ARP სერვერის ინტერფეისზე ჩერდება და LAN-ის დანარჩენი ვერასოდეს შეიტყობს, სად ცხოვრობს.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ამ ხარვეზს ხურავს: სერვერი კლიენტის ნაცვლად პასუხობს. დიაპაზონისთვის parpd ჩანაწერებს მართავს, სანამ კლიენტები მოდიან და მიდიან, ხოლო sysctl net.ipv4.conf.eth0.proxy_arp=1 პასუხობს ყველაფერზე, რაც სხვაგან მარშრუტირდება, რაც საკმარისად ფართოა, რომ დატვირთულ სეგმენტზე საკუთარი სიურპრიზები შექმნას.
რომელი გზაც არ უნდა აირჩიოთ, მოხსენით NAT გვირაბსა და კაბელს შორის. MASQUERADE წესი ზუსტად იმ მისამართების კითხვას მალავს, რომელზეც პასუხის გაცემას ცდილობთ. ის ასევე შემდეგ ადამიანს ტოვებს ტოპოლოგიას, რომელზეც ის კლიენტის მხრიდან ვერ იმსჯელებს.
სანამ რამეს შეცვლით, დაიჭირეთ ერთი ცდა სერვერზე tcpdump -ni tun0-ით და დაადასტურეთ, საერთოდ მოდის თუ არა თანასწორის პაკეტი. მოსვლა და გადაგდება client-to-client-ზე მიუთითებს; არასოდეს მოსვლა ტოპოლოგიაზე ან მარშრუტიზაციაზე. OpenVPN 2.6-ის სახელმძღვანელო აღწერს ორივე საკვანძო სიტყვას და ნაგულისხმევ ტოპოლოგიას, რაც ღირს თქვენს ვერსიასთან შედარება ფორუმის პოსტიდან სტრიქონის კოპირებამდე.
- tun ინტერფეისი აუზის ნიღაბს აჩვენებს და არა /30 თანასწორთა წყვილს.
- პირდაპირი ping მეორე გვირაბის მისამართზე წარმატდება აღმოჩენის შემოწმებამდე.
- სერვერის კონფიგურაცია შეიცავს
client-to-client-ს, როცა თანასწორებმა პაკეტები უნდა გაცვალონ. - დაასახელეთ ის აღმოჩენის პროტოკოლი, რომელსაც ამოწმებთ, იმის ნაცვლად რომ თქვათ, აპლიკაცია ვარდება.
- TAP გამოიყენეთ მხოლოდ მაშინ, როცა ჯგუფის ყველა კლიენტის პლატფორმა მხარს უჭერს მას.
- NAT მოარიდეთ გვირაბსა და LAN-ს შორის გზას, როცა იმავე subnet-ში ხელმისაწვდომობა მნიშვნელოვანია.