WireGuard funkcias per poŝtelefonaj datumoj sed ne per la sama wifi
Peto el la interno de la LAN al la publika adreso de la enkursigilo sekvas alian vojon ol peto per poŝtelefonaj datumoj. Testu ekstere, poste elektu lokan vojon.
La tunelo ekfunkcias per poŝtelefonaj datumoj kaj poste restas ĉe konektado hejme, kun la sama profilo, la sama najbara ŝlosilo kaj neniom da agorda ŝanĝo intere. La diferenco kuŝas en la vojaĝo: peto el la interno de la LAN al la publika adreso de la enkursigilo ne estas la sama vojaĝo kiel peto alvenanta el la interreto. Plej multaj hejmaj enirejoj aŭ tute ne realigas la revenan vojon aŭ faras tion nur por certaj protokoloj. Tio igas la simptomon aspekti kiel rompita ŝlosilo, kvankam nenio pri la ŝlosilo moviĝis. Determinu, kiu vojo malsukcesis, antaŭ ol tuŝi ŝlosilon, pordan plusendon aŭ klientan profilon.
Unu adreso, du malsamaj vojoj
De ekstere, paketo atingas la publikan adreson de la enkursigilo, kaj porda plusenda regulo transdonas ĝin al la WireGuard-aŭskultanto sur la interna gastiganto. De interne, la kliento kompostas la saman publikan adreson, do la paketo forlasas la klienton, alvenas al la enkursigilo kaj devas esti returnita al la LAN. Ĝuste ĉe tiu returno la du vojoj disiĝas, ĉar la enkursigilo devas traduki fluon, kiu samtempe forlasas kaj reeniras la saman interfacon. Multaj realigoj forĵetas ĝin anstataŭ traduki ĝin, kaj la kliento tiam atendas manpremon, kiu neniam estis sendita.
La konduto kutime nomiĝas NAT-loopback aŭ hairpinning, kaj ĝi apartenas al la enkursigilo prefere ol al WireGuard; RFC 4787 prezentas la tradukajn kazojn, en kiuj enirejo povas aŭ ne povas subteni ĝin. WireGuard mem havas neniun opinion pri la vojo, ĉar ĝi vidas nur paketojn, kiuj atingas ĝian interfacon. Kiam la enkursigilo forĵetas la fluon, la demono neniam ricevas ion, la kliento raportas manpreman tempolimon, kaj la servila protokolo restas malplena. Malplena protokolo estas do indico pri tio, kie la paketo haltis, ne pruvo, ke la servilo estas malsupren. Ĝi ankaŭ estas la kialo, kial reinstallado ŝanĝas nenion.
Ankaŭ la malo gravas: servila protokolo, kiu montras manpreman provon el la LAN-adreso, pruvas, ke la paketo alvenis kaj la vojo estas bona, kio movas la esploron al ŝlosiloj kaj permesitaj adresoj. Legu la protokolon por tio, kion ĝi pruvas, ne por tio, kion vi esperis vidi.
Reproduktu ĝin antaŭ ol ŝanĝi ion
Testu el rajtigita ekstera reto kun la sama aparato kaj la sama profilo, poste ripetu la teston ene de la LAN sen ŝanĝi ion. Kompletigita manpremo ekstere kaj kliento, kiu interne neniam forlasas la aparaton, reproduktas la kondiĉon anstataŭ diveni ĝin. Ambaŭ provoj devas uzi la saman profilon, alie la komparo pruvas nenion.
Poste rigardu, al kio solviĝas la finpunkta nomo por ĉi tiu aparato. La tri sekvaj komandoj ankaŭ montras, kiun adreson la kliento efektive vokis:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netLa unua komando raportas la finpunkton, kiun la interfaco nun uzas, kaj la aliaj du montras, al kio la nomo solviĝas sur ĉi tiu maŝino. Kliento, kiu vokas publikan adreson dum ĝi sidas sur la sama reto kiel la servilo, uzas la hairpin-vojon. Kliento, kiu vokas la LAN-adreson, tion ne faras, kaj misfunkcio tie apartenas al alia esploro. Tiu distingo decidas, ĉu la sekva sekcio entute aplikiĝas.
Subtenataj manieroj atingi proksiman servilon
La plej pura aranĝo estas split-horizon-respondo: la publika nomo solviĝas al la publika adreso por la interreto kaj al la LAN-adreso de la servilo por klientoj ene. La profilo tenas unu finpunktan nomon, kaj la solvilo elektas la vojon. Tio postulas kontrolon de la interna DNS-respondo, kiun hejma enkursigilo kutime ofertas kaj organizaĵo povas intence aranĝi. Sen tiu kontrolo restas la elektoj: enkursigila funkcio aŭ dua profilo.
La enkursigila funkcio estas reflektado: la enirejo tradukas la fluon de interne al ekstere kaj resendas ĝin internen. Kie ĝi funkcias, ĝi bezonas neniun klientan ŝanĝon, kaj kie ĝi ne funkcias, nenia klienta agordo savas ĝin. Testu ĝin observante la servilan protokolon dum interna provo anstataŭ legi la funkcian liston de la enkursigilo.
Redakti la profilon al privata adreso estas diagnozo, ne dezajno. Ĝi pruvas, ke la servilo respondas en la LAN, kaj ĝi rompas la saman profilon en la momento, kiam la tekkomputilo forlasas la domon.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Tenu la profilon uzebla for de hejmo
Kiun ajn vojon vi elektas, lasu la identecan kontrolon trankvila. La finpunkta adreso ne estas la najbara identeco, kaj adresa ŝanĝo neniam pravigas akcepti fremdan publikan ŝlosilon, kiu hazarde respondas. WireGuard aŭtentikigas per ŝlosilo, do malĝusta gastiganto malsukcesas la manpremon anstataŭ doni aliron al io neatendita.
Se la publika adreso moviĝas, dinamia DNS estas tio, kio tenas la nomon utila, kaj la refreŝiga konduto de la kliento decidas, kiom rapide la ŝanĝo alvenas. Testu tion de ekstere post adresa ŝanĝo, ĉar la LAN-kazo ne povas validigi ĝin. Atentu solvilon, kiu kaŝmemorigas la malnovan respondon preter la vivodaŭro de la rikordo. Nomo, kiu ankoraŭ montras al la antaŭa adreso, aspektas ĝuste kiel servilo, kiu falis.
Notu, kiun nomon la profilo uzas kaj al kio ĝi solviĝas ĉe ĉiu flanko de la limo. Profilo, kiu dependas de enkursigila funkcio, kiun neniu notis, estas subtena voko atendanta la sekvan firmvaran ĝisdatigon. La noto ankaŭ estas tio, kio diras al la sekva persono, ĉu interna misfunkcio estas la konata hairpin-kazo aŭ io nova.