FRITZ!Box VPN konektiĝas sed nenio respondas: WireGuard aŭ IPSec
Konektita FRITZ!Box-tunelo, kiu ne atingas la LAN-on, estas adresada problemo. Kontrolu la kvar IPSec-kampojn aŭ la WireGuard-peer antaŭ reimporto.
La tunelo raportas konekton, la ikono estas verda, kaj nenio en la hejma LAN respondas. Tio estas la plej ofta plendo pri la fora aliro de FRITZ!Box, kaj preskaŭ neniam temas pri la tunelo mem. La adresa plano, la identeco de la subreto aŭ la enkursiga tabelo de la kliento malĝustas. Kiun el tiuj vi fine sencimigos, dependas de tio, ĉu vi elektis WireGuard aŭ la pli malnovan IPSec Fernzugang, do komencu sciante, kiun vi efektive agordis.
La tunelo ekfunkcias kaj la LAN restas silenta
Tunelo, kiu establiĝas, pruvas, ke la ŝlosiloj kaj la finpunkto estas ĝustaj. Ĝi ne pruvas, ke la kliento ricevis adreson, al kiu la skatolo povas enkursigi, nek ke la kliento scias, kiuj prefiksoj apartenas al la tunelo. Tio estas du apartaj sukcesoj, kaj nur la dua ebligas al vi atingi printilon.
Kontrolu unue la adreson de la kliento, poste ĝian enkursigan tabelon.
Se la atribuita adreso kuŝas ekster la LAN-subreto, la skatolo havas nenion, al kio enkursigi reen. Se ĝi kuŝas ene de la DHCP-gamo, la skatolo povas doni la saman adreson al loka aparato. Ambaŭ kreas tunelon, kiu konektiĝas, kaj LAN-on, kiu ignoras vin.
Kion ĉiu opcio efektive agordas
La opcio IPSec generas agordan dosieron por unu uzanto, enhavantan la antaŭe kunhavatan ŝlosilon kaj la adresadon. Vi importas ĝin en klienton, kiu parolas la saman profilon, kio en Windows kutime signifas la ilon de la fabrikanto kaj ne la enkonstruitan klienton. La opcio WireGuard generas peer por unu aparato: ŝlosilparo, adreso interne de la tunelo kaj finpunkto.
Tiu diferenco decidas vian prizorgan modelon. Ĉiu WireGuard-aparato estas aparta peer kun propra ŝlosilo, do nuligi perditan telefonon signifas forigi unu peer, dum la aliaj daŭre funkcias. IPSec nuligas per ŝanĝo de la kunhavata sekreto aŭ de la agordo de la uzanto, kio estas pli maldelikata kaj tuŝas ĉiun aparaton, kiu ĝin uzas.
Neniu el la du opcioj estas eksdata. La IPSec-vojo restas la subtenata tie, kie la fora flanko ne povas ruli WireGuard.
La IPSec-kampoj, kiuj kreas mortan tunelon
Kvar valoroj devas kongrui kun via LAN, kaj tri el ili malsukcesas tiel, ke ĝi aspektas kiel rompita tunelo.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
La retadreso estas tiu, kiu kaptas homojn. Subreto identiĝas per sia unua adreso, kiu kutime finiĝas per nulo, kaj enigi gastigan adreson tie kreas agordon, kiu aspektas tute kredinda kaj neniam konektiĝas. La DHCP-gamo gravas pro alia kialo: tunelaj klientoj kutime atribuiĝas super ĝi, do gamo, kiu konsumas la tutan subreton, lasas nenion por disdoni.
Interkovrantaj subretoj estas la alia klasika kazo. Se la fora LAN, al kiu vi aliĝas, uzas la saman prefikson kiel la LAN, sur kiu vi sidas, enkursigado ne povas distingi ilin, kaj renumerigado de unu flanko estas la sola vera ripeto. Neniu kvanto da klienta agordo solvas tion.
Kial WireGuard malsukcesas alimaniere
WireGuard havas neniun antaŭe kunhavatan ŝlosilon por mistajpi, do ĝiaj malsukcesoj grupiĝas ĉirkaŭ la difino de la peer anstataŭe. Listo de permesitaj IP-oj, kiu preterlasas la LAN-prefikson, kreas tunelon, kiu portas nenion, ĉar la kliento neniam sendas en ĝin trafikon celantan la LAN-on. Eksdata publika ŝlosilo ĉe iu ajn flanko kreas manpremon, kiu neniam kompletiĝas. Mankanta finpunkto aŭ malĝusta pordo kreas silenton anstataŭ eraron.
Komparu ambaŭ flankojn kampo post kampo anstataŭ reimporti la dosieron kaj esperi.
La sola komuna fiasko estas la subreta kolizio. WireGuard volonte konstruos tunelon al reto, kiu interkovras vian lokan, kaj tiam la enkursiga tabelo decidas, kiu el la du identaj prefiksoj venkos.
Pruvu ĝin de ekstere, poste konservu vojon reen
Testu el poŝtelefona konekto, neniam el interne de la LAN, ĉar el interne vi testas vojon, kiu tute ne implikas la tunelon. Notu, kiun pordon ĉiu opcio uzas antaŭ ol ŝalti ĝin, kaj plusendu tiun pordon al la skatolo.
Konservu la generitan dosieron ie, kien vi povas atingi sen la tunelo, kaj samtempe notu la eksteran nomon de la skatolo.
Agordo, kiu neniam estis testita de ekstere, estas plano, ne funkcianta fora alira vojo. Testu unu LAN-gastigan per adreso, ne per nomo, por ke DNS-fiasko ne estu konfuzata kun enkursiga fiasko.