ddclient publiseer die VPN-uitgang: herstel die opsporingsbron

Jou DNS-naam wys nou na ʼn adres van ʼn VPN-verskaffer, en die opdateringslog lyk heeltemal gesond. Daardie kombinasie is normaal. ʼn Webgebaseerde opsporingspeiling vra ʼn eksterne diens watter bron dit sien, en wanneer die versoek deur ʼn vol tonnel-VPN vertrek, is die antwoord die VPN-uitgang eerder as jou huis-WAN-adres. Die opdaterer het sy werk gedoen; die werk is op die verkeerde waarneming gerig.

Bevestig wat die naam veronderstel is om te bereik

ʼn Publieke naam vir ʼn inkomende tuisdiens het ʼn adres nodig waardeur goedgekeurde inkomende verbindings daardie diens kan bereik. Om ʼn gedeelde verskaffer-uitgang te publiseer, reël nie inkomende deurvoer daar nie, en geen hoeveelheid DNS-opstelling skep daardie deurvoer nie. Besluit dit voordat jy aan die opdaterer raak, want dit bepaal watter adres korrek is.

ʼn Privaat naam vir ʼn tonneladres van ʼn VPN-kliënt is ʼn ander probleem met ʼn ander antwoord: dit hoort in private DNS, en dit het glad nie ʼn publieke opsporingsdiens nodig nie. Om die twee vereistes te vermeng, is hoe ʼn werkende opset ʼn adres begin publiseer wat niemand gevra het nie.

Koppelvlakadresse moet ook geïnterpreteer word. ʼn Skootrekenaaradres agter ʼn tuisroeteerder is nie die publieke WAN-adres nie, en selfs die roeteerder se WAN-adres kan agter carrier-grade NAT sit, waar publikasie daarvan nie inkomende bereikbaarheid kan lewer nie.

Reproduseer die waarde voordat jy iets verander

Let die twee paaie afsonderlik op. Met die tonnel op rapporteer ʼn peiling die uitgang; met die tonnel af, of met die peiling aan die fisiese koppelvlak gebind, rapporteer dit die tuisadres: curl --interface eth0 https://ifconfig.me. As daardie twee antwoorde verskil, het jy die fout gereproduseer sonder om aan die opdaterer te raak.

Hardloop dan die kliënt in ʼn modus wat die opstelling nagaan sonder om ʼn opdatering te doen, soos ddclient -verbose -noexec, en lees watter opsporingsmetode dit gekies het. Die breedsprakige uitvoer noem die metode en die waarde wat dit verkry het, en dit is die feit wat jy nodig het voordat jy iets wysig.

Rig opsporing op die gekose pad

As die naam die huis-WAN-adres moet publiseer, moet opsporing daardie adres sien. Drie opsies werk, in rowwe volgorde van voorkeur: laat die roeteerder deur sy eie ondersteunde opdaterer publiseer; gebruik ddclient se roeteerderstatus-opsporing teen ʼn bladsy wat die roeteerder werklik bedien; of hou ʼn webpeiling maar bind dit aan die fisiese koppelvlak sodat dit buite die tonnel vertrek.

Vir die roeteerderstatus-roete gebruik nuwer ddclient-weergawes die usev4- en fwv4-opsiefamilie, met ʼn opsionele oorslaanpatroon vir die omliggende bladsyteks. Kyk in die README vir jou geïnstalleerde weergawe, want ouer weergawes spel dieselfde idee met use en fw, en ʼn gekopieerde opsienaam uit die verkeerde weergawe faal by die opstart.

As jy webopsporing hou, onthou dat die roetering van die peiling en die roetering van die opdaterings-API-oproep aparte besluite is. Die opdateringsoproep lewer die rekord; die peiling bepaal die waarde wat gelewer word.

Hou geheime en weergawes reg

Roeteerder-aanmelding en verskaffer-tokens hoort in ʼn beskermde opstellêer, nie op ʼn opdragreël wat in die shell-geskiedenis beland nie. Breedsprakige spore kan albei bevat, so redigeer hulle voordat jy dit in ʼn kaartjie plak. ʼn Opsporingsmetode wat ʼn gemagtigde roeteerderbladsy moet skraap, vereis ook dat jy daardie aanmelding oor firmware-opdaterings heen laat werk. Berg dit met dieselfde sorg as die verskaffer-token.

Die ddclient README dokumenteer die opsporingsbenaderings en hul opsiename. Moenie IPv4- en IPv6-resultate in een rekord meng nie, en moenie aanneem dat ʼn opsie in een weergawe ook in ʼn ander bestaan nie.

Verifieer die waarde, dan die bereikbaarheid

Vergelyk die voorgestelde adres met die beoogde eindpunt voordat jy ʼn lewendige opdatering toelaat, kyk dan na gesaghebbende DNS ná een gemagtigde opdatering en reken vir oplosser-kas. ʼn Lae TTL verkort die wag; dit maak nie ʼn verkeerde waarde reg nie.

Eers nadat die rekord korrek is, moet jy die inkomende diens vanaf ʼn onafhanklike netwerk toets, met die vereiste vuurmuur en deurvoer reeds goedgekeur. ʼn Korrekte A-rekord bewys nie ʼn bereikbare diens nie, en ʼn statiese VPN-leasing kan private naamgewing vereenvoudig sonder om ʼn publieke gasheernaam te herstel wat na die verkeerde WAN wys.