ddclient publicē VPN izeju: izlabojiet atklāšanas avotu

Jūsu DNS vārds tagad atrisinās uz VPN pakalpojumu sniedzēja adresi, un atjaunināšanas žurnāls izskatās pilnīgi veselīgs. Šī kombinācija ir normāla. Tīmekļa atklāšanas zonde jautā ārējam servisam, kādu avotu tas redz, un, kad pieprasījums iziet caur pilna tuneļa VPN, atbilde ir VPN izeja, nevis jūsu mājas WAN adrese. Atjauninātājs izdarīja savu darbu; darbs bija vērsts uz nepareizu novērojumu.

Apstipriniet, ko vārdam jāsasniedz

Publiskam ienākošā mājas pakalpojuma vārdam vajadzīga adrese, pa kuru apstiprināti ienākošie savienojumi var sasniegt šo pakalpojumu. Koplietota pakalpojumu sniedzēja izejas publicēšana tur neiekārto ienākošo pāradresāciju, un neviena DNS konfigurācija neveido šo pāradresāciju. Izlemiet to pirms atjauninātāja aizskaršanas, jo tas nosaka, kura adrese ir pareiza.

Privāts nosaukums VPN klienta tuneļa adresei ir cita problēma ar citu atbildi: tas pieder privātajam DNS, un tam vispār nav vajadzīgs publisks atklāšanas serviss. Abu prasību sajaukšana ir veids, kā strādājoša konfigurācija sāk publicēt adresi, kuru neviens nav lūdzis.

Arī saskarnes adresēm vajadzīga interpretācija. Portatīvā datora adrese aiz mājas maršrutētāja nav publiskā WAN adrese, un pat maršrutētāja WAN adrese var atrasties aiz operatora NAT, kur tās publicēšana nevar nodrošināt ienākošu sasniedzamību.

Atkārtojiet vērtību pirms kaut kā maiņas

Vērojiet abus ceļus atsevišķi. Kad tunelis ir ieslēgts, zonde ziņo izeju; kad tunelis ir izslēgts vai zonde ir piesaistīta fiziskajai saskarnei, tā ziņo mājas adresi: curl --interface eth0 https://ifconfig.me. Ja šīs divas atbildes atšķiras, jūs esat atkārtojuši kļūmi, nepieskaroties atjauninātājam.

Pēc tam palaidiet klientu režīmā, kas pārbauda konfigurāciju, neveicot atjaunināšanu, piemēram, ddclient -verbose -noexec, un izlasiet, kuru atklāšanas metodi tas izvēlējās. Detalizētā izvade nosauc metodi un iegūto vērtību, un tas ir fakts, kas jums vajadzīgs pirms jebkuras rediģēšanas.

Novirziet atklāšanu uz izvēlēto ceļu

Ja vārdam jāpublicē mājas WAN adrese, atklāšanai jāvēro tieši šī adrese. Darbojas trīs iespējas, aptuvenā priekšrocību secībā: ļaujiet maršrutētājam publicēt ar savu atbalstīto atjauninātāju; izmantojiet ddclient maršrutētāja statusa atklāšanu pret lapu, kuru maršrutētājs patiešām apkalpo; vai saglabājiet tīmekļa zondi, bet piesaistiet to fiziskajai saskarnei, lai tā izietu ārpus tuneļa.

Maršrutētāja statusa ceļam jaunāki ddclient izdevumi izmanto usev4 un fwv4 opciju saimi, ar neobligātu izlaišanas modeli apkārtējam lapas tekstam. Pārbaudiet sava instalētā izdevuma README, jo vecāki izdevumi to pašu ideju raksta ar use un fw, un no nepareizā izdevuma kopēts opcijas nosaukums neizdodas startēšanas laikā.

Ja paturat tīmekļa atklāšanu, atcerieties, ka zondes maršrutēšana un atjaunināšanas API izsaukuma maršrutēšana ir atsevišķi lēmumi. Atjaunināšanas izsaukums piegādā ierakstu; zonde nosaka piegādājamo vērtību.

Turiet noslēpumus un versijas kārtībā

Maršrutētāja akreditācijas dati un pakalpojumu sniedzēja pilnvaras pieder aizsargātā konfigurācijas failā, nevis komandrindā, kas nonāk shell vēsturē. Detalizētas pēdas var saturēt abus, tāpēc izdzēsiet tos pirms ielīmēšanas pieteikumā. Atklāšanas metodei, kas prasa autentificētas maršrutētāja lapas skrāpēšanu, arī jānodrošina, ka šie akreditācijas dati darbojas arī pēc programmaparatūras atjauninājumiem. Glabājiet tos ar tādu pašu rūpību kā pakalpojumu sniedzēja pilnvaru.

ddclient README dokumentē atklāšanas pieejas un to opciju nosaukumus. Nejauc IPv4 un IPv6 rezultātus vienā ierakstā un nepieņem, ka vienā izdevumā esoša opcija pastāv citā.

Pārbaudiet vērtību, pēc tam sasniedzamību

Pirms atļaut tiešu atjaunināšanu salīdziniet ierosināto adresi ar paredzēto galapunktu, pēc tam pēc vienas atļautas atjaunināšanas pārbaudiet autoritatīvo DNS un ņemiet vērā risinātāju kešatmiņas. Zems TTL saīsina gaidīšanu; tas nepadara nepareizu vērtību pareizu.

Tikai pēc tam, kad ieraksts ir pareizs, jums jāpārbauda ienākošais pakalpojums no neatkarīga tīkla, kad nepieciešamais ugunsmūris un pāradresācija jau apstiprināta. Pareizs A ieraksts nepierāda sasniedzamu pakalpojumu, un statiska VPN nomā var vienkāršot privātu nosaukumu piešķiršanu, nelabojot publisku resursdatora nosaukumu, kas norāda uz nepareizo WAN.