Via VPN-adresujo ne estas la DHCP-gamo de la LAN: kial ĝi paneas

La alloga mallongigo estas doni al VPN-klientoj adresojn el la sama gamo, kiun uzas la ofica DHCP-servilo, laŭ la teorio, ke ĉio estas unu reto ĉiuokaze. Ne estas tiel. Enkursigita tunelo portas unicast-pakaĵojn inter du finpunktoj, dum la LAN-adresujo ekzistas por respondi dissendajn petojn sur fizika segmento. Reuzi la numerojn metas du disdonilojn respondecaj pri unu adresspaco kaj lasas la revenan vojon nedifinita.

Du disdoniloj, unu adresspaco

La DHCP-servilo de la LAN scias, kiujn adresojn ĝi luigis kaj al kiu MAC-adreso, kaj defendas ilin per ARP. La VPN-servilo havas sian propran adresujon kaj scias nenion pri tiuj luoj. Neniu el ili eraras; oni simple neniam prezentis ilin unu al la alia.

Adreso el la LAN-adresujo, kiun la VPN-servilo disdonas, eble jam apartenas al printilo. Nun du aparatoj postulas unu adreson en la sama prefikso, kaj la plusendada tabelo de la komutilo decidas, kiu respondos.

Tiu estas la paneo, kiun homoj unue renkontas: kliento, kiu sukcese konektiĝas kaj poste atingas la malĝustan maŝinon, aŭ atingas la ĝustan intermitante.

Kial la enkursigilo ne disdonas VPN-adresojn

DHCP-malkovro estas dissendo, kaj dissendoj haltas ĉe enkursigita limo. Se la dezajno ne pontas la tunelon aŭ ne funkciigas DHCP-relajon kun kongrua rajtigo, la peto de la kliento neniam atingas la LAN-servilon.

Tial la VPN-servilo mem atribuas la adreson: adresujo en la servila agordo, po unu adreso por samtavolano en WireGuard-agordo, aŭ adreso puŝata de la aŭtentiga tavolo en IKEv2-enkonduko. Tiuj mekanismoj estas sendependaj de la luada datumbazo de la LAN, kaj ĝuste tial ili bezonas propran gamon.

La sama rezonado klarigas, kial ŝanĝi la DHCP-agordon ne riparas VPN-klienton, kiu neniam ricevas adreson. La kliento ne demandas la LAN-servilon, kaj neniu kvanto de agorda redaktado igas ĝin demandi.

La interkovro montriĝas kiel konflikto, ne kiel malrapida reto

Du retoj, kiuj dividas prefikson sen subtenata dezajno, estas alia problemo ol duobla posedo, kaj ili ofte konfuziĝas. Se la VPN-adresujo estas aparta prefikso, interkovro gravas nur kiam itinero sendas trafikon al la malĝusta flanko. Se la adresujo kuŝas ene de la LAN-prefikso, la konflikto estas tuja kaj loka.

En la praktiko vi vidas ARP-respondojn de la malĝusta aparato, konektojn, kiuj resetiĝas duonvoje, kaj klienton, kies propran adreson postulas iu alia. Nenio el tio aspektas kiel itinera problemo, kaj tial la ripeto estas aplikata sur la malĝusta tavolo. Duobla luo estas facile konfirmebla kaj ĝene kunvivebla. Ĝi ankaŭ postvivas restartigojn, ĉar ambaŭ disdoniloj daŭre insistas pri la sama adreso.

La reena vojo estas aparta problemo

Eĉ kun pura, aparta adresujo, LAN-gastigantoj devas scii, kiel respondi klienton. Ilia defaŭlta enirejo estas la enkursigilo, kaj la enkursigilo bezonas itineron por la adresujo direktitan al la VPN-servilo, se la dezajno ne tradukas la klientan trafikon anstataŭe.

Legu la vojon en ambaŭ direktoj antaŭ ol ŝanĝi ion. Ĉe la enirejo, demandu kiun interfacon la kerno uzus por klienta adreso; ĉe la kliento, demandu kiun itineron ĝi uzas por LAN-adreso.

Ĉi tiuj komandoj montras la plusendan decidon ĉe la enirejo kaj la najbarajn rikordojn, kiuj malkaŝas duoblaĵon:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Se la unua komando respondas per la tunela interfaco, la reena itinero ekzistas. Se ĝi respondas per la LAN-interfaco, la enkursigilo kredas, ke la kliento estas sur la drato, kaj provos ARP por ĝi.

Pontitaj dezajnoj ekzistas, sed oni devas elekti ilin

Ponti tunelon al la LAN estas reala dezajno, uzata kiam klientoj devas ricevi dissendojn aŭ esti malkovritaj de protokoloj, kiuj supozas unu segmenton. Ĝi postulas, ke la servilo posedu tiun pontan konduton kaj la adresan traktadon, kiu iras kun ĝi.

Kio ne funkcias, estas imiti la rezulton per kopiado de numeroj. Komuna adresujo sen ponto donas al vi la konflikton sen la malkovro, kio estas la plej malbona el ambaŭ aranĝoj.

Elektu tavolon tri kun aparta adresujo, se la aplikaĵo ne vere bezonas la segmenton, kaj dokumentu la adresujon, por ke la sekva administranto ne reuzu la DHCP-gamon pro ordeco.