ddclient აქვეყნებს VPN-ის გასასვლელს: გაასწორეთ აღმოჩენის წყარო

თქვენი DNS სახელი ახლა VPN პროვაიდერის მისამართზე იხსნება, და განახლების ჟურნალი სრულიად ჯანმრთელად გამოიყურება. ეს შერწყმა ნორმალურია. ვებ-დაფუძნებული აღმოჩენის პრობი გარე სერვისს ეკითხება, რომელ წყაროს ხედავს, და როცა მოთხოვნა სრული გვირაბის VPN-ით გადის, პასუხი VPN-ის გასასვლელია და არა თქვენი სახლის WAN მისამართი. განმაახლებელმა თავისი საქმე გააკეთა; საქმე არასწორ დაკვირვებაზე იყო მიმართული.

დაადასტურეთ, რას უნდა მიაღწიოს სახელმა

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

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

ინტერფეისის მისამართებსაც ინტერპრეტაცია სჭირდება. სახლის როუტერის უკან მდგარი ლეპტოპის მისამართი საჯარო WAN მისამართი არ არის, და როუტერის WAN მისამართიც კი შეიძლება ოპერატორის NAT-ის უკან იყოს, სადაც მისი გამოქვეყნება შემომავალ ხელმისაწვდომობას ვერ შექმნის.

გაამრავლეთ მნიშვნელობა სანამ რამეს შეცვლით

დააკვირდით ორ გზას ცალ-ცალკე. გვირაბის ჩართვისას პრობი გასასვლელს აცხადებს; გვირაბის გამორთვისას, ან პრობის ფიზიკურ ინტერფეისზე მიბმისას, ის სახლის მისამართს აცხადებს: curl --interface eth0 https://ifconfig.me. თუ ეს ორი პასუხი განსხვავდება, თქვენ ხარვეზი გაამრავლეთ განმაახლებელზე ხელის შეუხებლად.

შემდეგ გაუშვით კლიენტი რეჟიმში, რომელიც კონფიგურაციას ამოწმებს განახლების შესრულების გარეშე, მაგალითად ddclient -verbose -noexec, და წაიკითხეთ, რომელი აღმოჩენის მეთოდი აირჩია. დეტალური გამოტანა ასახელებს მეთოდს და მიღებულ მნიშვნელობას, და ეს არის ის ფაქტი, რომელიც რედაქტირებამდე გჭირდებათ.

მიმართეთ აღმოჩენა არჩეულ გზაზე

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

როუტერის სტატუსის გზისთვის, ახალი ddclient გამოშვებები იყენებენ usev4 და fwv4 ოპციების ოჯახს, გვერდის მიმდებარე ტექსტისთვის სურვილისამებრ გამოტოვების ნიმუშით. შეამოწმეთ თქვენი დაყენებული ვერსიის README, რადგან ძველი გამოშვებები იმავე იდეას use და fw-ით წერენ, და არასწორი გამოშვებიდან კოპირებული ოპციის სახელი გაშვებისას ვარდება.

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

საიდუმლოებები და ვერსიები წესრიგში გქონდეთ

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

ddclient README აღწერს აღმოჩენის მიდგომებს და მათი ოპციების სახელებს. არ აურიოთ IPv4 და IPv6 შედეგები ერთ ჩანაწერში, და არ ჩათვალოთ, რომ ერთ გამოშვებაში არსებული ოპცია მეორეშიც არსებობს.

შეამოწმეთ მნიშვნელობა, შემდეგ ხელმისაწვდომობა

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

მხოლოდ მას შემდეგ, რაც ჩანაწერი სწორია, უნდა გამოსცადოთ შემომავალი სერვისი დამოუკიდებელი ქსელიდან, საჭირო ფაირვოლი და გადამისამართება უკვე დამტკიცებული. სწორი A ჩანაწერი არ ამტკიცებს ხელმისაწვდომ სერვისს, და სტატიკური VPN იჯარა შეიძლება ამარტივებდეს კერძო სახელდებას, არასწორ WAN-ზე მიმანიშნებელი საჯარო ჰოსტის სახელის გასწორების გარეშე.