eth0:0 to etykieta, nie urządzenie: popraw dopasowanie SNAT

Licznik na zero oznacza, że reguła nazywa interfejs, który nie może istnieć. Odczytaj prawdziwe urządzenie, popraw dopasowanie -o, a potem świadomie wybierz tłumaczony adres.

Reguła NAT, która miała dać jednej puli klientów VPN własny publiczny adres, stoi na zerze pakietów, podczas gdy ta sama pula nadal wychodzi z niewłaściwego źródła. Reguła zwykle nie myli się co do adresu; myli się co do interfejsu. -o eth0:0 wskazuje urządzenie, którego nie ma, bo eth0:0 to etykieta przypisana do adresu na eth0. Patrzenie na liczniki to najszybszy sposób, by to potwierdzić, a poprawka jest mniejsza, niż sugeruje dochodzenie.

Sprawdź, jak jądro nazywa urządzenie

Przeczytaj oba widoki osobno, zanim cokolwiek zmienisz:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

Lista łączy pokazuje interfejsy. Lista adresów może pokazać drugi adres IPv4 noszący etykietę eth0:0, a urządzeniem dla tego adresu jest nadal eth0. Podręcznik adresów iproute2 traktuje etykietę jako nazwę adresu, a nie jako drugie łącze, i właśnie na tym rozróżnieniu opiera się cały problem.

Historia wyjaśnia zamieszanie. Stara ifconfig eth0:0 składnia naprawdę wyglądała jak nowy interfejs, a skrypty z tamtych czasów nadal się do niego odwołują. W dzisiejszym systemie alias to etykieta na adresie i nic na ścieżce routingu ani netfilter nie traktuje go jako osobnego punktu wyjścia.

Sprawdź, do czego reguła naprawdę pasowała

Czytaj liczniki razem z listą reguł, a nie z pamięci:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Reguła, której licznik pakietów pozostaje na zerze, gdy płynie pasujący ruch, nie jest oceniana, a warunek interfejsu wyjściowego, który nazywa eth0:0 jest częstą przyczyną. Urządzenie wyjściowe wybrane przez trasę to eth0, więc warunek szukający innej nazwy nigdy nie staje się prawdziwy, niezależnie od tego, który adres źródłowy wybrało jądro.

Zmień warunek na prawdziwe urządzenie i zostaw etykietę poza nim. Jeśli musisz rozróżnić dwie pule klientów, które dzielą to urządzenie, rozróżnij je po prefiksie źródła, a nie po nazwie interfejsu, która nie może istnieć. Dwie reguły z niepokrywającymi się -s dopasowaniami są czytelne i testowalne; jedna reguła z wymyślonym urządzeniem nie jest ani jednym, ani drugim. Dodaj do każdej reguły komentarz nazywający pulę, bo za pół roku sam prefiks nie powie nikomu, dlaczego tam stoi.

Sprawdź trasę, która wybrała urządzenie

NAT postrouting działa po tym, jak trasa już wybrała interfejs wyjściowy, więc interfejs w regule musi być tym, który wybrała trasa. Zapytaj jądro bezpośrednio za pomocą ip route get o reprezentatywny adres klienta i odczytaj zarówno urządzenie, jak i zgłaszane źródło.

Jeśli odpowiedź nazywa eth0, część reguły dotycząca interfejsu jest rozstrzygnięta. Jeśli nazywa urządzenie tunelowe, pakiet nigdy nie dociera do reguły, którą edytujesz, a poszukiwania przenoszą się do tablicy routingu i jej priorytetów. Reguła, która nigdy nie pasuje, bo pakiet wyszedł gdzie indziej, wygląda w wyjściu liczników tak samo jak reguła z błędnie zapisanym urządzeniem. Zanim cokolwiek zmienisz, ustal, który z dwóch przypadków masz, bo drugi wymaga zmiany routingu, a nie tekstu.

Świadomie wybierz tłumaczone źródło

Gdy urządzenie jest poprawne, adres źródłowy to osobna decyzja. To tylko przykładowa pula IPv4 i przykładowy adres:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Wpisanie adresu w --to-source nie sprawia, że ktoś będzie go do ciebie routował. Dostawca nadrzędny lub właściciel adresu musi dostarczać odpowiedzi dla tego adresu do tego hosta, a adres musi być taki, którego wolno ci używać. Jeśli nie jest, reguła dopasuje i przetłumaczy, a odpowiedzi i tak pójdą gdzie indziej.

Zmiana adresu źródłowego to nie to samo co zmiana łącza nadrzędnego. Gdy prawdziwym wymaganiem jest inna ścieżka fizyczna, polityka routingu musi najpierw wybrać tę ścieżkę; SNAT przepisuje potem źródło na urządzeniu, które wybrała polityka. Więcej etykiet na eth0 nie daje ani trasy, ani upoważnienia.

Zweryfikuj połączeniem, które właśnie otworzyłeś

Otwórz nowe połączenie klienta zamiast używać ponownie istniejącego. Śledzenie połączeń zachowuje tłumaczenie zapisane na początku przepływu, więc stara sesja może nadal używać poprzedniego adresu źródłowego i sprawiać, że poprawna nowa reguła wygląda na zepsutą. Obserwuj rosnący licznik, a potem zobacz przetłumaczone źródło na kablu lub na drugim końcu.

Gdy kilka pul dzieli jeden interfejs, daj każdej jawne dopasowanie źródła i własny adres tłumaczenia, trzymaj je w zarządzanej konfiguracji zapory i zanotuj kolejność ich oceniania. Potem zapisz, co zweryfikowałeś: urządzenie z ip route get, licznik, który się ruszył, i źródło, które zobaczyła druga strona. Ten zapis odpowiada na następny raport bez powtarzania zamieszania z aliasem.

Powiązane artykuły