Istnieje kilka sposobów, by mieć możliwość do dostania się na serwer w cywilizowany sposób, w przypadku posiadania zmiennego adresu IP. Możemy wykorzystać ogólnodostępne usługi typu dynds.org, no-ip.com itp. W każdej sytuacji zachodzi konieczność wykorzystania klienta, który po ponownym połączeniu (w przypadku neostrady – przynajmniej raz na dobę) wyśle do serwera swój nowy numer IP.
Podobnie też zrobiłem w tym przypadku, lecz zarówno część serwerowa jak i kliencka została napisana od podstaw wykorzystując sh oraz ogólnodostępne w systemie narzędzia. Podstawowym powodem była chęć posiadania nazwy domenowej w postaci oddzial.firma.pl zamiast jakichś noip itp, nie ujmując oczywiście niczego tym usługodawcom.
Jak to jest zrobione?
-
Potrzebna nam jest domena wydelegowana na jakiś serwer (nazwijmy go „A”) ze statycznym IP.
-
Serwer – klient („B”) w przypadku zmiany adresu IP wysyła informacje o tym fakcie do „A”, podając swój nowy numer (za pomocą ftp, maila zaszyfrowanego gnupg, czymkolwiek innym).
-
„A” generuje nowy plik konfiguracyjny dla serwera DNS wstawiając w odpowiednich miejscach nowy numer IP. Aktualizujemy również serial DNSa – tak, by zmiany zaczęły działać. W zasadzie serial powinien mieć format YYYYMMDDXX, gdzie YYYY to rok zmiany, MM miesiąc, DD dzień, zaś XX – numer zmiany dokonanej danego dnia – przykładowo 00, 01, itd. Na szczęście możemy uzyskać jedną komendą poprawny wpis mówiący o dokładnym czasie zachodzących zmian. Jest to ni mniej, ni więcej, jak komenda date +%s (podaje ona tzw. timestamp, czyli ilość sekund, które upłynęły od 1970-01-01 00:00:00 UTC).
-
A” po wygenerowaniu nowego pliku konfiguracyjnego restartuje serwer DNS
Niestety nie ma róży bez kolców. Co by nie mówić łącze ze zmiennym IP to prowizorka. Jeśli ktoś twierdzi inaczej – jego sprawa. Ja obstaję przy swoim. Gdyby to zawsze działało jak powinno – nie było by problemu. Niestety w momencie wymiany informacji pomiędzy „A” a „B” powstają czasami uciążliwe przestoje, część usług należy zrestartować, gdyż „pamiętają” swój stary adres IP i po prostu nie działają. Ogólnie nie polecam tego rozwiązania – wybrać pod serwer należy łącze z przynajmniej jednym statycznym, publicznym adresem IP. Każdy, kto zechce wykonać to na przykładowo neostradzie – prosi się o problemy.
Proponuję również dla bezpieczeństwa połączyć oba serwery tunelem – przykładowo vtun. Jeśli trafimy w moment „synchronizacji”, a konieczne będzie dostanie się na serwer w minimalnym czasie – tunel nam pomoże. „Wstanie” on zaraz po ponownym połączeniu z providerem. Innym rozwiązaniem może być przyłączenie się do któregoś z brokerów IPv6.