Samba na adresie VPN: dlaczego odbiornik znika
Udostępnienie działa do restartu tunelu, a potem kończy się przekroczeniem czasu, choć ping wciąż odpowiada. Odbiornik związany z nieistniejącym adresem wyjaśnia cały wzorzec.
Udostępnienie działa przez cały ranek, tunel łączy się ponownie w południe, a ta sama ścieżka UNC kończy się teraz przekroczeniem czasu, choć ping do serwera wciąż odpowiada. W definicji udostępnienia nic się nie zmieniło i VPN działa. Zmienił się adres lokalny, z którym był związany Samba, a po ponownym utworzeniu interfejsu już nie istnieje. Ten tryb awarii to problem cyklu życia odbiornika, a nie problem uprawnień.
Udostępnienie działa do restartu tunelu
Powiązanie usługi z adresem wiąże jej gniazdo z czasem życia tego adresu. Gdy interfejs tunelu zostaje zniszczony i zbudowany od nowa, stary adres znika, a gniazdo z nim związane znika razem z nim. Usługa działa dalej, ale nic nie nasłuchuje tam, gdzie kierowani są klienci.
Ping może nadal się udać, jeśli nowy adres odpowiada na ICMP, i dlatego osiągalność wygląda dobrze, gdy udostępnienie jest martwe. Właśnie ten jeden mylący sukces wysyła ludzi do zapory.
Osiągalność nie jest adresem powiązania
Mieszają się tu trzy decyzje. Trasa decyduje, czy pakiet klienta dotrze. Nasłuchujące gniazdo decyduje, czy coś przyjmie go pod adresem lokalnym. Konfiguracja udostępnienia i uprawnienia systemu plików decydują, co dzieje się potem. Po ponownym utworzeniu interfejsu psuje się tylko druga z nich.
Adres z puli VPN też nie jest automatycznie lokalnym adresem powiązania. Należy do klienta, a nie do serwera plików. Ping to słaby test dla usługi plikowej.
Trzymaj tych właścicieli osobno także w dokumentacji. Przyszła zmiana puli VPN nie powinna wymagać edycji Samby, a zmiana uprawnień udostępnienia nie powinna wymagać restartu tunelu.
Zamiast tego powiąż ze stabilnym adresem
Stabilniejszy projekt trzyma Sambę na stałym adresie i pozwala VPN doprowadzić do niego klientów. Adres serwera nie zmienia się, gdy tunel drga, więc odbiornik nigdy nie musi podążać za interfejsem. Dopuszczenie wymuszają wtedy ścieżka VPN i zapora hosta, które są zbudowane właśnie do tego zadania.
Jeśli musisz powiązać się z tunelem, zrozum umowę zainstalowanego wydania. Parametry interfaces i bind interfaces only nie są tym samym, a dokumentacja wiązania ostrzega przed przerywanymi interfejsami. Dynamiczna obsługa odbiornika istnieje na niektórych platformach, ale to zdolność do sprawdzenia, a nie do założenia. Przeczytaj tabelę przed drgnięciem i po nim i porównaj oba wyniki.
ss -ltnp | grep ':445'Testuj ponowne połączenie, nie zieloną lampkę
Sprawdź odbiornik po ponownym połączeniu, nie tylko po starcie usługi. Odtwórz tunel, potem odczytaj tabelę nasłuchu i potwierdź, że gniazdo istnieje pod adresem, na który kierowani są klienci. Zielony wskaźnik tunelu i zaliczona kontrola konfiguracji nie dowodzą ani jednego, ani drugiego.
smbclient -L //files.corp.example -U aliceNastępnie wykonaj jedną dozwoloną operację i jedną odrzuconą ścieżkę z klienta i powtórz po drugim ponownym połączeniu. Jeśli udostępnienie działa tylko do pierwszego drgnięcia, powiązanie nadal jest związane z czasem życia interfejsu i projekt nie został naprawiony. Zmień powiązanie lub adres usługi, a objaw przestanie wracać.