Klienci OpenVPN w trybie mostu nie mają internetu? Sprawdź regułę NAT

Serwer w trybie mostu działa, reguła masquerade istnieje, a przeglądarka na kliencie wciąż się kręci. Wszystko wygląda tak, jakby powinno działać, dlatego pierwsza godzina idzie na sprawdzanie tunelu i danych logowania. Potem czytasz licznik reguły NAT i widzisz zero, które się nie ruszyło. Reguła, która nigdy nie policzyła żadnego pakietu, nigdy żadnego nie dopasowała, a na serwerze w trybie mostu przyczyna jest strukturalna: ruch klienta wychodzi przez wirtualne urządzenie tap, podczas gdy reguła wskazuje fizyczną kartę skopiowaną ze starszego poradnika.

Dowodem jest licznik, a nie wpis w tabeli

Reguły, które istnieją, i reguły, które pasują, to dwie różne rzeczy, a rozdziela je licznik. Wypisz tabelę NAT ze szczegółowymi licznikami i przeczytaj liczby obok każdej reguły, zanim cokolwiek zmienisz. Licznik stojący na zerze, gdy ruch płynie, oznacza, że reguła została pominięta, choćby jej adresy wyglądały rozsądnie. Licznik, który rośnie, gdy połączenie nadal zawodzi, kieruje cię gdzie indziej: do przekazywania, drogi powrotnej albo drugiego końca.

iptables -t nat -L POSTROUTING -v -n

Najpierw przeczytaj licznik obok dopasowania interfejsu. Jeśli zakres źródłowy jest właściwy, a strona wyjściowa błędna, poprawką jest jedno słowo w regule, a nie zupełnie nowa reguła.

Znajdź nazwę, którą jądro naprawdę zapisuje

Ustal nazwę urządzenia tunelowego przed napisaniem reguły, korzystając z listy interfejsów, a nie z pamięci. W konfiguracji OpenVPN w trybie mostu urządzeniem jest zwykle interfejs tap utworzony przez serwer, a jego nazwa jest częścią lokalnej konfiguracji, nie uniwersalną stałą. Potwierdź, że istnieje, gdy tunel jest aktywny, ponieważ urządzenie, które pojawia się dopiero po podłączeniu klienta, sprawi, że wcześniejszy test będzie wyglądał na problem z regułą.

ip -brief link

Zapisz tę nazwę. Każde późniejsze polecenie w tej diagnozie się do niej odwołuje, a literówka tutaj daje dokładnie ten sam zerowy licznik co pierwotny błąd.

Przepisz regułę na urządzenie tunelowe

Skieruj regułę na urządzenie tunelowe i pozostaw zakres klientów jako warunek dopasowania, aby obejmowała ruch tunelowy i nie ruszała własnych połączeń hosta. Podstaw własny zakres i nazwę urządzenia, ponieważ oba poniżej są przykładami i żaden nie jest przenośny między instalacjami.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Następnie sprawdź dwa pozostałe warunki, które ten sam objaw ukrywa. Sprawdź, czy przekazywanie jest włączone, a jeśli nie, włącz je w konfiguracji samej dystrybucji, a nie poleceniem echo, które znika po restarcie. Przeczytaj też liczniki łańcucha forward i jeśli odrzuca on ruch tunelowy, zezwól konkretnie na ten interfejs, a politykę łańcucha zostaw bez zmian.

Odczyt łańcucha forward z licznikami zajmuje jedno polecenie i wyklucza połowę pozostałych możliwości, zanim dotkniesz kolejnej reguły.

Dlaczego fizyczna karta nigdy nie pasuje

Most to przełącznik programowy złożony z urządzenia tap i jednego interfejsu fizycznego. Ramka klienta wchodzi do tego przełącznika i wychodzi w stronę sieci fizycznej jako element mostu, a nie jako pakiet na karcie. Jądro przypisuje więc pakiet do mostu i jego portu, dlatego karta, o której myślałeś, nigdy nie pojawia się w dopasowaniu. Z fizycznym interfejsem nic nie jest zepsute; po prostu nie jest to urządzenie, któremu jądro przypisuje ten pakiet.

Kolejny problem, na który ludzie trafiają, wynika z tej samej struktury: filtrowanie ramek na moście to osobny mechanizm od filtrowania IP. Jeśli wymagane jest ograniczenie na poziomie ramki, należy ono do filtrowania mostu, a nie do reguły tabeli IP.

Udowodnij to od początku do końca, a potem utrwal

Uruchom jednego klienta i spinguj coś w sieci LAN serwera; ta ścieżka ćwiczy przekazywanie bez żadnego tłumaczenia adresów. Potem zażądaj czegoś publicznego, żeby reguła masquerade musiała zostać użyta, i przeczytaj licznik jeszcze raz: powinien ruszyć się dla tego testu, a nie dla poprzedniego. Przechwycenie wykonane na urządzeniu tunelowym pokazuje zarówno, gdzie pojawia się ramka, jak i jaki adres niesie.

Ostatni krok: umieść działające reguły w konfiguracji, którą czyta restart, i zapisz nazwę urządzenia, którego most tego hosta faktycznie używa. Wszystko wpisane ręcznie znika po restarcie, a ten sam błąd wraca bez niczego, co by go wyjaśniało.

Jeśli po przepisaniu licznik nadal się nie rusza, porównaj zakres źródłowy w regule z adresem, który klient faktycznie otrzymał, ponieważ serwer w trybie mostu może rozdawać adresy z zakresu, którego nie zamierzałeś.