Wêrom't in LAN-host foar in OpenVPN-klantadres ARP docht

Berikberensproblemen tusken in LAN-host en in VPN-klant geane faak werom op it adresplan sels. Jou dy host in ynterface op 10.0.100.0/22 en hy behannelt elk adres fan 10.0.100.0 oant 10.0.103.255 as direkt ferbûn, ynklusyf in klantpool dy't stil by 10.0.101.0/24 lein is. It antwurd giet nea nei in router, want fan it eachpunt fan 'e host is der gjin router by belutsen. It pakket is oan in buorman adressearre en wurdt op 'e tried frege.

Dat meganisme sit efter in hiele famylje fan rapporten: de tunnel is omheech, de server hat in rûte, en de LAN-host kin de klant noch altyd net berikke.

It /22 dat it /24 opslokt

Lês it prefiks as in berik, net as in tekenrige. In /22 hâldt 1024 adressen, en 10.0.100.0/22 rint fan 10.0.100.0 oant 10.0.103.255, dus in pool by 10.0.101.0/24 leit der hielendal yn. De flater oerlibbet de resinsje omdat de earste oktetten fan 'e pool der oars útsjen as de earste oktetten fan it LAN, en allinnich it tredde okket de ynslettenheid ferret. Skriuw beide berikken nûmerryk út foardat jo se apart ferklearje.

Deselde ynslettenheid kin ek omkeard foarkomme. In pool dy't frij liket omdat der no gjinien gebrûk fan makket, kin dochs binnen in prefiks falle dat in side-router advertearret, en it adresplan is it iennichste dokumint dat dat sjen lit.

Direkt ferbûn betsjut ARP, gjin routing

As in host mei in /22-ynterface nei 10.0.101.25 stjoert, fergeliket de kernel it bestimming mei it prefiks fan it ynterface en fynt in oerienkomst. It pakket wurdt in buoropsykjen ynstee fan in routed pakket, en op Ethernet is it buoropsykjen in ARP-fersyk foar dat adres. As it adres by in VPN-klant efter in routed gateway heart, besit gjin host op it LAN it, dus bliuwt it fersyk unbeantwurde en wurde de pakketten weilitten. De tunnel is net skuldich, en de klant sjocht it ferkear nea.

Dêrom liket de flater asymmetrysk en soms tuskentiids. De VPN-host kin it LAN faak berikke omdat syn eigen rûtes de goede kant op wiist, wylst de LAN-host net antwurdzje kin, en alles wat in ferâldere ARP-ynfier cachet, lit it symptoom flikkere.

TUN, TAP en wat elk draacht

In TUN-apparaat draacht IP-pakketten, en in TAP-apparaat draacht Ethernet-ramen. In routed TUN-keppeling hoecht gjin ARP te dragen om IP-berikberens te leverjen, en dêrom is it unbeantwurde fersyk hjirboppe te ferwachtsjen en net stikken. TAP mei in bewuste brêge kin it broadcastdomein útwreidzje en ARP wurkje litte, mar it feroaret wat de klant sjen kin, freget einpunten dy't deselde raming stypje, en is in werûntwerp fan it netwurkmodel ynstee fan in reparaasje foar in oerlappende prefiks. In routed ynset nei TAP omsette om in adresplanflater te genêzen, ruilet in lyts probleem foar in grutter.

Notearje wêr't it ARP-fersyk ferskynde en hokker systeem it útstjoerde foardat jo konklúzjes lûke. De ôfstjoerder fertelt jo wat hy oer it bestimming leaut, net wat de tunnel docht.

Ûntwerp in pool dy't net oerlappe kin

Kies in pool bûten elk ferbûn prefiks en elk advertearre sideprefiks, en foegje dan de rûtes ta dy't it yn beide rjochtingen berikber meitsje. In berik lykas 10.8.0.0/24 yn in ûnbrûkt part fan it plan is maklik om oer te riddenearjen, en in LAN dat it berikke moat, krijt in statyske rûte dy't nei de VPN-server wiist. Feroarje de tawizing, de advertearre rûtes, de tastiene boarneadressen en de firewallregels tegearre, want se beskriuwe ien ûntwerp en net fjouwer ynstellings.

Source NAT op 'e server kin de pool efter in LAN-routber adres ferstopje, en it is in legitimit migraasje-ynstrumint. It skriuwt ek de boarne oer, sadat it LAN it fermogen ferliest om ferbiningen oan yndividuele klanten ta te skriuwen en regels per klant ta te passen.

Brûk foar de akseptaasje it echt tawiisde adres fan 'e echte klant en in echt applikaasjefersyk fan in LAN-host, en befêstigje dan dat it antwurd de plande gateway folget ynstee fan 'e tried.