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

net30-ში ეს ველი თანამზრახველის მისამართია; subnet-ში — ქვექსელის ნიღაბი. ორი ფორმა ალტერნატივაა, არასდროს მიმდევრობა.

ორი ფორმა, გვერდიგვერდ

ტრადიციულ net30 განლაგებაში თითოეულ კლიენტს აქვს /30 ბლოკი: ქსელის მისამართი, ორი გამოსაყენებელი მისამართი და მაუწყებლობის მისამართი. ifconfig-push იღებს კლიენტის მისამართსა და თანამზრახველის მისამართს, ხოლო თანამზრახველი იმავე ბლოკის მეორე გამოსაყენებელი მისამართია, რომელსაც წერტილ-წერტილ კავშირის სერვერის მხარე იყენებს.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

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

ბლოკში ორივე ხაზი ცალკე ხაზია CCD ფაილისთვის. თითოეული კლიენტი იღებს ზუსტად ერთ მათგანს.

წაიკითხეთ ტოპოლოგია, რომელსაც სერვერი რეალურად ატარებს

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

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

ფიქსირებული მისამართი დინამიკური აუზის გარეთ შეინახეთ

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

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

სერვერი 10.99.0.1-ს იღებს თავისთვის, და ფიქსირებული კლიენტის მისამართი აუზის დიაპაზონს გარეთ რჩება. CCD ფაილი სახელდება კლიენტის ეფექტური იდენტობის მიხედვით და არა პროფილის ფაილის სახელით, და დამატებით გაფართოებას არ იღებს. თუ username-as-common-name აქტიურია, ავთენტიფიცირებული მომხმარებლის სახელია ის იდენტობა, რომელიც უნდა დაემთხვას. ორი მოწყობილობა, რომლებიც ერთ იდენტობას იზიარებენ, ფიქსირებულ მისამართსაც გაიზიარებენ, რაც პოლიტიკის და არა მარშრუტიზაციის პრობლემაა.

გადაამოწმეთ განაწილება, რომელიც კლიენტმა რეალურად მიიღო

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

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

დაკავშირებული სტატიები