Statisk rutt i FRITZ!Box: peka den mot LAN-IP:n för VPN-gatewayen

Ditt hem-LAN har en FRITZ!Box som standardrouter och en liten Linux-box som sköter VPN-jobbet bredvid. Boxen når kontorsnätet, men laptopen bakom FRITZ!Box gör det inte. En statisk rutt löser detta med tre fält, och den enda verkliga svårigheten är att vägra sätta en tunneladress i gateway-fältet. Gatewayen är nästa router på ditt eget LAN, och det har den alltid varit.

Skriv upp de tre fälten innan du öppnar gränssnittet

Ta ett LAN 192.168.50.0/24, en FRITZ!Box på 192.168.50.1, och en VPN-box med fast adress 192.168.50.2 som redan har en fungerande skyddad väg till 10.40.0.0/16. Rutten säger: för det externa prefixet, lämna paketet till enheten på den fasta LAN-adressen. Den externa VPN-serverns publika endpoint och dess inre tunneladress är båda irrelevanta här, eftersom FRITZ!Box aldrig skickar något direkt till dem.

Reservera den LAN-adressen utanför DHCP-poolen, annars kommer gatewayen du konfigurerade en dag att tillhöra en telefon.

Var FRITZ!Box håller rutten

FRITZ! öppnar IPv4-ruttkontrollerna under Hemnätverk, sedan Nätverk, sedan Nätverksinställningar, med den exakta etiketten och nästlingen beroende på modell och FRITZ!OS-version. Slå på den avancerade vyn om rutttabellen är dold, lägg till en post med värdena ovan och tillämpa. Handboken för din specifika modell är värd en titt, eftersom samma funktion har flyttat mellan versioner mer än en gång. Notera den exakta formuleringen av posten du sparar, eftersom en tabellpost sällan berättar vilken skärm som skapade den.

Det här är inte samma funktion som när FRITZ!Box själv avslutar en VPN. En rutt pekar på en annan enhet; den inbyggda VPN:en är enheten.

Gatewayen måste routa, inte bara nå

En värd som når det externa nätet blir inte automatiskt en router för resten av LAN:et. VPN-boxen behöver IP-vidarebefordran påslagen, en brandväggsregel som tillåter vidarebefordran mellan LAN-gränssnittet och tunneln, och en rutt som skickar svaret tillbaka till LAN:et i stället för ut via sin egen standardväg. Att slå på vidarebefordran och glömma brandväggsregeln är den vanligaste halva lösningen, och från klientens sida ser det ut som ett routerfel.

Kontrollera det från FRITZ!Box-sidan genom att pinga LAN-adressen för VPN-boxen, och sedan från en klient genom att spåra till en extern adress och bekräfta att andra hoppet är den boxen.

Returväg och överlappande intervall

Den externa sidan behöver en rutt för 192.168.50.0/24 tillbaka genom tunneln, om du inte medvetet översätter källan på VPN-boxen. Att bevara och att översätta är olika policyer med olika loggar och olika åtkomstregler, och den statiska rutten du just lade till väljer inte mellan dem. Överlappande intervall är ett svårare problem: om ditt LAN och det externa nätet delar ett prefix kan en enda värdrutt inte skilja dem, och adressplanen måste ändras.

Att lägga till en mer specifik rutt någon annanstans på LAN:et, eller en andra VPN-klient på laptopen, vinner tyst över posten i FRITZ!Box.

Testa från en vanlig klient och testa sedan felet

Kör testet från en vanlig auktoriserad LAN-maskin, inte från VPN-boxen, eftersom boxen redan fungerade och inte bevisar något. Nå en extern tjänst och kontrollera svaret, bekräfta sedan att orelaterade internetmål fortfarande tar standardrutten och inte dras genom tunneln. Att ersätta standardrutten för att nå ett enda subnät är en mycket större ändring än trefältsposten du började med.

Koppla slutligen från VPN:en och se vad som händer. Den statiska rutten ligger kvar i tabellen medan dess gateway har förlorat den skyddade vägen, så trafiken misslyckas vid boxen i stället för att falla tillbaka till internet, och varje krav på att blockera reservtrafik hör hemma i boxens egen policy, inte i en sparad rutt.