Czasy, kiedy zdarzało mi się udostępniać znajomym coś na serwerku HTTP uruchomionym na prywatnym komputerze, to w zasadzie jeszcze czasy modemów telefonicznych. No ale było miło. Nawet kiedy rozmówcy dawało się nasz bieżący adres IP. A jak już można było dać w tym momencie adres domenowy, we własnej domenie – toż to prawdziwa elita! Nie to co jakieś tam piractwo w domenie DynDNS. Jako że moją domenę utrzymuje FreeDNS::42 – korzystałem z ich gotowego skryptu do dynamicznego aktualizowania rekordów i po prostu działało. Mój serwerek regularnie (dzięki crontab) wywoływał skrypt, więc po tym, jak dostawca zmienił mi adres IP, miałem wkrótce ten adres zmieniony w domenie, a po zwyczajowych 24-48 godzinach na propagację – sprawa była załatwiona automatycznie.

Jak to mówią, tak dobrze żarło, a zdechło… Od niedawna po zmianie adresu IP na bieżący od dostawcy nie da się dostać do usług udostępnianych na moim komputerze pod tym adresem. Choć jak spytamy Google, jaki jest nasz bieżący adres IP, pokaże się nam, że właśnie ten. Co się dzieje? Parę kolejnych pytań do wyszukiwarki i można się domyślić, że pewnie dostawca wykorzystuje teraz Carrier-Grade NAT (CGNAT) i tak już po prostu będzie. A co począć? Przeprosić się z usługami typu DynDNS. Mam konto w No-IP, mój router to obsługuje, potrzebne porty dawno już przekierowałem na routerze, tylko żeby skrypt od FreeDNS jeszcze raczył zamiast domyślnego nowego adresu (który nie zadziała) wziąć sobie ten z No-IP… Oczywiście da się to zrobić. Żeby wywołanie skryptu jako nowego adresu nie brało teraz – jak dotąd – <dynamic> (zewnętrzny adres, który już nie działa), robimy na serwerku coś takiego:

./freedns-dyndns.py --newaddress `dig +short moj_adres.ddns.net`

No i już! “Będzie pan zadowolony!” A tak naprawdę – nic to na CGNAT nie pomoże, chociaż adres w domenie ustawi… Będę się musiał wziąć za tunelowanie, przydałby się chociaż dostęp przez SSH.

PS. Oczywiście mój komputer (serwerek) miał adres domenowy nie tylko po to, żeby było łatwiej łączyć się z nim przez SSH i SCP. Był też na nim serwer www (nginx) z prostą statyczną stroną, która miała certyfikat SSL z Let’s Encrypt. Przez to zrobił się jeszcze jeden problem: odnawianie certyfikatu przestało działać (bo nie ma dostępu do serwera przez port 80). No i teraz certyfikat nie zrobi mi się sam automatycznie. To może chociaż ręcznie?

Z pomocą przychodzi metoda wyzwania DNS-01. Dla jednej domeny i raz na kwartał – mogę tak robić. Na komputerze wywołuję

certbot certonly --manual --preferred-challenges=dns -d mojadomena.net

i otrzymuję zawartość, którą musi mieć nowy rekord TXT _acme-challenge.mojadomena.net. Teraz trzeba przeredagować zawartość strefy DNS swojej domeny, po czym z finalnym wciśnięciem Enter, by zatwierdzić wymianę certyfikatu, poczekać na propagację. Czekanie umili nam link do sprawdzania, czy zmiana już się rozpropagowała:

https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.mojadomena.net.

Gdy będzie widać nową zawartość rekordu – można zatwierdzić zmianę. Na koniec jeszcze przeładujemy konfigurację serwera – u mnie to odbędzie się poleceniem

sudo /etc/init.d/nginx reload

i w końcu będziemy się mogli cieszyć nowym certyfikatem. Jakby tak jeszcze się dało zautomatyzować w konfiguracji DNS dodanie rekordu TXT, byłoby prościej…