WireGuard werk op mobiele data, maar nie op dieselfde wifi nie

Die tonnel kom op met mobiele data en bly dan by die huis op verbind staan, met dieselfde profiel, dieselfde eweknie-sleutel en geen konfigurasieverandering tussenin nie. Die verskil lê in die reis: ’n versoek van binne die LAN na die router se openbare adres is nie dieselfde reis as ’n versoek wat van die internet af kom nie. Die meeste huisgateways implementeer nie die terugpad nie, of net vir sekere protokolle. Dit laat die simptoom soos ’n stukkende sleutel lyk terwyl niks aan die sleutel verander het nie. Stel eers vas watter pad gefaal het voordat jy aan ’n sleutel, ’n poortaanstuur of ’n kliëntprofiel raak.

Een adres, twee verskillende paaie

Van buite bereik ’n pakket die router se openbare adres en ’n poortaanstuur-reël gee dit aan die WireGuard-luisteraar op die interne gasheer. Van binne skakel die kliënt dieselfde openbare adres, so die pakket verlaat die kliënt, kom by die router aan en moet weer na die LAN teruggedraai word. Dit is by daardie terugdraai waar die twee paaie uiteengaan, want die router moet ’n stroom vertaal wat dieselfde koppelvlak beide verlaat en weer binnekom. Baie implementasies laat val dit eerder as om dit te vertaal, en die kliënt wag dan op ’n handdruk wat nooit gestuur is nie.

Die gedrag word gewoonlik NAT-loopback of hairpinning genoem, en dit hoort by die router eerder as by WireGuard; RFC 4787 uiteen die vertaalgevalle waarin ’n gateway dit wel of nie mag ondersteun nie. WireGuard self het geen mening oor die pad nie, want dit sien net pakkette wat sy koppelvlak bereik. Wanneer die router die stroom laat val, ontvang die daemon nooit iets nie, die kliënt rapporteer ’n handdruk-tydverstreke, en die bedienerlog bly leeg. ’n Leë log is dus ’n leidraad oor waar die pakket gestop het, nie bewys dat die bediener af is nie. Dit is ook hoekom ’n herinstallasie niks verander nie.

Die omgekeerde saak maak ook saak: ’n bedienerlog wat ’n handdrukpoging vanaf die LAN-adres wys, bewys die pakket het aangekom en die pad is reg, wat die ondersoek na sleutels en toegelate adresse skuif. Lees die log vir wat dit bewys, nie vir wat jy gehoop het om te sien nie.

Reproduseer dit voordat jy iets verander

Toets vanaf ’n gemagtigde eksterne netwerk met dieselfde toestel en dieselfde profiel, en herhaal die toets dan binne die LAN sonder om iets te wysig. ’n Voltooide handdruk buite en ’n kliënt wat binne nooit die toestel verlaat nie, reproduseer die toestand in plaas daarvan om daaroor te raai. Albei pogings moet dieselfde profiel gebruik, anders bewys die vergelyking niks.

Kyk dan waarna die eindpuntnaam vir hierdie toestel oplos. Die volgende drie opdragte wys ook watter adres die kliënt werklik geskakel het:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Die eerste opdrag rapporteer die eindpunt wat die koppelvlak tans gebruik, en die ander twee wys waarna die naam op hierdie masjien oplos. ’n Kliënt wat ’n openbare adres skakel terwyl hy op dieselfde netwerk as die bediener sit, gebruik die hairpin-pad. ’n Kliënt wat die LAN-adres skakel doen dit nie, en ’n fout daar hoort by ’n ander ondersoek. Daardie onderskeid bepaal of die volgende afdeling hoegenaamd van toepassing is.

Ondersteunde maniere om ’n nabygeleë bediener te bereik

Die skoonste reëling is ’n split-horison-antwoord: die openbare naam los vir die internet op die openbare adres op en vir kliënte binne op die bediener se LAN-adres. Die profiel hou een eindpuntnaam en die resolver kies die pad. Dit vereis beheer oor die interne DNS-antwoord, wat ’n huisrouter gewoonlik bied en ’n organisasie doelbewus kan reël. Sonder daardie beheer bly die keuses ’n routerfunksie of ’n tweede profiel.

Die routerfunksie is weerkaatsing: die gateway vertaal die stroom van binne na buite en stuur dit weer binne. Waar dit werk, het dit geen kliëntverandering nodig nie, en waar dit nie werk nie, red geen kliëntinstelling dit nie. Toets dit deur die bedienerlog tydens ’n interne poging dop te hou eerder as om die router se funksielys te lees.

Om die profiel na ’n private adres te wysig is ’n diagnose, nie ’n ontwerp nie. Dit bewys die bediener antwoord op die LAN, en dit breek dieselfde profiel die oomblik wanneer die skootrekenaar die huis verlaat.

Hou die profiel bruikbaar weg van die huis

Watter pad jy ook kies, laat die identiteitskontrole alleen. Die eindpuntadres is nie die eweknie-identiteit nie, en ’n adresverandering regverdig nooit die aanvaarding van ’n onverwante openbare sleutel wat toevallig antwoord nie. WireGuard verifieer deur die sleutel, so ’n verkeerde gasheer faal die handdruk eerder as om toegang tot iets onverwags te gee.

As die openbare adres skuif, hou dinamiese DNS die naam bruikbaar, en die kliënt se verversingsgedrag bepaal hoe vinnig die verandering deurkom. Toets dit van buite ná ’n adresverandering, want die LAN-geval kan dit nie bevestig nie. Let op ’n resolver wat die ou antwoord langer as die rekord se lewensduur cache. ’n Naam wat nog na die vorige adres wys, lyk presies soos ’n bediener wat afgegaan het.

Skryf neer watter naam die profiel gebruik en waarna dit aan elke kant van die grens oplos. ’n Profiel wat van ’n routerfunksie afhang wat niemand opgeteken het nie, is ’n ondersteuningsoproep wat op die volgende firmware-opdatering wag. Die nota sê ook vir die volgende persoon of ’n interne fout die bekende hairpin-geval is of iets nuuts.