MULTI: nieprawidłowy adres źródłowy od klienta: czyj to był adres?

Dziennik serwera wypisuje MULTI: bad source address from client, odrzuca pakiet, a sesja pozostaje połączona. Ta kombinacja myli osoby, które czytają komunikat jako nieudaną autoryzację. Tak nie jest: klient się uwierzytelnił, a przysłany pakiet niósł wewnętrzny adres źródłowy, którego serwer nie potrafił powiązać z tą instancją klienta. Sprawdzenie odbywa się przed dostarczeniem, dlatego tunel wygląda zdrowo, choć nic pożytecznego przez niego nie przechodzi.

Co serwer porównuje przed dostarczeniem

Dla każdego pakietu przychodzącego od klienta serwer w przestrzeni użytkownika patrzy na adres źródłowy wewnątrz tunelu i pyta swój wewnętrzny stan routingu, do którego klienta ten adres należy. Jeśli właścicielem jest inna instancja albo nie ma żadnego właściciela, pakiet jest odrzucany i emitowane jest ostrzeżenie.

Zwykłe dostarczanie przez interfejs tunelu nigdy nie następuje.

Ta kolejność wyjaśnia szczegół, który dziwi ludzi: liczniki zapory hosta się nie ruszają, bo pakiet nigdy nie dotarł do zapory. Dostrajanie filtrowania odwrotnej ścieżki na hoście nic tu nie zmienia, ponieważ odrzucenie nastąpiło w wewnętrznym sprawdzeniu powiązania demona. Czytaj komunikat jako stwierdzenie o własności, a następnie ustal, która z trzech sytuacji go wywołała.

Trzy źródła niedopasowanego adresu wewnętrznego

Klient może wysyłać z adresu, którego mu nie przydzielono, z sieci, której nikt nie zadeklarował jako jego, albo z kopii tożsamości, która ma już właściciela. Wszystkie trzy dają tę samą linię dziennika. Różnią się tym, co trzeba zmienić. Zacznij od adresu i bieżącej listy przypisań, i pozwól tym dwóm faktom wybrać przypadek.

Rozróżnienie ich wymaga dwóch faktów: odrzuconego adresu w dzienniku i przypisań, które serwer uważa za bieżące. Drugi jest dostępny w widoku stanu lub zarządzania działającej instancji i jest jedynym autorytetem, z którym warto się konsultować, ponieważ plik konfiguracyjny zapisuje intencje, a nie stan bieżący.

Zapisz oba, zanim cokolwiek zmienisz, a potem sklasyfikuj. Zrzut ekranu wykonany później nie jest zapisem stanu, który wywołał ostrzeżenie. Zachowaj też znacznik czasu, ponieważ przypisania przemieszczają się między sesjami.

LAN za klientem i iroute

Gdy klient lokacji routuje własną sieć prywatną, ta sieć musi zostać zadeklarowana jako należąca do klienta. Plik specyficzny dla klienta z wpisem iroute robi to, a wpis nazywa prefiks, który klient może przenosić.

Trasa jądra kierująca ten sam prefiks do tunelu jest osobnym wymaganiem, a jej dodanie niczego nie zmienia we własności wewnętrznej demona.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Potwierdź, że efektywna tożsamość odpowiada nazwie pliku, ponieważ niezgodność oznacza, że plik nigdy się nie wczytuje, a objaw jest identyczny z brakującym wpisem. Nie dodawaj szerokiego iroute, aby uciszyć ostrzeżenie, ponieważ zamienia to nieoczekiwane źródło w dozwolone, nie odpowiadając, dlaczego klient je wysłał. Podręcznik OpenVPN 2.6 dokumentuje iroute, duplicate-cn i mapowanie tożsamości jako osobne mechanizmy kontroli.

Ta sama tożsamość na dwóch maszynach

Profil skopiowany na drugi laptop niesie ten sam certyfikat i tę samą nazwę wspólną. W zależności od ustawień serwera nowsze połączenie może zastąpić starsze, a sprawdzenie powiązania wygrywa ta instancja, która ma własność.

To sprawia, że usterka wygląda na przerywaną i pojawia się tylko wtedy, gdy oba urządzenia są aktywne.

Zezwolenie na zduplikowane nazwy wspólne pozwala obu się połączyć, ale nie daje im niezależnych adresów statycznych ani niezależnej własności. Jeśli dwa urządzenia muszą współistnieć, zarejestruj je osobno, aby każde miało własną tożsamość i własne przypisanie. Traktowanie ustawienia duplikatów jako naprawy tego ostrzeżenia pozostawia zagadkę na miejscu i dodaje drugą.

Udowodnij, że powiązanie się zmieniło

Zastosuj poprawkę przez właściciela konfiguracji, a następnie połącz ponownie dotkniętego klienta, aby wczytała się nowa polityka.

Powtórz ten sam przebieg i potwierdź trzy rzeczy: wewnętrzne źródło pakietu, instancję klienta, z którą serwer go wiąże, oraz zachowanie celu po tym.

Jeśli ostrzeżenie ustaje, ale aplikacja nadal zawodzi, problem się przesunął, a nie zniknął. Przekazywanie, reguły zapory i ścieżka powrotna to osobne etapy, a przejście sprawdzenia powiązania oznacza tylko, że pakietowi pozwolono opuścić tunel.