Kial LAN-gastiganto sendas ARP por la adreso de OpenVPN-kliento

Atingebloproblemoj inter LAN-gastiganto kaj VPN-kliento ofte fontas el la adresplano mem. Donu al tiu gastiganto interfacon sur 10.0.100.0/22 kaj ĝi traktos ĉiun adreson de 10.0.100.0 ĝis 10.0.103.255 kiel rekte konektitan, inkluzive de klientaro diskrete lokita en 10.0.101.0/24. La respondo neniam iras al enkursigilo, ĉar laŭ la vidpunkto de la gastiganto neniu enkursigilo partoprenas. La pakaĵo estas adresita al najbaro kaj petata sur la kablo.

Tiu mekanismo staras malantaŭ tuta familio da raportoj: la tunelo estas aktiva, la servilo havas itineron, kaj la LAN-gastiganto ankoraŭ ne povas atingi la klienton.

La /22, kiu englutas la /24

Legu la prefikson kiel intervalon, ne kiel signoĉenon. /22 entenas 1024 adresojn, kaj 10.0.100.0/22 etendiĝas de 10.0.100.0 ĝis 10.0.103.255, do klientaro en 10.0.101.0/24 kuŝas tute interne. La eraro postvivas la revizion ĉar la unuaj oktoj de la klientaro aspektas malsame ol la unuaj oktoj de la LAN, kaj nur la tria okto malkaŝas la entenon. Skribu ambaŭ intervalojn cifere antaŭ ol deklari ilin apartaj.

La sama enteno povas aperi inverse. Klientaro, kiu ŝajnas libera ĉar nenio uzas ĝin nun, tamen povas fali en prefikson anoncatan de iu ejenkursigilo, kaj la adresplano estas la sola dokumento, kiu montras tion.

Rekta konekto signifas ARP, ne enkursigon

Kiam gastiganto kun /22-interfaco sendas al 10.0.101.25, la kerno komparas la celon kun la prefikso de la interfaco kaj trovas kongruon. La pakaĵo fariĝas najbarserĉo anstataŭ enkursigita pakaĵo, kaj sur Ethernet la najbarserĉo estas ARP-peto por tiu adreso. Se la adreso apartenas al VPN-kliento malantaŭ enkursigita kluzo, neniu gastiganto en la LAN posedas ĝin, do la peto restas senresponda kaj la pakaĵoj estas forĵetitaj. La tunelo ne kulpas, kaj la kliento neniam vidas la trafikon.

Tial la fiasko aspektas malsimetria kaj foje intermita. La VPN-gastiganto ofte povas atingi la LAN-on ĉar ĝiaj propraj itineroj montras la ĝustan direkton, dum la LAN-gastiganto ne povas respondi, kaj io ajn kaŝmemoranta malnovan ARP-eron igas la simptomon trembrili.

TUN, TAP kaj kion ĉiu portas

TUN-aparato portas IP-pakaĵojn, kaj TAP-aparato portas Ethernet-kadrojn. Enkursigita TUN-ligilo ne bezonas porti ARP por liveri IP-atingeblecon, kaj ĝuste tial la senresponda peto supre estas atendata kaj ne difekta. TAP kun intenca ponto povas etendi la dissendan domajnon kaj igi ARP funkcii, sed ĝi ŝanĝas tion, kion la kliento povas vidi, postulas finpunktojn subtenantajn la saman kadrigon kaj estas reprojektado de la retmodelo anstataŭ riparo por interkovra prefikso. Ŝanĝi enkursigitan instalon al TAP por kuraci adresplaneraron interŝanĝas malgrandan problemon kontraŭ pli granda.

Notu, kie la ARP-peto aperis kaj kiu sistemo elsendis ĝin, antaŭ ol tiri konkludojn. La sendanto diras al vi, kion ĝi kredas pri la celo, ne kion faras la tunelo.

Projektu klientaron, kiu ne povas interkovriĝi

Elektu klientaron ekster ĉiu konektita prefikso kaj ĉiu anoncita eja prefikso, poste aldonu la itinerojn, kiuj igas ĝin atingebla en ambaŭ direktoj. Intervalo kiel 10.8.0.0/24 en neuzata parto de la plano estas facile rezonebla, kaj LAN, kiu devas atingi ĝin, ricevas statikan itineron montrantan al la VPN-servilo. Ŝanĝu kune la atribuon, la anoncitajn itinerojn, la permesitajn fontadresojn kaj la fajroŝirmilajn regulojn, ĉar ili priskribas unu dezajnon kaj ne kvar agordojn.

Fonta NAT sur la servilo povas kaŝi la klientaron malantaŭ LAN-enkursigebla adreso, kaj ĝi estas legitima migrilo. Ĝi ankaŭ reskribas la fonton, do la LAN perdas la kapablon atribui konektojn al unuopaj klientoj kaj apliki regulojn por kliento.

Por akcepto uzu la efektive atribuitan adreson de la reala kliento kaj realan aplikaĵpeton de LAN-gastiganto, poste konfirmu, ke la respondo sekvas la planitan kluzon kaj ne la kablon.