Kumokonekta ang VPN ng FRITZ!Box pero walang sumasagot: WireGuard o IPSec

Sinasabi ng tunnel na nakakonekta ito, berde ang icon, at walang sumasagot sa LAN ng bahay. Ito ang pinakakaraniwang reklamo tungkol sa remote access ng FRITZ!Box, at halos hindi kailanman ang tunnel mismo ang mali. Ang plano ng address, ang pagkakakilanlan ng subnet o ang routing table ng client ang mali. Alin sa mga ito ang huli mong i-debug ay depende sa kung pinili mo ang WireGuard o ang mas lumang IPSec Fernzugang, kaya magsimula sa pag-alam kung alin talaga ang na-configure mo.

Bumabangon ang tunnel at nananatiling tahimik ang LAN

Ang tunnel na nabuo ay nagpapatunay na tama ang mga key at ang endpoint. Hindi nito pinatutunayan na nabigyan ang client ng address na maaaring i-route ng box, o alam ng client kung aling mga prefix ang kabilang sa tunnel. Dalawang magkaibang tagumpay ito, at ang pangalawa lamang ang magpapahintulot sa iyo na maabot ang printer.

Suriin muna ang address ng client, pagkatapos ang routing table nito.

Kung ang itinalagang address ay nasa labas ng subnet ng LAN, walang mapaglalagyan ng ruta pabalik ang box. Kung ito ay nasa loob ng saklaw ng DHCP, maaaring ibigay ng box ang parehong address sa isang lokal na device. Pareho nitong ginagawa ang tunnel na kumokonekta at LAN na binabalewala ka.

Ano ang aktuwal na nako-configure ng bawat opsyon

Ang opsyon na IPSec ay gumagawa ng configuration file para sa isang user, na naglalaman ng pre-shared key at ng addressing. Ini-import mo ito sa isang client na nagsasalita ng parehong profile, na sa Windows ay karaniwang nangangahulugan ng tool ng vendor at hindi ang built-in na client. Ang opsyon na WireGuard ay gumagawa ng peer para sa isang device: isang pares ng key, isang address sa loob ng tunnel at isang endpoint.

Ang pagkakaibang iyon ang nagtatakda ng modelo ng maintenance mo. Ang bawat device na WireGuard ay hiwalay na peer na may sariling key, kaya ang pag-revoke ng nawawalang telepono ay nangangahulugan ng pagbura ng isang peer habang patuloy na gumagana ang iba. Ang IPSec ay nagre-revoke sa pamamagitan ng pagbabago ng shared secret o ng configuration ng user, na mas magaspang at nakakaapekto sa bawat device na gumagamit nito.

Wala sa dalawang opsyon ang lipas na. Ang ruta ng IPSec ay nananatiling sinusuportahan kung saan hindi kayang patakbuhin ng malayong dulo ang WireGuard.

Ang mga field ng IPSec na gumagawa ng patay na tunnel

Apat na halaga ang dapat tumugma sa iyong LAN, at tatlo sa kanila ay nabigo sa paraang mukhang sirang tunnel.

Ang address ng network ang humuhuli sa mga tao. Nakikilala ang subnet sa pamamagitan ng una nitong address, na karaniwang nagtatapos sa zero, at ang paglalagay ng address ng host doon ay gumagawa ng configuration na mukhang lubos na kapani-paniwala at hindi kailanman kumokonekta. Mahalaga ang saklaw ng DHCP sa ibang dahilan: ang mga client ng tunnel ay karaniwang itinatakda sa itaas nito, kaya ang saklaw na umuubos sa buong subnet ay walang natitira upang ipamahagi.

Ang mga subnet na nagsasapawan ay ang isa pang klasikong kaso. Kung ang malayong LAN na sinasalihan mo ay gumagamit ng parehong prefix ng LAN na iyong kinauupuan, hindi kayang paghiwalayin ng routing ang dalawa, at ang muling pagbilang ng isang panig ang tanging tunay na lunas. Walang dami ng configuration ng client ang makakalutas nito.

Bakit nabigo ang WireGuard nang iba

Walang pre-shared key ang WireGuard na maaaring maling i-type, kaya nagkukumpol ang mga pagkabigo nito sa paligid ng depinisyon ng peer. Ang listahan ng pinapayagang IP na naglalaktawan sa prefix ng LAN ay gumagawa ng tunnel na walang dinadala, dahil hindi kailanman nagpapadala ang client ng trapikong patungo sa LAN sa loob nito. Ang lumang public key sa alinmang panig ay gumagawa ng handshake na hindi kailanman natatapos. Ang nawawalang endpoint o maling port ay gumagawa ng katahimikan sa halip na error.

Paghambingin ang dalawang panig field sa field sa halip na muling mag-import ng file at umasa.

Ang nag-iisang karaniwang pagkabigo ay ang banggaan ng subnet. Kusang gagawa ang WireGuard ng tunnel patungo sa network na nagsasapawan sa lokal mo, at pagkatapos ay magpapasya ang routing table kung alin sa dalawang magkaparehong prefix ang mananalo.

Patunayan ito mula sa labas, pagkatapos ay magtabi ng daan pabalik sa loob

Subukan mula sa mobile connection, huwag kailanman mula sa loob ng LAN, dahil mula sa loob sinusubukan mo ang daang walang kinalaman sa tunnel. Itala kung aling port ang ginagamit ng bawat opsyon bago mo ito i-enable, at i-forward ang port na iyon sa box.

Itabi ang nabuong file sa lugar na maaabot mo nang walang tunnel, at samantala itala rin ang panlabas na pangalan ng box.

Ang configuration na hindi pa nasubukan mula sa labas ay plano, hindi gumaganang daan ng remote access. Subukan ang isang host ng LAN sa address at hindi sa pangalan, upang ang pagkabigo ng DNS ay hindi mapagkamalang pagkabigo ng routing.