Statische route in de FRITZ!Box: wijs hem naar het LAN-IP van de VPN-gateway

Je thuis-LAN heeft een FRITZ!Box als standaardrouter en een kleine Linux-box die ernaast de VPN-taak doet. De box bereikt het kantoornetwerk, de laptop achter de FRITZ!Box niet. Een statische route lost dit op met drie velden, en de enige echte moeilijkheid is weigeren om een tunneladres in het gateway-veld te zetten. De gateway is de volgende router op je eigen LAN, en dat is hij altijd geweest.

Schrijf de drie velden op voordat je de interface opent

Neem een LAN 192.168.50.0/24, een FRITZ!Box op 192.168.50.1, en een VPN-box met een vast adres 192.168.50.2 die al een werkend beveiligd pad naar 10.40.0.0/16 heeft. De route zegt: voor dat externe prefix gaat het pakket naar het apparaat op het vaste LAN-adres. Het publieke endpoint van de externe VPN-server en zijn interne tunneladres zijn hier beide irrelevant, omdat de FRITZ!Box er nooit iets rechtstreeks naartoe stuurt.

Reserveer dat LAN-adres buiten de DHCP-pool, anders is de gateway die je hebt ingesteld op een dag van een telefoon.

Waar de FRITZ!Box de route bewaart

FRITZ! opent de IPv4-routeregels onder Thuisnetwerk, dan Netwerk, dan Netwerkinstellingen, waarbij het exacte label en de nesting afhangen van het model en de FRITZ!OS-versie. Schakel de uitgebreide weergave in als de routetabel verborgen is, voeg één item met de waarden hierboven toe en pas het toe. De handleiding voor jouw specifieke model is een blik waard, omdat dezelfde functie meer dan eens tussen releases is verhuisd. Let op de exacte formulering van het item dat je opslaat, want een tabelitem vertelt zelden welk scherm het heeft gemaakt.

Dit is niet dezelfde functie als wanneer de FRITZ!Box zelf een VPN beëindigt. Een route wijst naar een ander apparaat; de ingebouwde VPN is dat apparaat.

De gateway moet routeren, niet alleen bereiken

Een host die het externe netwerk bereikt is niet automatisch een router voor de rest van het LAN. De VPN-box heeft IP-forwarding nodig, een firewallregel die forwarding tussen de LAN-interface en de tunnel toestaat, en een route die het antwoord terug naar het LAN stuurt in plaats van via zijn eigen standaardpad naar buiten. Forwarding aanzetten en de firewallregel vergeten is de meest voorkomende halve oplossing, en vanaf de client ziet het eruit als een routeringsfout.

Controleer het vanaf de FRITZ!Box-kant door het LAN-adres van de VPN-box te pingen, en daarna vanaf een client door naar een extern adres te traceren en te bevestigen dat de tweede hop die box is.

Terugweg en overlappende bereiken

De externe kant heeft een route nodig voor 192.168.50.0/24 terug door de tunnel, tenzij je de bron bewust op de VPN-box vertaalt. Bewaren en vertalen zijn verschillende policies met verschillende logboeken en verschillende toegangsregels, en de statische route die je net hebt toegevoegd kiest daar niet tussen. Overlappende bereiken zijn een lastiger probleem: als je LAN en het externe netwerk hetzelfde prefix delen, kan één hostroute ze niet onderscheiden, en het adresplan moet veranderen.

Een specifiekere route elders op het LAN toevoegen, of een tweede VPN-client op de laptop, wint stil van het item in de FRITZ!Box.

Test vanaf een normale client, en test daarna de storing

Voer de test uit vanaf een gewone geautoriseerde LAN-machine, niet vanaf de VPN-box, want de box werkte al en bewijst niets. Bereik een externe dienst en controleer het antwoord, bevestig dan dat niet-verwante internetbestemmingen nog steeds de standaardroute nemen en niet door de tunnel worden getrokken. De standaardroute vervangen om één subnet te bereiken is een veel grotere wijziging dan het driedelige item waarmee je begon.

Trek ten slotte de VPN los en kijk wat er gebeurt. De statische route blijft in de tabel staan terwijl zijn gateway het beveiligde pad kwijt is, dus verkeer faalt bij de box in plaats van terug te vallen op internet, en elke eis om fallbackverkeer te blokkeren hoort in het beleid van de box zelf, niet in een opgeslagen route.