Dlaczego ostrzeżenie vpnc o czyszczeniu tras pojawia się w kontenerze
Czyszczenie pamięci podręcznej tras to pozostałość po jądrze, które już jej nie przechowuje; błąd tylko do odczytu pochodzi z montowania w kontenerze, a nie z tunelu.
Świeże logi kontenera często kończą się skargą Read-only file system na /proc/sys/net/ipv4/route/flush, a tej linii przypisuje się winę za tunel, który może być całkowicie zdrowy. Zapis za nią celuje we wpis jądra, który nie robi już nic pożytecznego, odkąd zniknęła pamięć podręczna tras IPv4. W kontenerze /proc/sys jest montowany tylko do odczytu, więc przekierowanie jest odrzucane, zanim trafi jakakolwiek wartość, a powłoka wypisuje tę odmowę. Działający tunel może wypisywać to ostrzeżenie, dopóki stara linia pozostaje w skrypcie, a --privileged nigdy nie czyni zapisu sensownym.
Co skrypt próbował wyczyścić
Starsze skrypty połączenia kończyły się czyszczeniem pamięci podręcznej: zapis wartości do pliku kontrolnego jądra i prośba do stosu IPv4 o odrzucenie pamięci podręcznej routingu, aby nowa trasa tunelu została wybrana bez czekania na wygaśnięcie przestarzałych wpisów. Plik był adresowany pod /proc/sys/net/ipv4/, co czyniło operację przekierowaniem powłoki, a nie poleceniem routingu. Jądro 3.6 usunęło tę pamięć podręczną, a wraz z nią powód istnienia czyszczenia. Nic w obecnej ścieżce danych nie zależy od tego zapisu.
Sam wpis przetrwał jako stary plik tylko do zapisu, więc skrypt, który nadal do niego pisze, dociera do rzeczywistej ścieżki i rzeczywistej kontroli uprawnień. Na hoście zapis zwraca sukces i niczego nie zmienia. W kontenerze to samo przekierowanie trafia na /proc/sys tylko do odczytu i zawodzi z EROFS, które powłoka wypisuje jako komunikat systemu plików tylko do odczytu. W jądrach, w których ścieżka naprawdę nie istnieje, sformułowanie zmienia się na No such file or directory, a wniosek się nie zmienia.
Oba błędy mówią co innego, a różnicę warto zachować wyraźnie. Read-only file system oznacza, że jądro dotarło do wpisu i odmówiło zapisu; No such file or directory oznacza, że wpisu nie ma. Żaden komunikat nie informuje o urządzeniu tunelu, trasach ani rozwiązywaniu nazw, więc żaden nie może uzasadniać większych uprawnień.
To kolejność sprawia, że komunikat wygląda na przyczynowy. Skrypt połączenia instaluje trasy, zmienia stan interfejsu i przepisuje rozwiązywanie nazw, zanim dotrze do czyszczenia na końcu, więc ostatnia wypisana linia jest tą, którą ludzie cytują, nawet gdy każdy ważny krok zwrócił sukces. Tunel, który się zestawia i przenosi ruch, wypisując to ostrzeżenie, dokładnie odpowiada powyższemu mechanizmowi.
Sprawdź montowanie i trasę, zanim dodasz uprawnienia
Trzy odczyty oddzielają kosmetyczne ostrzeżenie od rzeczywistej awarii: czy zainstalowany skrypt nadal zawiera tę linię, jak zamontowany jest /proc/sys i dokąd faktycznie trafia ruch aplikacji. Uruchom je w tej samej przestrzeni nazw kontenera lub na hoście, na którym pojawiło się ostrzeżenie, ponieważ sprawdzenie na niepowiązanej maszynie odpowiada na inne pytanie.
grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10Odpowiedź grep jest słabsza, niż się wydaje, ponieważ trafienie dowodzi, że linia istnieje, a nie że działa bez zabezpieczenia; utrzymywany skrypt może nieść zapis wewnątrz zabezpieczenia, które go pomija. findmnt -no OPTIONS /proc/sys rozstrzyga montowanie bezpośrednio, a ro w tym wyniku oznacza, że każdy zapis poniżej tego punktu jest odrzucany, cokolwiek robi skrypt. Potem wyszukiwanie trasy pokazuje, czy miejsce docelowe potrzebne aplikacji jest rozwiązywane przez interfejs tunelu, czy przez domyślną bramę kontenera. Wyszukiwanie wybierające domyślną bramę oznacza, że tunel wstał i nic do niego nie jest routowane, co jest problemem routingu, a nie uprawnień.
Skąd naprawdę pochodzi poprawka
Utrzymywana poprawka mieszka w skrypcie, a nie we flagach kontenera. upstream vpnc-script zmienił sposób obsługi tej operacji, więc porównaj kopię w obrazie z bieżącym upstreamem i zaktualizuj przez pakiet lub budowę obrazu, która ją dostarcza. Plik edytowany ręcznie w działającym kontenerze nie podlega przeglądowi i nie przetrwa następnej budowy.
--privileged jest udokumentowany jako przyznający wszystkie uprawnienia oraz szeroki dostęp do urządzeń, co jest dużą ustępstwem za komunikat, który niczego nie zmienia, więc wskaż brakujące uprawnienie, jeśli naprawdę go brakuje. Po aktualizacji powtórz wyszukiwanie trasy i pozwól aplikacji użyć tunelu, ponieważ cichy log i działające połączenie to osobne wyniki.