DNS-nafnið þitt leysist nú í vistfang VPN-þjónustuveitanda, og uppfærsluskráin lítur algjörlega heilbrigð út. Sú samsetning er eðlileg. Vefbyggð uppgötvunarprufa spyr ytri þjónustu hvaða uppruna hún sjái, og þegar beiðnin fer út um fullt tunna-VPN er svarið VPN-útgangurinn en ekki WAN-vistfang heimilisins. Uppfærslan gerði sitt verk; verkinu var beint að rangri athugun.

Staðfestu hvað nafnið á að ná til

Opinbert nafn fyrir innkomna heimaþjónustu þarf vistfang sem samþykktar innkomnar tengingar komast í gegnum að þeirri þjónustu. Að birta sameiginlegan útgang þjónustuveitanda kemur ekki á innkominni framsendingu þar, og engin DNS-stilling skapar þá framsendingu. Ákveddu þetta áður en þú snertir uppfærsluna, því það ræður því hvaða vistfang er rétt.

Einkanaftn fyrir tunna-vistfang VPN-biðlara er annað vandamál með annað svar: það tilheyrir einkareknu DNS og þarf alls ekki opinbera uppgötvunarþjónustu. Að blanda kröfunum tveimur er leiðin sem virk stilling byrjar að birta vistfang sem enginn bað um.

Viðmótsvistföng þurfa líka túlkun. Vistfang fartölvu bak við heimanetbeini er ekki opinbera WAN-vistfangið, og jafnvel WAN-vistfang beinisins getur verið bak við NAT símafyrirtækis, þar sem birting þess getur ekki skapað innkomið aðgengi.

Endurgerðu gildið áður en þú breytir nokkru

Fylgstu með báðum leiðunum í sundur. Þegar tunnan er upp greinir prufa frá útganginum; þegar tunnan er niðri, eða prufan er bundin við líkamlega viðmótið, greinir hún frá heimilisfanginu: curl --interface eth0 https://ifconfig.me. Ef þessi tvö svör eru ólík hefur þú endurgert gallann án þess að snerta uppfærsluna.

Keyrðu síðan biðlarann í ham sem athugar stillinguna án þess að framkvæma uppfærslu, til dæmis ddclient -verbose -noexec, og lestu hvaða uppgötvunaraðferð hann valdi. Ítarlega úttakið nefnir aðferðina og gildið sem fékkst, og það er sú staðreynd sem þú þarft áður en þú breytir nokkru.

Beindu uppgötvuninni að völdu leiðinni

Ef nafnið á að birta WAN-vistfang heimilisins verður uppgötvunin að fylgjast með því vistfangi. Þrír valkostir virka, í grófum forgangsröð: leyfðu beininum að birta í gegnum eigin studda uppfærslu; notaðu beinisstöðu-uppgötvun ddclient gegn síðu sem beinið þjónar í raun; eða haltu vefprufu en biddu hana við líkamlega viðmótið svo hún fari út fyrir tunnuna.

Fyrir beinisstöðu-leiðina nota nýrri ddclient-útgáfur valkostafjölskylduna usev4 og fwv4, með valfrjálsu sleppimynstri fyrir síðutextann í kring. Skoðaðu README fyrir uppsettu útgáfuna þína, því eldri útgáfur skrifa sömu hugmynd með use og fw, og valkostanafn afritað úr rangri útgáfu mistekst við ræsingu.

Ef þú heldur vefuppgötvuninni skaltu muna að beining prufunnar og beining uppfærslu-API-kallsins eru aðskildar ákvarðanir. Uppfærslukallið skilar færslunni; prufan ræður gildinu sem skilað er.

Haltu leyndarmálum og útgáfum í lagi

Beinisauðkenni og tákn þjónustuveitandans eiga heima í varðri stillingarskrá, ekki á skipanalínu sem endar í shell-sögu. Ítarleg slóð getur innihaldið hvort tveggja, svo fjarlægðu þau áður en þú límir þau í miða. Uppgötvunaraðferð sem krefst þess að skafa auðkennda beinissíðu krefst líka að þú haltu þessum auðkennum virkum í gegnum fastbúnaðaruppfærslur. Geymdu þau af sömu varúð og tákn þjónustuveitandans.

ddclient README skjalfestir uppgötvunaraðferðirnar og valkostanöfn þeirra. Ekki blanda IPv4- og IPv6-niðurstöðum í eina færslu, og ekki gera ráð fyrir að valkostur sem er í einni útgáfu sé í annarri.

Staðfestu gildið, síðan aðgengið

Berðu saman fyrirhugaða vistfangið við fyrirhugaða endapunktinn áður en þú leyfir uppfærslu í beinni, athugaðu síðan valdbera DNS eftir eina heimilaða uppfærslu og taktu tillit til skyndiminni leysara. Lágt TTL styttir biðina; það gerir rangt gildi ekki rétt.

Aðeins eftir að færslan er rétt ættir þú að prófa innkomnu þjónustuna frá sjálfstæðu neti, með nauðsynlegan eldvegg og framsendingu þegar samþykkta. Rétt A-færsla sannar ekki aðgengilega þjónustu, og kyrrstætt VPN-leiga getur einfaldað einkanaftngjöf án þess að laga opinbert hýsilnafn sem bendir á ranga WAN.

Tengdir greinar