rsync przez VPN: port demona 873 kontra tryb SSH

Zezwolenie na TCP 873 na interfejsie tunelu nie przepycha rsync przez OpenVPN, ani nie sprawia, że druga strona zaakceptuje moduł. Tunel przenosi połączenie wewnętrzne, którego reguły protokołu i celu pozostają dokładnie takie, jakie były. Pierwsze pytanie nie brzmi więc, który port otworzyć, lecz jakie połączenie nawiązuje rsync. Wszystko poniżej zakłada, że tunel już działa i wątpliwa jest tylko usługa wewnętrzna.

Ustal, jakie połączenie rsync naprawdę nawiązuje

Argument zdalny w poleceniu zwykle odpowiada na to pytanie przed jakąkolwiek zmianą zapory. Podwójny dwukropek lub schemat URL wybiera demona, natomiast pojedynczy dwukropek po nazwie hosta wybiera zdalną powłokę. Czytaj argument, który naprawdę uruchamiasz, a nie ten z przykładu w dokumentacji.

Jawna opcja zdalnej powłoki może ponownie zmienić odpowiedź, bo mówi rsyncowi, który program uruchomić do transportu. Czytaj cały wiersz poleceń, łącznie z odziedziczonymi skryptami opakowującymi, nie tylko część z hostem.

Tryb demona: adres wiązania, moduł i port

W składni demona segment ścieżki nazywa skonfigurowany moduł, a nie katalog na dysku. Hasło modułu jest sprawdzane dopiero po zaakceptowaniu połączenia, a moduł może dodatkowo być tylko do odczytu lub ukryty na liście. Ta kolejność ma znaczenie przy czytaniu błędu, bo odrzucone połączenie i odrzucony moduł to awarie na dwóch różnych etapach. Żaden z tych komunikatów nie mówi nic o samym tunelu.

Samodzielnego demona można przypiąć do adresu tunelu w jego pliku konfiguracyjnym, co trzyma go poza interfejsem publicznym bez żadnej reguły zapory. Wartość musi istnieć w chwili wiązania demona, a nasłuchiwacz uruchamiany przez gniazdo lub zarządzany przez inetd może ją całkowicie zignorować.

address = 10.44.0.1
port = 873
[archive]
    path = /srv/archive
    read only = yes

Potem testuj pod adresem prywatnym, a nie pod nazwą publiczną. Publiczna nazwa hosta rozwiązuje się na adres WAN i idzie inną ścieżką, nawet gdy jedna maszyna odpowiada na oba.

rsync --list-only rsync://10.44.0.1/archive/

Tryb zdalnej powłoki: SSH przenosi transfer

Przy jednym dwukropku rsync uruchamia program zdalnej powłoki i mówi jej protokołem przez ten kanał, więc jedyną osiągalną usługą jest SSH na tym porcie, na którym nasłuchuje serwer. Demon rsync nigdy nie działa, port 873 jest nieistotny, a decyzja o dostępie staje się decyzją o koncie SSH. Ścieżka zdalna jest wtedy prawdziwą ścieżką systemu plików interpretowaną przez powłokę po drugiej stronie. Dlatego zmiana zapory wymierzona w 873 nie robi dla tego trybu zupełnie nic.

Taki projekt wymaga upoważnionego konta i weryfikacji klucza hosta, i dziedziczy własną politykę uwierzytelniania SSH. Często jest to lepszy wybór, gdy transfer musi przejść przez niezaufaną sieć, bo szyfrowanie należy do protokołu zbudowanego właśnie do tego. Demon z prośbą o hasło to nie to samo.

Otwórz tylko wybraną ścieżkę

Gdy tryb jest ustalony, zezwól na jedyną usługę wewnętrzną na jedynym interfejsie, który przenosi tunel. Ogranicz regułę według interfejsu, puli źródeł i adresu docelowego, żeby późniejsza zmiana domyślnej odmowy nie mogła jej po cichu poszerzyć. Potem przejrzyj kolejność reguł, bo reguła zezwalająca wcześniej w łańcuchu czyni wąską regułę tylko dekoracyjną.

Jeśli demon działa na maszynie za bramą VPN, a nie na samej bramie, brama też potrzebuje ścieżki przekazywania, a cel własnego pozwolenia i trasy powrotnej. Otwarcie portu tylko na bramie daje połączenie, które zostaje przyjęte, a potem donikąd nie prowadzi.

Sprawdź z klienta w tym samym trybie i do tego samego celu, których zamierzasz używać na produkcji. Udane wylistowanie dowodzi razem nasłuchiwacza, trasy i reguły; przekroczenie czasu wskazuje ścieżkę, a odmowa wskazuje nasłuchiwacz.

ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873