A ju nevojitet DNS dinamik për një server VPN shtëpiak?

DNS dinamik rregullon emrin, jo rrugën e hyrjes. Tre kontrolle vendosin nëse një emër hosti mjafton për një server VPN shtëpiak apo rruga e hyrjes është e prishur.

Shumica e dështimeve të VPN shtëpiake për të cilat më pyesin nuk janë dështime DNS, dhe megjithatë njerëzit blejnë fillimisht një abonim DNS dinamik. Përpara se të konfiguroni ndonjë gjë, vendosni nëse emri i hostit është pjesa që është me të vërtetë e prishur. Një përditësues rishkruan një regjistrim kur adresa që ju dha ofruesi lëviz; ai nuk mund të hapë një port, të kalojë përmes NAT-it të operatorit ose ta bëjë një sesion aktiv WireGuard të vërë re se pika e saj fundore ka ndryshuar. Tre kushte vendosin nëse DNS dinamik është zgjidhja e plotë apo vetëm një rresht i saj.

Kushti i parë: adresa juaj lëviz me të vërtetë

Adresat e banesave lëvizin për arsye të zakonshme: modemi risinkronizohet pas një ndërprerjeje rryme, ofruesi ribalancon një pishinë, një qira e re vjen pas një ndërprerjeje të gjatë. Në disa linja ato lëvizin edhe rrallë, dhe e kam parë të njëjtën adresë të mbijetojë një vit; planet e biznesit shpesh përfshijnë një statike. Nëse asgjë nuk ka ndryshuar në dymbëdhjetë muaj, një regjistrim A i redaktuar me dorë është një demon më pak për të mbajtur gjallë.

Matni në vend që të hamendësoni. Lexoni adresën WAN në faqen e statusit të ruterit dhe krahasojeni me atë që sheh bota e jashtme. Ekzekutoni këtë nga një makinë në LAN:

curl -fsS https://api.ipify.org; echo

Nëse dy vlerat ndryshojnë, diçka përkthen përpara ruterit tuaj dhe asnjë përditësim i emrit të hostit nuk do ta rregullojë atë. Një adresë brenda 100.64.0.0/10 është diapazoni i përbashkët për NAT të nivelit të operatorit, dhe kjo është arsyeja e zakonshme pse një emër i përditësuar saktë skadon gjithsesi nga jashtë.

Kushti i dytë: klientët e kërkojnë emrin përsëri

TTL i shkurtër është pjesa që njerëzit e kapërcejnë. Zbërthyesit rekurzivë respektojnë TTL-in e regjistrimit, por stivat e klientëve ruajnë veçmas, dhe një tunel tashmë i ngritur nuk zbërthon asgjë përsëri. Gjatë korrigjimit vendoseni regjistrimin në 60-300 sekonda; kjo shkurton dritaren kur shërbehet një përgjigje e vjetër, dhe nuk migron një sesion të lidhur.

OpenVPN e zbërthon përsëri rreshtin remote vpn.example.net 1194 në çdo rilidhje, dhe resolv-retry infinite e mban duke u përpjekur përsëri në vend që të dalë kur kërkimi dështon. Në server, float lejon një sesion të vendosur të ndjekë një palë, adresa e burimit e të cilit ka ndryshuar. WireGuard është më i drejtpërdrejtë: wg-quick up e zbërthon Endpoint kur zbatohet konfigurimi, dhe klienti e zbërthon përsëri kur rindërton tunelin, kështu që një shtrëngim duarsh që ende ia del kundrejt adresës së vjetër vazhdon të ia dalë derisa ndalon.

Ky ndryshim formëson planin. Nëse klientët lidhen sipas kërkesës, një ndryshim adrese kushton një rilidhje. Nëse mbajnë një sesion të hapur për ditë, prisni që tuneli të vdesë në shtrëngimin e radhës të duarve, dhe bëjeni klientin të provojë përsëri në vend që të supozoni se mbetet lart.

Kushti i tretë: rruga e hyrjes është ende e hapur

