Statika itinero en la FRITZ!Box: direktu ĝin al la LAN-IP de la VPN-enirejo

Via hejma LAN havas FRITZ!Box kiel implicitan enkursigilon kaj malgrandan Linux-skatolon apude, kiu plenumas VPN-devon. La skatolo atingas la oficejan reton, sed la tekkomputilo malantaŭ la FRITZ!Box ne. Statika itinero solvas tion per tri kampoj, kaj la sola vera malfacilaĵo estas rifuzi meti tunel-adreson en la enirejan kampon. La enirejo estas la sekva enkursigilo en via propra LAN, kaj ĝi ĉiam estis tia.

Skribu la tri kampojn antaŭ ol malfermi la interfacon

Prenu LAN-on 192.168.50.0/24, FRITZ!Box ĉe 192.168.50.1, kaj VPN-skatolon kun fiksa adreso 192.168.50.2, kiu jam havas funkciantan protektitan vojon al 10.40.0.0/16. La itinero diras: por tiu malproksima prefikso, transdonu la paketon al la aparato ĉe la fiksa LAN-adreso. La publika finpunkto de la malproksima VPN-servilo kaj ĝia interna tunel-adreso estas ambaŭ nerelevantaj ĉi tie, ĉar la FRITZ!Box neniam sendas ion rekte al ili.

Rezervu tiun LAN-adreson ekster la DHCP-baseno, alie la enirejo, kiun vi agordis, iam apartenos al telefono.

Kie la FRITZ!Box tenas la itinero

FRITZ! malfermas la IPv4-itinrajn regilojn sub Hejma reto, poste Reto, poste Retaj agordoj, kun la preciza etikedo kaj nestado dependaj de la modelo kaj la versio de FRITZ!OS. Ŝaltu la etenditan vidon se la itinra tabelo estas kaŝita, aldonu unu rikordon kun la supraj valoroj kaj apliku. Indas rigardi la gvidilon por via specifa modelo, ĉar la sama funkcio moviĝis inter eldonoj pli ol unufoje. Notu la precizan vortigon de la rikordo, kiun vi konservas, ĉar tabela rikordo malofte diras, kiun ekranon ĝi produktis.

Ĉi tio ne estas la sama funkcio kiel la FRITZ!Box mem finanta VPN-on. Itinero montras al alia aparato; la enkonstruita VPN estas la aparato.

La enirejo devas enkursigi, ne nur atingi

Gastiganto, kiu atingas la malproksiman reton, ne estas aŭtomate enkursigilo por la resto de la LAN. La VPN-skatolo bezonas ŝaltitan IP-plusendadon, fajroŝirman politikon, kiu permesas plusendadon inter la LAN-interfaco kaj la tunelo, kaj itinero, kiu resendas la respondon al la LAN anstataŭ eliri per sia propra implicita vojo. Ŝalti plusendadon kaj forgesi la fajroŝirman regulon estas la plej ofta duona riparo, kaj de la klienta flanko ĝi aspektas kiel itinera fiasko.

Kontrolu ĝin de la FRITZ!Box-flanko per pingado al la LAN-adreso de la VPN-skatolo, poste de kliento per spurigo al malproksima adreso kaj konfirmo, ke la dua salto estas tiu skatolo.

Revena vojo kaj interkovraj gamoj

La malproksima flanko bezonas itinero por 192.168.50.0/24 reen tra la tunelo, krom se vi intence tradukas la fonton ĉe la VPN-skatolo. Konservi kaj traduki estas malsamaj politikoj kun malsamaj protokoloj kaj malsamaj alirreguloj, kaj la statika itinero, kiun vi ĵus aldonis, ne elektas inter ili. Interkovraj gamoj estas pli malfacila problemo: se via LAN kaj la malproksima reto dividas prefikson, unu gastiganta itinero ne povas distingi ilin, kaj la adresa plano devas ŝanĝiĝi.

Aldono de pli specifa itinero aliloke en la LAN, aŭ dua VPN-kliento sur la tekkomputilo, kviete venkos la rikordon de la FRITZ!Box.

Testu de normala kliento, poste testu la fiaskon

Farigu la teston de ordinara rajtigita LAN-maŝino, ne de la VPN-skatolo, ĉar la skatolo jam funkciis kaj pruvas nenion. Atingu malproksiman servon kaj kontrolu la respondon, poste konfirmu, ke nerilataj interretaj cellokoj ankoraŭ uzas la implicitan itinero kaj ne estas trenataj tra la tunelo. Anstataŭigi la implicitan itinero por atingi unu subreton estas multe pli granda ŝanĝo ol la tri-kampa rikordo, kun kiu vi komencis.

Fine, malkonektu la VPN-on kaj vidu, kio okazas. La statika itinero restas en la tabelo dum ĝia enirejo perdis la protektitan vojon, do trafiko fiaskas ĉe la skatolo anstataŭ fali reen al la interreto, kaj ajna postulo bloki rezervan trafikon apartenas al la politiko de la skatolo mem, ne al konservita itinero.