Hjemme-LAN-et ditt har en FRITZ!Box som standardruter og en liten Linux-boks som gjør VPN-jobben ved siden av. Boksen når kontornettet, men laptopen bak FRITZ!Box gjør det ikke. En statisk rute fikser dette med tre felter, og den eneste virkelige vanskeligheten er å nekte å sette en tunneladresse i gateway-feltet. Gatewayen er den neste ruteren på ditt eget LAN, og det har den alltid vært.

Skriv de tre feltene før du åpner grensesnittet

Ta et LAN 192.168.50.0/24, en FRITZ!Box på 192.168.50.1, og en VPN-boks med fast adresse 192.168.50.2 som allerede har en fungerende beskyttet vei til 10.40.0.0/16. Ruten sier: for det eksterne prefikset, gi pakken til enheten på den faste LAN-adressen. Den eksterne VPN-serverens offentlige endepunkt og dens indre tunneladresse er begge irrelevante her, fordi FRITZ!Box aldri sender noe direkte til dem.

FeltVerdiHva det navngir
IPv4-nettverk10.40.0.0Det eksterne målnettverket
Nettmaske255.255.0.0Hvor stort det målet er
Gateway192.168.50.2Den neste ruteren på hjemme-LAN-et

Reserver den LAN-adressen utenfor DHCP-poolen, ellers vil gatewayen du konfigurerte en dag tilhøre en telefon.

Hvor FRITZ!Box holder ruten

FRITZ! åpner IPv4-rutekontrollene under Hjemmenettverk, deretter Nettverk, deretter Nettverksinnstillinger, med den nøyaktige etiketten og nesting avhengig av modell og FRITZ!OS-versjon. Slå på den avanserte visningen hvis rutetabellen er skjult, legg til én oppføring med verdiene ovenfor og bruk den. Veiledningen for din spesifikke modell er verdt en titt, fordi samme funksjon har flyttet mellom utgivelser mer enn én gang. Legg merke til den nøyaktige ordlyden i oppføringen du lagrer, fordi en tabelloppføring sjelden forteller hvilken skjerm som laget den.

Dette er ikke samme funksjon som når FRITZ!Box selv avslutter en VPN. En rute peker på en annen enhet; den innebygde VPN-en er enheten.

Gatewayen må rute, ikke bare nå

En vert som når det eksterne nettverket er ikke automatisk en ruter for resten av LAN-et. VPN-boksen trenger IP-videresending slått på, en brannmurregel som tillater videresending mellom LAN-grensesnittet og tunnelen, og en rute som sender svaret tilbake til LAN-et i stedet for ut via sin egen standardvei. Å slå på videresending og glemme brannmurregelen er den vanligste halve løsningen, og fra klientens side ser det ut som en ruterfeil.

Sjekk det fra FRITZ!Box-siden ved å pinge LAN-adressen til VPN-boksen, og deretter fra en klient ved å spore til en ekstern adresse og bekrefte at andre hopp er den boksen.

Returvei og overlappende områder

Den eksterne siden trenger en rute for 192.168.50.0/24 tilbake gjennom tunnelen, med mindre du bevisst oversetter kilden på VPN-boksen. Å bevare og å oversette er forskjellige policyer med forskjellige logger og forskjellige tilgangsregler, og den statiske ruten du nettopp la til velger ikke mellom dem. Overlappende områder er et vanskeligere problem: hvis LAN-et ditt og det eksterne nettverket deler et prefiks, kan én vertsrute ikke skille dem, og adresseplanen må endres.

Å legge til en mer spesifikk rute et annet sted på LAN-et, eller en andre VPN-klient på laptopen, vil stille vinne over oppføringen i FRITZ!Box.

Test fra en vanlig klient, og test deretter feilen

Kjør testen fra en vanlig autorisert LAN-maskin, ikke fra VPN-boksen, fordi boksen allerede virket og ikke beviser noe. Nå en ekstern tjeneste og kontroller svaret, og bekreft deretter at urelaterte internettmål fortsatt tar standardruten og ikke blir dratt gjennom tunnelen. Å erstatte standardruten for å nå ett subnett er en mye større endring enn trefeltoppføringen du begynte med.

Til slutt, koble fra VPN-en og se hva som skjer. Den statiske ruten blir i tabellen mens gatewayen har mistet den beskyttede veien, så trafikken feiler ved boksen i stedet for å falle tilbake til internett, og ethvert krav om å blokkere fallback-trafikk hører hjemme i boksens egen policy, ikke i en lagret rute.

Relaterte artikler