Waarom 'n LAN-gasheer vir die adres van 'n OpenVPN-kliënt ARP

Bereikbaarheidsprobleme tussen 'n LAN-gasheer en 'n VPN-kliënt lei dikwels terug na die adresplan self. Gee daardie gasheer 'n koppelvlak op 10.0.100.0/22 en hy behandel elke adres van 10.0.100.0 tot 10.0.103.255 as direk verbind, insluitend 'n kliëntpoel wat stilweg by 10.0.101.0/24 geplaas is. Die antwoord gaan nooit na 'n roeteerder nie, want vanuit die gasheer se oogpunt is geen roeteerder betrokke nie. Die pakkie is aan 'n buur geadresseer en word op die draad aangevra.

Daardie meganisme sit agter 'n hele familie verslae: die tonnel is op, die bediener het 'n roete, en die LAN-gasheer kan steeds nie die kliënt bereik nie.

Die /22 wat die /24 insluk

Lees die voorvoegsel as 'n reeks, nie as 'n string nie. 'n /22 hou 1024 adresse, en 10.0.100.0/22 strek van 10.0.100.0 tot 10.0.103.255, so 'n poel by 10.0.101.0/24 lê heeltemal daarbinne. Die fout oorleef die hersiening omdat die poel se eerste oktette anders lyk as die LAN se eerste oktette, en net die derde okteet verklap die insluiting. Skryf albei reekse numeries uit voordat jy hulle afsonderlik verklaar.

Dieselfde insluiting kan omgekeerd voorkom. 'n Poel wat vry lyk omdat niks dit tans gebruik nie, kan steeds binne 'n voorvoegsel val wat een of ander terreinroeteerder adverteer, en die adresplan is die enigste dokument wat dit wys.

Direk verbind beteken ARP, nie roetering nie

Wanneer 'n gasheer met 'n /22-koppelvlak na 10.0.101.25 stuur, vergelyk die kern die bestemming met die koppelvlak se voorvoegsel en vind 'n ooreenstemming. Die pakkie word 'n buuropsporing eerder as 'n geroeteerde een, en op Ethernet is die buuropsporing 'n ARP-versoek vir daardie adres. As die adres aan 'n VPN-kliënt agter 'n geroeteerde poort behoort, besit geen gasheer op die LAN dit nie, so die versoek bly onbeantwoord en die pakkies word laat val. Die tonnel is nie skuldig nie, en die kliënt sien nooit die verkeer nie.

Daarom lyk die fout asimmetries en soms wisselvallig. Die VPN-gasheer kan dikwels die LAN bereik omdat sy eie roetes die regte kant toe wys, terwyl die LAN-gasheer nie kan antwoord nie, en enigiets wat 'n verouderde ARP-inskrywing kas maak die simptoom flikker.

TUN, TAP en wat elkeen dra

'n TUN-toestel dra IP-pakkies, en 'n TAP-toestel dra Ethernet-rame. 'n Geroeteerde TUN-skakel hoef nie ARP te dra om IP-bereikbaarheid te lewer nie, en dit is juis waarom die onbeantwoorde versoek hierbo verwag word en nie 'n fout is nie. TAP met 'n doelbewuste brug kan die uitsaaidomein uitbrei en ARP laat werk, maar dit verander wat die kliënt kan sien, vereis eindpunte wat dieselfde rame ondersteun, en is 'n herontwerp van die netwerkmodel eerder as 'n herstelling vir 'n oorvleuelende voorvoegsel. 'n Geroeteerde ontplooiing na TAP oorskakel om 'n adresplanfout te genees, ruil 'n klein probleem vir 'n groter een.

Teken aan waar die ARP-versoek verskyn het en watter stelsel dit uitgestuur het voordat jy gevolgtrekkings maak. Die sender vertel jou wat hy oor die bestemming glo, nie wat die tonnel doen nie.

Ontwerp 'n poel wat nie kan oorvleuel nie

Kies 'n poel buite elke verbinde voorvoegsel en elke geadverteerde terreinvoorvoegsel, en voeg dan die roetes by wat dit in albei rigtings bereikbaar maak. 'n Reeks soos 10.8.0.0/24 in 'n ongebruikte deel van die plan is maklik om oor te redeneer, en 'n LAN wat dit moet bereik, kry 'n statiese roete wat na die VPN-bediener wys. Verander die toewysing, die geadverteerde roetes, die toegelate bronadresse en die brandmuurreëls saam, want hulle beskryf een ontwerp en nie vier instellings nie.

Source-NAT op die bediener kan die poel agter 'n LAN-roeteerbare adres wegsteek, en dit is 'n wettige migrasie-instrument. Dit herskryf ook die bron, so die LAN verloor die vermoë om verbindings aan individuele kliënte toe te skryf en reëls per kliënt toe te pas.

Gebruik vir aanvaarding die werklike kliënt se toegewysde adres en 'n werklike toepassingsversoek vanaf 'n LAN-gasheer, en bevestig dan dat die antwoord die beplande poort volg eerder as die draad.