Statiese roete in die FRITZ!Box: wys na die LAN-IP van die VPN-gateway

Jou tuis-LAN het 'n FRITZ!Box as die verstekroeteerder en 'n klein Linux-boks wat VPN-werk langsaan doen. Die boks kan die kantoor-netwerk bereik, en die skootrekenaar agter die FRITZ!Box kan nie. 'n Statiese roete los dit in drie velde op, en die enigste werklike moeilikheid is om te weier om 'n tonneladres in die gateway-veld te sit. Die gateway is die volgende roeteerder op jou eie LAN, en dit was nog altyd so.

Skryf die drie velde voordat jy die koppelvlak oopmaak

Neem 'n LAN van 192.168.50.0/24, 'n FRITZ!Box by 192.168.50.1, en 'n VPN-boks met 'n vaste adres van 192.168.50.2 wat reeds 'n werkende beskermde pad na 10.40.0.0/16. Die roete sê: vir daardie afgeleë voorvoegsel, gee die pakkie aan die toestel by die vaste LAN-adres. Die afgeleë VPN-bediener se publieke eindpunt en sy binneste tonneladres is albei hier irrelevant, want die FRITZ!Box stuur nooit iets direk daarheen nie.

Reserveer daardie LAN-adres buite die DHCP-poel, anders sal die gateway wat jy opgestel het eendag aan 'n selfoon behoort.

Waar die FRITZ!Box die roete hou

FRITZ! maak die IPv4-roetebeheerders oop onder Tuisnetwerk, dan Netwerk, dan Netwerkinstellings, met die presiese etiket en nesteling afhangende van die model en FRITZ!OS-weergawe. Aktiveer die gevorderde aansig as die roetetabel versteek is, voeg een inskrywing met die bostaande waardes by en pas dit toe. Die gids vir jou spesifieke model is 'n blik werd, want dieselfde funksie het al meer as een keer tussen weergawes geskuif. Let op die presiese bewoording van die inskrywing wat jy stoor, want 'n tabelinskrywing sê selde watter skerm dit geskep het.

Dit is nie dieselfde funksie as wanneer die FRITZ!Box self 'n VPN termineer nie. 'n Roete wys na 'n ander toestel; die ingeboude VPN is die toestel.

Die gateway moet roeteer, nie net bereik nie

'n Gasheer wat die afgeleë netwerk kan bereik, is nie outomaties 'n roeteerder vir die res van die LAN nie. Die VPN-boks het IP-aansturing nodig, 'n brandmuurbeleid wat aansturing tussen die LAN-koppelvlak en die tonnel toelaat, en 'n roete wat die antwoord terug na die LAN stuur eerder as uit sy eie verstekpad. Aansturing aanskakel en die brandmuur-reël vergeet is die mees algemene halwe oplossing, en dit lyk van die kliënt se kant soos 'n roeteringsfout.

Toets dit van die FRITZ!Box-kant deur die VPN-boks se LAN-adres te ping, en dan van 'n kliënt af deur na 'n afgeleë adres te traceroute en te bevestig dat die tweede hop daardie boks is.

Terugpad en oorvleuelende reekse

Die afgeleë kant het 'n roete vir 192.168.50.0/24 terug deur die tonnel nodig, tensy jy die bron doelbewus by die VPN-boks vertaal. Bewaring en vertaling is verskillende beleide met verskillende logboeke en verskillende toegangsreëls, en die statiese roete wat jy pas bygevoeg het, kies nie tussen hulle nie. Oorvleuelende reekse is 'n moeiliker probleem: as jou LAN en die afgeleë netwerk 'n voorvoegsel deel, kan 'n enkele gasheerroete hulle nie onderskei nie, en die adresplan moet verander.

Om 'n meer spesifieke roete elders op die LAN by te voeg, of 'n tweede VPN-kliënt op die skootrekenaar, sal die FRITZ!Box-inskrywing stilweg oortref.

Toets van 'n gewone kliënt, dan toets die fout

Voer die toets uit vanaf 'n gewone gemagtigde LAN-masjien, nie vanaf die VPN-boks nie, want die boks het al gewerk en bewys niks. Bereik 'n afgeleë diens en kontroleer die antwoord, bevestig dan dat onverwante internetbestemmings steeds die verstekroete volg en nie deur die tonnel gesleep word nie. Om die verstekroete te vervang om een subnet te bereik is 'n baie groter verandering as die drie-veld-inskrywing waarmee jy begin het.

Laastens, ontkoppel die VPN en kyk wat gebeur. Die statiese roete bly in die tabel terwyl sy gateway die beskermde pad verloor het, so verkeer faal by die boks eerder as om na die internet terug te val, en enige vereiste om terugvalverkeer te blokkeer hoort in die boks se eie beleid, nie in 'n gestoorde roete nie.