ddclient avaldab VPN-väljundi: parandage avastamisallikas
Veebipäring teatab aadressi, mida see näeb, seega täistunneliga VPN võib avaldada teenusepakkuja väljundi. Valige esmalt lõpp-punkt ja seejärel sobitage avastamine sellega.
Teie DNS-nimi laheneb nüüd VPN-teenusepakkuja aadressiks ja värskenduslogi näeb täiesti terve välja. See kombinatsioon on tavaline. Veebipõhine avastamispäring küsib väliselt teenuselt, millist allikat see näeb, ja kui päring väljub täistunneliga VPN-i kaudu, on vastuseks VPN-i väljund, mitte teie kodu WAN-aadress. Värskendaja tegi oma töö; töö oli suunatud vale vaatluse peale.
Kinnitage, mida nimi peaks saavutama
Sissetuleva koduteenuse avalik nimi vajab aadressi, mille kaudu heakskiidetud sissetulevad ühendused jõuavad selle teenuseni. Jagatud teenusepakkuja väljundi avaldamine ei korralda seal sissetulevat edasisaatmist ja ükski DNS-i seadistus ei loo seda edasisaatmist. Otsustage see enne, kui värskendajat puudutate, sest see määrab, milline aadress on õige.
VPN-i kliendi tunneliaadressi privaatnimi on teine probleem teise vastusega: see kuulub privaatsesse DNS-i ja ei vaja üldse avalikku avastamisteenust. Kahe nõude segamine on viis, kuidas toimiv seadistus hakkab avaldama aadressi, mida keegi ei küsinud.
Ka liidese aadressid vajavad tõlgendamist. Koduruuteri taga olev sülearvuti aadress ei ole avalik WAN-aadress ja isegi ruuteri WAN-aadress võib olla operaatori NAT-i taga, kus selle avaldamine ei saa anda sissetulevat kättesaadavust.
Taastage väärtus enne, kui midagi muudate
Jälgige kahte teed eraldi. Tunneli töötamisel teatab päring väljundi; tunneli väljalülitamisel või päringu sidumisel füüsilise liidesega teatab see kodu aadressi: curl --interface eth0 https://ifconfig.me. Kui need kaks vastust erinevad, olete rikke taastanud, ilma värskendajat puudutamata.
Seejärel käivitage klient režiimis, mis kontrollib seadistust ilma värskendust tegemata, näiteks ddclient -verbose -noexec, ja lugege, millise avastamismeetodi see valis. Üksikasjalik väljund nimetab meetodi ja saadud väärtuse ning see on tõsiasi, mida enne mis tahes muudatust vajate.
Suunake avastamine valitud teele
Kui nimi peab avaldama kodu WAN-aadressi, peab avastamine jälgima just seda aadressi. Toimivad kolm valikut, ligikaudses eelistuse järjekorras: las ruuter avaldab oma toetatud värskendaja kaudu; kasutage ddclienti ruuteri oleku avastamist lehe vastu, mida ruuter tegelikult serveerib; või jätke veebipäring alles, kuid siduge see füüsilise liidesega, et see väljuks tunnelist väljapoole.
Ruuteri oleku tee jaoks kasutavad uuemad ddclienti väljaanded valikute perekonda usev4 ja fwv4, valikulise vahelejätmismustriga ümbritseva leheteksti jaoks. Kontrollige paigaldatud versiooni README-d, sest vanemad väljaanded kirjutavad sama idee kujul use ja fw ning vale väljaande juurest kopeeritud valiku nimi ebaõnnestub käivitamisel.
Kui jätate veebiavastamise alles, pidage meeles, et päringu marsruutimine ja värskenduse API-kutse marsruutimine on eraldi otsused. Värskenduskutse toimetab kirje kohale; päring otsustab, milline väärtus toimetatakse.
Hoidke saladused ja versioonid korras
Ruuteri mandaadid ja teenusepakkuja tokenid kuuluvad kaitstud seadistusfaili, mitte käsureale, mis jõuab shelli ajalukku. Üksikasjalikud jäljed võivad sisaldada mõlemat, seega redigeerige need enne pileti sisse kleepimist. Avastamismeetod, mis nõuab autenditud ruuteri lehe kraapimist, nõuab ka seda, et hoiaksite selle mandaadi töös ka püsivara uuenduste järel. Hoidke seda sama hoolega nagu teenusepakkuja tokenit.
ddclient README dokumenteerib avastamislähenemised ja nende valikute nimed. Ärge segage IPv4 ja IPv6 tulemusi ühes kirjes ega eeldage, et ühes väljaandes olev valik on olemas teises.
Kontrollige väärtust, seejärel kättesaadavust
Võrrelge pakutud aadressi kavandatud lõpp-punktiga enne reaalajas värskenduse lubamist, seejärel kontrollige autoriteetset DNS-i pärast ühte lubatud värskendust ja arvestage lahendajate vahemäludega. Madal TTL lühendab ootust; see ei tee valest väärtusest õiget.
Alles siis, kui kirje on õige, peaksite katsetama sissetulevat teenust sõltumatust võrgust, kus nõutav tulemüür ja edasisaatmine on juba heaks kiidetud. Õige A-kirje ei tõesta kättesaadavat teenust ja staatiline VPN-liising võib lihtsustada privaatset nimetamist, parandamata avalikku hostinime, mis osutab valele WAN-ile.