VPN w FRITZ!Box łączy się, ale nic nie odpowiada: WireGuard czy IPSec
Połączony tunel FRITZ!Box, który nie dociera do sieci LAN, to problem adresacji. Sprawdź cztery pola IPSec lub peer WireGuard przed ponownym importem.
Tunel zgłasza połączenie, ikona jest zielona, a nic w domowej sieci LAN nie odpowiada. To najczęstsza skarga dotycząca zdalnego dostępu FRITZ!Box i prawie nigdy nie jest winny sam tunel. Błędny jest plan adresów, tożsamość podsieci albo tablica routingu klienta. Który z nich w końcu będziesz debugować, zależy od tego, czy wybrałeś WireGuard, czy starszy IPSec Fernzugang, więc zacznij od wiedzy, co właściwie skonfigurowałeś.
Tunel się podnosi, a sieć LAN milczy
Tunel, który się zestawia, dowodzi, że klucze i punkt końcowy są poprawne. Nie dowodzi jednak, że klient otrzymał adres, do którego skrzynka umie routować, ani że klient wie, które prefiksy należą do tunelu. To dwa odrębne sukcesy i tylko drugi pozwala dotrzeć do drukarki.
Najpierw sprawdź adres klienta, potem jego tablicę routingu.
Jeśli przydzielony adres leży poza podsiecią LAN, skrzynka nie ma gdzie routować z powrotem. Jeśli leży w zakresie DHCP, skrzynka może dać ten sam adres urządzeniu lokalnemu. Oba przypadki dają tunel, który się łączy, i sieć LAN, która cię ignoruje.
Co naprawdę konfiguruje każda opcja
Opcja IPSec generuje plik konfiguracyjny dla jednego użytkownika, zawierający klucz wstępnie współdzielony i adresację. Importujesz go do klienta mówiącego tym samym profilem, co w Windows oznacza zwykle narzędzie producenta, a nie klienta wbudowanego. Opcja WireGuard generuje peer dla jednego urządzenia: parę kluczy, adres wewnątrz tunelu i punkt końcowy.
Ta różnica decyduje o modelu utrzymania. Każde urządzenie WireGuard to osobny peer z własnym kluczem, więc odebranie zgubionego telefonu oznacza usunięcie jednego peera, a pozostałe nadal działają. IPSec odbiera, zmieniając wspólny sekret lub konfigurację użytkownika, co jest grubsze i dotyka każde urządzenie, które go używa.
Żadna z opcji nie jest przestarzała. Ścieżka IPSec pozostaje obsługiwana wszędzie tam, gdzie druga strona nie może uruchomić WireGuard.
Pola IPSec, które dają martwy tunel
Cztery wartości muszą zgadzać się z twoją siecią LAN, a trzy z nich zawodzą w sposób, który wygląda jak zepsuty tunel.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
To adres sieci najczęściej ludzi łapie. Podsieć identyfikuje się jej pierwszym adresem, który zwykle kończy się zerem, a wpisanie tam adresu hosta daje konfigurację, która wygląda całkowicie wiarygodnie i nigdy się nie łączy. Zakres DHCP ma znaczenie z innego powodu: klienci tunelu dostają adresy zwykle powyżej niego, więc zakres zjadający całą podsieć nie zostawia nic do rozdania.
Nakładające się podsieci to drugi klasyczny przypadek. Jeśli zdalna sieć LAN, do której dołączasz, używa tego samego prefiksu co sieć, na której siedzisz, routing nie potrafi ich rozróżnić, a przenumerowanie jednej strony to jedyne realne rozwiązanie. Żadna ilość konfiguracji klienta tego nie rozwiąże.
Dlaczego WireGuard zawodzi inaczej
WireGuard nie ma klucza wstępnie współdzielonego, który można wpisać błędnie, więc jego awarie skupiają się wokół definicji peera. Lista dozwolonych adresów IP, która pomija prefiks sieci LAN, daje tunel, który nic nie przenosi, bo klient nigdy nie wysyła do niego ruchu kierowanego do LAN. Nieaktualny klucz publiczny po którejkolwiek stronie daje uścisk dłoni, który nigdy się nie kończy. Brak punktu końcowego lub zły port daje ciszę zamiast błędu.
Porównaj obie strony pole po polu, zamiast ponownie importować plik i mieć nadzieję.
Jedyną wspólną awarią jest kolizja podsieci. WireGuard chętnie zbuduje tunel do sieci, która pokrywa się z twoją lokalną, a potem tablica routingu decyduje, który z dwóch identycznych prefiksów wygrywa.
Udowodnij to z zewnątrz, a potem zachowaj drogę powrotną
Testuj z połączenia mobilnego, nigdy od środka sieci LAN, bo od środka testujesz ścieżkę, która w ogóle nie obejmuje tunelu. Zapisz, którego portu używa każda opcja, zanim ją włączysz, i przekieruj ten port na skrzynkę.
Trzymaj wygenerowany plik tam, gdzie dotrzesz bez tunelu, i przy okazji zapisz zewnętrzną nazwę skrzynki.
Konfiguracja, która nigdy nie była testowana z zewnątrz, jest planem, a nie działającą ścieżką dostępu zdalnego. Testuj jeden host sieci LAN po adresie, a nie po nazwie, żeby awaria DNS nie została wzięta za awarię routingu.