DNS dinamik ndryshon vetëm ku tregon emri dhe asgjë tjetër. Ridrejtimi i portit në ruter, rregulli i firewall-it në hostin VPN dhe leja e ofruesit për paketat hyrëse duhet të ekzistojnë të gjitha përpara se regjistrimi të ketë rëndësi. Vini re se ku synon ridrejtimi: nëse është i fiksuar në një adresë WAN në vend të ndërfaqes, një ndryshim adrese e prish ridrejtimin në heshtje dhe regjistrimi merr fajin.

Provoni nga jashtë. Një telefon në të dhëna celulare me Wi-Fi të fikur është testi i ndershëm më i lirë; një laptop në të njëjtin LAN nuk është. Kur emri zbërthehet në adresën tuaj publike dhe ruteri nuk ka lak NAT, një test i brendshëm dështon ndërsa regjistrimi është krejt i saktë, dhe kjo i dërgon shumicën të redaktojnë një regjistrim që nuk ka qenë kurrë i gabuar.

Çfarë të ekzekutoni kur të treja vlejnë

ddclient është përditësuesi më pak befasues për një host të vogël. Një konfigurim minimal publikon adresën që sheh ofruesi, gjë që shmang gabimin e NAT-it të dyfishtë:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Ekzekutoni atë nga një kohëmatës systemd çdo pak minuta në vend të një cikli shell, dhe regjistroni përgjigjen e ofruesit në vend që të supozoni sukses. Trajtojeni kredencialin si një çelës, sepse ai vendos ku dërgohet çdo klient: përdorni një shenjë përditësimi të kufizuar në vend të fjalëkalimit të llogarisë, mbajeni skedarin në modalitetin 0600 dhe dërgoni përditësimet përmes HTTPS.

Verifikoni përpara se të angazhoheni

Një kërkim ju tregon çfarë sheh pjesa tjetër e botës, dhe printon TTL-in që duhet të prisni pas një ndryshimi:

dig +noall +answer vpn.example.net @1.1.1.1

Krahasoni atë adresë me adresën WAN të ruterit. Nëse përputhen, emri po bën punën e tij dhe ajo që ende dështon është arritshmëria hyrëse, një çelës ose një klient që nuk ka zbërthyer përsëri. Nëse ndryshojnë, përditësuesi publikon ndërfaqen e gabuar, shpesh sepse ekzekutohej në hostin VPN pas ruterit në vend të ruterit vetë.

Mbajini një kthim pas një minutë: shënoni adresën e fundit që funksionoi dhe TTL-in e mëparshëm, që t'i publikoni të dyja me dorë ndërsa ofruesi kalon një pasdite të keqe.

Kur përgjigjja është jo

Nëse kushti i parë ose i tretë dështon, ajo që ndryshon është vendimi, jo konfigurimi. Pas NAT-it të operatorit, opsionet praktike janë t'i kërkoni ofruesit një adresë publike, ta zhvendosni pikën e hyrjes në një VPS të vogël me adresë të qëndrueshme, ose të përdorni një shtresë mbivendosjeje që mban takimin e vet. Nëse adresa është statike, kaloni përditësuesin: një regjistrim A, një regjistrim AAAA nëse përdorni IPv6, i njëjti ridrejtim porti.

Nëse adresa ndryshon ndërsa klientët mbeten të lidhur, rregullimi i ndershëm jeton në klient: logjikë rilidhjeje dhe një interval ripërpjekjeje, jo një përditësues më i shpejtë. Një ofrues i dytë thjesht fsheh intervalin.

Përpara se të vazhdoni, konfirmoni katër gjëra sipas radhës:

  • Adresa që publikon përditësuesi përputhet me adresën WAN të ruterit.
  • TTL-i i regjistrimit është mjaft i shkurtër që një ndryshim të shfaqet brenda minutash.
  • Ridrejtimi i portit është i lidhur me ndërfaqen, jo me një adresë fikse.
  • Një klient i vërtetë është rilidhur dhe ka kaluar trafik që nga ndryshimi i fundit.

Nëse të katërt vlejnë, lëreni konfigurimin në paqe; dështimi juaj i radhës është një çelës ose një rregull firewall, jo një problem emërtimi. Nëse ndonjë dështon, rregulloni atë rresht përpara se të shtoni një pjesë tjetër lëvizëse. RFC 2136 përshkruan vetë mekanizmin e përditësimit, nëse doni të shihni çfarë vendos demoni në tel.

Artikuj të ngjashëm