Trzy projekty rozwiązują ten sam problem laboratoryjny: mała sieć LAN musi wychodzić przez partnera WireGuard, a sama bramka zachowuje zwykłe łącze nadrzędne. Kusicący skrót to przeniesienie trasy domyślnej routera do tunelu, ale to psuje własną ścieżkę zarządzania urządzenia i wszystko inne, co ono przekazuje. Ciekawą opcją jest routing polityczny ograniczony do jednego interfejsu i jednego prefiksu. Wybierz między nimi, odpowiadając na trzy pytania o maszynę, którą naprawdę masz.

Zdecyduj, gdzie mieszka wyjście

Pierwsze pytanie: czy ten host przekazuje też coś innego? Dedykowana bramka laboratoryjna może żyć z polityką przekazywania, która domyślnie wszystko odrzuca. Router z obowiązkami produkcyjnymi nie może, a nakładanie konkurencyjnego zestawu reguł na zarządzany firewall to właśnie sposób, w jaki planuje się awarie. Drugie: czy możesz posiadać dwa obiekty polityki i ich kolejność między restartami? Trzecie: czy twój partner autoryzuje adres źródłowy tunelu i oferuje wyjście do internetu? Partner, który udostępnia tylko sieć prywatną, to inny produkt i żadna lokalna zmiana routingu tego nie naprawi. Jeśli którakolwiek odpowiedź brzmi nie, umieść wyjście w przestrzeni nazw albo w jednorazowej maszynie wirtualnej.

Przestrzeń nazw lub VM kosztuje pamięć i daje czysty promień rażenia. Routing polityczny kosztuje dwie reguły i zostawia ci jedno urządzenie do debugowania.

Wybierz wyjście, które autoryzuje twoje źródło

Większość awarii w tym laboratorium zdarza się, zanim istnieje choć jedna reguła firewalla. Operator wyjścia musi akceptować adres źródłowy, który niosą twoje pakiety po translacji, a w tym projekcie jest to adres tunelu, nie prefiks LAN. Dlatego maskowanie należy do projektu od początku, a nie jako późny dodatek.

Potwierdź trzy rzeczy u operatora: partner autoryzuje adres twojego tunelu, przekazuje IPv4 zamiast kończyć na sobie i stosuje NAT wyjściowy. Bez pierwszego twoje pakiety docierają i znikają. Bez trzeciego wychodzą z prywatnym źródłem i giną na następnym skoku. Następnie sprawdź, czy wg-quick nie instaluje własnej trasy domyślnej, czemu zapobiega Table = off; to ustawienie tłumi tworzenie tras, a nie kontrole AllowedIPs po stronie partnera ani jego obsługę DNS.

Dwa obiekty polityki wykonują sterowanie

Sterowanie wymaga tablicy i reguły. Tablica trzyma dwie trasy: prefiks LAN wychodzący z interfejsu LAN i trasę domyślną wychodzącą z tunelu. Reguła wysyła do tablicy ruch, który przychodzi na interfejs LAN i niesie ten prefiks. Użyj selektora iif razem z dopasowaniem źródła, bo własne pakiety WireGuard bramki powstają lokalnie i nigdy nie pasują do interfejsu wejściowego.

Strażnik przychodzi przed wyszukiwaniem, nie po nim. Ta kolejność to cała właściwość bezpieczeństwa projektu.

Strażnik to druga reguła na tym samym selektorze, której werdykt to unreachable. Daj jej wyższy priorytet liczbowy, aby wyszukiwanie nadal wygrywało, dopóki tunel jest podniesiony. Gdy trasa tunelu znika, wyszukiwanie nic nie zwraca, a strażnik zatrzymuje poszukiwanie, zamiast pozwolić mu spaść do trasy domyślnej WAN w tablicy głównej.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Zamknij lukę zapasową, zanim ją otworzysz

Najpierw zainstaluj strażnika, a potem wyszukiwanie. Odwrotna kolejność zostawia okno kilku sekund, w którym ruch klienta testowego może dotrzeć do łącza nadrzędnego.

Filtr dopełnia obraz. W haku forward zaakceptuj kierunek z LAN do tunelu dla prefiksu testowego oraz ustalony kierunek powrotny, a potem odrzuć wszystko inne; NAT dla tego prefiksu na interfejs tunelu trafia do postrouting. Właśnie pozostawienie policy drop na łańcuchu przekazywania zamienia brakującą trasę w ciszę zamiast w wyciek. Filtrowanie trasy odwrotnej wymaga trybu luźnego na interfejsie tunelu, bo publiczne źródło przychodzące po dekapulacji ma najlepszą trasę odwrotną po stronie WAN. Linux bierze wyższą z wartości all i dla interfejsu, więc ustawienie interfejsu tunelu to nie to samo co osłabienie walidacji wszędzie.

Udowodnij to przypadkiem awarii

Zadaj jądru precyzyjne pytanie, podając adres źródłowy klienta i interfejs, na który przychodzi. Wyszukiwanie bez obu odpowiada na inne pytanie i w obu przypadkach będzie wyglądać poprawnie. Potem spójrz na liczniki firewalla, stan transferu partnera i usługę samego klienta.

Przetestuj usuwanie porządnie. Zatrzymaj tunel, zostawiając regułę i filtr na miejscu: klient powinien stanąć, a własny ruch bramki powinien nadal działać. Następnie zatrzymaj partnera bez dotykania lokalnego interfejsu, i to jest przypadek, który łapie projekty polegające wyłącznie na obecności trasy. Na koniec uruchom ponownie i ponownie sprawdź kolejność reguł, bo hak demontażu usuwający strażnika oddaje cały projekt tablicy głównej. Zapisz numer tablicy, priorytety i nazwy interfejsów na zgłoszeniu zmiany, bo następna osoba dodająca regułę będzie tą, która to zepsuje.

Powiązane artykuły