Uwaga przedstawiona poniżej metoda nie jest uniwersalna, ale może być użyta jako „szybki hack” w przypadku niespodziewanego fakapu z VPNem.

Fakap – źródło problemu

Ogólna miłość korporacji do wykorzystania OSS jest znana. Oczywiście korpy biorą tyle, ile się da, a jak coś nie działa, to ścigają twórców, żeby naprawiali soft. Jest jednak pewna dziedzina, gdzie korporacje unikają OSS jak ognia – VPN. Zamiast po ludzku, użyć OpenVPN każde korpo kupuje jakiegoś VPNa. Oczywiście nie wykupuje wsparcia dla użytkowników, którzy korzystają z czegoś innego niż korpo-windows. Każdy taki soft ma własnego klienta, który działa po swojemu i po swojemu ingeruje w tabele routingu, opakowuje interfejsy sieciowe czy tworzy reguły firewalla.

W ogólności przepływ pracy jest taki sam dla każdego klienta. W momencie zalogowania dodawane są odpowiednie konfiguracje, które powinny zostać usunięte gdy wylogujemy się z VPNa. Problem pojawi się w momencie, gdy z jakiegoś powodu klient VPN nie zostanie prawidłowo zamknięty. W moim przypadku było to „szybki reset” po kolejnej awarii kamery (temat na osobny wpis). Po restarcie sieć po prostu nie się podniosła. Przy czym był to dość zwodniczy objaw.

Po pierwsze interfejs sieciowy działał i mogłem połączyć się z routerem. Mogłem też dobić się do drukarki sieciowej, a Factorio widziało serwer w LANie. Po drugie inni użytkownicy korzystający z tego routera widzieli mój komputer oraz mogli normalnie korzystać z internetu. Po trzecie, tethering przez USB działał normalnie i miałem dostęp do sieci. Zatem coś się było zjebało między routerem, kartą sieciową i konfiguracją interfejsu.

Naprawa

W pierwszym odruchu połączyłem się przez USB, odpaliłem VPNa, rozłączyłem i taka akcja powinna pomóc. Klient powinien wyczyścić swoją konfigurację i pozwolić mi na normalną pracę. Niestety nie 🙁 I tu mnie nic nie tknęło, że to jest duperela z profilem połączenia… pół nocy w dupe.

Reset tabeli routingu, restart managera sieciowego, wyczyszczenie /etc/hosts, wyczyszczenie reguł firewalla i ich ponowna instalacja (tylko ptorzebnych). Nic nie dało rady. Lekka załamka.

Oświecenie

Koniec końców poszedłem do /etc/NetworkManager/system-connections. W tym miejscu składowane są informacje o profilach połączeń. Zrobiłem sobie kopię, po czym wywaliłem profil połączenia kablowego i stworzyłem nowy, pod inną nazwą. Bangla!

Co się było zjebało

Jak wspomniałem w /etc/NetworkManager/system-connections przechowywane są profile połączeń. Co dokładnie można tam ustawić opisuje manual. W moim przypadku krytyczne okazały się dwa wpisy zmieniane przez klienta VPN. Pierwszy z nich to autoconnect-priority, który został ustawiony na -999. Dzięki temu połączenie VPN jest ważniejsze i w razie krótkotrwałej (sekundowej) awarii połączenia sieciowego nie nastąpi całkowite zerwanie połączenia VPN. Sieć po chwili wróci, a klient VPN zostanie wybrany jako domyślny kanał komunikacji. Drugim jest para dns, dns-search. Pierwszy do tablica IP serwerów DNS, drugi to nazwy domenowe. Klient VPN ustawił serwer DNS na IP w sieci wirtualnej (10.x.x.x) na którym „wisi” jego własny serwer DNS i własną listę domen. W efekcie po restarcie nie dość, że interfejs kablowy miał najniższy priorytet, to jeszcze nie mógł znaleźć żadnego DNSa.

To wyjaśnia, dlaczego mogłem połączyć się z routerem, bo łączę się po IP, a nie mogłem wyjść w świat. Po prostu miałem internet bez DNSa. Przy okazji można to naprawić w prostszy sposób, ręcznie ustawiając IP DNSów i usuwając.

Wpis ku pamięci, bo znając życie za pół roku znowu coś popusuję.