Jak zapowiedziałem w notce o porządkach, przepiąłem się z łącza ADSL na komórkę. Decyzję przyspieszyła wydatnie awaria ADSL, polegająca na tym, że transfery liczone są w pojedynczych kB, a mimo obiecującego początkowego kontaktu, awaria nadal trwa… Przy czym po tym jak odesłałem parametry łącza, które chcieli, to przestali się odzywać. Mimo dwóch kontaktów mailowych z mojej strony.
Nie obyło się bez zawirowań i ledwo działający dostęp ADSL ratował mi tyłek, ale może o tym w innej notce. W tej chwili sytuacja wygląda tak, że cały ruch leci przez modem GSM wpięty do routera na Banana Pi. Jeśli chodzi o dostawcę łącza, to poszedłem na łatwiznę i jest to Aero2. W zeszłym miesiącu zużyłem (tj. bardziej rodzice) niecałe 2GB z 3GB pakietu. Czyli przewidywany koszt łącza to 5-10 zł/m-c. Wyższe pingi nie są problemem, zresztą różnica w stosunku do BSA jest niewielka. Prędkość to jakieś 3/1 Mbps[1], więc też lepiej, niż było.
Problemem okazał się dostęp do routera, który chciałbym zachować. Znalazłem autossh, o którym wspominałem w komentarzach do notki o porządkach, ale uruchomienie zajęło znacznie więcej czasu, mimo prostych instrukcji. Oczywiście wszystko przez moje niezrozumienie tematu, albo raczej wcześniejsze wyobrażenia. Liczyłem, że po zestawieniu tunelu, łącząc się do zdalnego hosta na określonym porcie, zostanę automagicznie przekierowany do hosta za NAT, z którego jest zestawiony tunel.
Tak jednak nie jest. Autossh słucha na zdalnym hoście wyłącznie na adresie lokalnym (127.0.0.1) i zdebugowanie tego zajęło mi dłuższą chwilę. Może oszczędzę tym wpisem komuś szukania. Korzystając z instrukcji dostępnych w sieci faktycznie połączymy się do hosta za NAT, ale tylko z maszyny do której jest zestawiony tunel. Można wystawić ten dostęp na świat, ale wymaga to dodatkowego przekierowania portu, czy to przy pomocy iptables, czy programu redir.
Ostatecznie wypracowałem następujący schemat. Połączenie zestawione z hosta za NAT przy pomocy autossh (uruchamiane przy starcie systemu, logowanie po kluczach bez hasła):
autossh -f -M 5122 -N -R 8888:127.0.0.1:22 user@host
Jeśli chcę się dostać do routera (hosta za NAT) to na hoście docelowym uruchamiam przekierowanie portów:
redir --lport=8888 --laddr=IP_PUBLICZNE --cport=8888 --caddr=127.0.0.1
W tym momencie łącząc się na port 8888 maszyny z publicznym IP, de facto łączę się do routera za NAT:
ssh -p 8888 user_za_nat@host
Oczywiście analogicznie mogę także zestawiać tunele SSH itp., które umożliwią mi wyjście w świat przez modem GSM.
Czemu redir, a nie iptables? Nie potrzebuję dostępu do tej maszyny cały czas. Wolę więc uruchomić na chwilę przekierowanie, niż wystawiać router na świat, chociaż po docelowym zabezpieczeniu pewnie się to zmieni.
[1] Tzn. 3/1Mbps wykazał speedtest, ale może być lepiej, zwł. download . Później zauważyłem, że konfigurując router ustawiłem limitowanie pasma na 3 Mbps dla pojedynczej końcówki za NAT.