ddclient julkaisee VPN-poistumisen: korjaa havaitsemislähde

DNS-nimesi ratkeaa nyt VPN-palveluntarjoajan osoitteeseen, ja päivitysloki näyttää täysin terveeltä. Yhdistelmä on normaali. Verkkopohjainen tunnistuskoetin kysyy ulkoiselta palvelulta, minkä lähteen se näkee, ja kun pyyntö lähtee täystunneli-VPN:n kautta, vastaus on VPN:n poistuminen eikä kotisi WAN-osoite. Päivittäjä teki tehtävänsä; tehtävä oli suunnattu väärään havaintoon.

Vahvista, mihin nimen pitäisi yltää

Julkinen nimi saapuvalle kotipalvelulle tarvitsee osoitteen, jonka kautta hyväksytyt saapuvat yhteydet voivat yltää siihen palveluun. Jaetun palveluntarjoajan poistumisen julkaiseminen ei järjestä sinne saapuvaa edelleenohjausta, eikä mikään määrä DNS-määritystä luo sitä edelleenohjausta. Päätä tämä ennen kuin kosket päivittäjään, koska se määrää, mikä osoite on oikea.

VPN-asiakkaan tunneliosoitteen yksityinen nimi on toinen ongelma toisella vastauksella: se kuuluu yksityiseen DNS:ään eikä tarvitse lainkaan julkista tunnistuspalvelua. Kahden vaatimuksen sekoittaminen on tapa, jolla toimiva määritys alkaa julkaista osoitetta, jota kukaan ei pyytänyt.

Myös liitäntäosoitteet vaativat tulkintaa. Kotireitittimen takana olevan kannettavan osoite ei ole julkinen WAN-osoite, ja jopa reitittimen WAN-osoite voi olla operaattorin NAT:n takana, jossa sen julkaiseminen ei voi tuottaa saapuvaa tavoitettavuutta.

Toista arvo ennen kuin muutat mitään

Tarkkaile kahta polkua erikseen. Tunnelin ollessa päällä koetin raportoi poistumisen; tunnelin ollessa pois päältä tai koettimen ollessa sidottu fyysiseen liitäntään se raportoi kodin osoitteen: curl --interface eth0 https://ifconfig.me. Jos nämä kaksi vastausta eroavat, olet toistanut vian koskematta päivittäjään.

Aja sitten asiakas tilassa, joka tarkistaa määrityksen tekemättä päivitystä, esimerkiksi ddclient -verbose -noexec, ja lue, minkä tunnistusmenetelmän se valitsi. Yksityiskohtainen tuloste nimeää menetelmän ja saadun arvon, ja se on se tosiasia, jonka tarvitset ennen mitään muokkausta.

Suuntaa tunnistus valittuun polkuun

Jos nimen on julkaistava kodin WAN-osoite, tunnistuksen on tarkkailtava juuri sitä osoitetta. Kolme vaihtoehtoa toimii, karkeassa suositusjärjestyksessä: anna reitittimen julkaista oman tuetun päivittäjänsä kautta; käytä ddclientin reitittimen tilan tunnistusta sivua vastaan, jota reititin todella tarjoilee; tai pidä verkkokoetin mutta sido se fyysiseen liitäntään, jotta se lähtee tunnelin ulkopuolelta.

Reitittimen tilan polulla uudemmat ddclient-julkaisut käyttävät usev4- ja fwv4-vaihtoehtoperhettä, mukana valinnainen ohituskuvio ympäröivälle sivutekstille. Tarkista asennetun versionsi README, koska vanhemmat julkaisut kirjoittavat saman ajatuksen muotoon use ja fw, ja väärästä julkaisusta kopioitu vaihtoehdon nimi epäonnistuu käynnistyksessä.

Jos pidät verkkotunnistuksen, muista, että koettimen reititys ja päivityksen API-kutsun reititys ovat erillisiä päätöksiä. Päivityskutsu toimittaa tietueen; koetin päättää toimitetun arvon.

Pidä salaisuudet ja versiot järjestyksessä

Reitittimen tunnistetiedot ja palveluntarjoajan tokenit kuuluvat suojattuun määritystiedostoon, ei komentoriville, joka päätyy shellin historiaan. Yksityiskohtaiset jäljet voivat sisältää molemmat, joten poista ne ennen kuin liität ne tikettiin. Tunnistusmenetelmä, joka vaatii todennetun reititinsivun kaapimista, vaatii myös, että pidät tunnistetiedot toimivina laiteohjelmistopäivitysten yli. Säilytä ne yhtä huolellisesti kuin palveluntarjoajan token.

ddclient README dokumentoi tunnistustavat ja niiden vaihtoehtojen nimet. Älä sekoita IPv4- ja IPv6-tuloksia yhteen tietueeseen äläkä oleta, että yhdessä julkaisussa oleva vaihtoehto on olemassa toisessa.

Vahvista arvo ja sitten tavoitettavuus

Vertaa ehdotettua osoitetta aiottuun päätepisteeseen ennen live-päivityksen sallimista, tarkista sitten autoritatiivinen DNS yhden valtuutetun päivityksen jälkeen ja huomioi ratkaisijoiden välimuistit. Matala TTL lyhentää odotusta; se ei tee väärästä arvosta oikeaa.

Vasta kun tietue on oikein, testaa saapuvaa palvelua riippumattomasta verkosta, kun tarvittava palomuuri ja edelleenohjaus on jo hyväksytty. Oikea A-tietue ei todista tavoitettavaa palvelua, ja staattinen VPN-liisaus voi yksinkertaistaa yksityistä nimeämistä korjaamatta julkista isäntänimeä, joka osoittaa väärään WAN:iin.