Bakit nagpapadala ng ARP ang isang LAN host para sa address ng OpenVPN client

Ang mga problema sa maabot sa pagitan ng isang LAN host at ng VPN client ay madalas bumabalik sa mismong plano ng address. Bigyan ang host na iyon ng interface sa 10.0.100.0/22 at ituturing nitong direktang konektado ang bawat address mula 10.0.100.0 hanggang 10.0.103.255, kasama ang isang pool ng kliyente na tahimik na inilagay sa 10.0.101.0/24. Hindi kailanman napupunta ang sagot sa isang router, dahil mula sa pananaw ng host ay walang router na kasangkot. Ang packet ay naka-address sa isang kapitbahay at hinihingi sa kabel.

Ang mekanismong iyon ang nasa likod ng isang buong pamilya ng mga ulat: nakabukas ang tunnel, may ruta ang server, at hindi pa rin maabot ng LAN host ang kliyente.

Ang /22 na lumalamon sa /24

Basahin ang prefix bilang isang saklaw, hindi bilang isang string. Ang isang /22 ay may 1024 address, at ang 10.0.100.0/22 ay mula 10.0.100.0 hanggang 10.0.103.255, kaya ang isang pool sa 10.0.101.0/24 ay buong-buong nasa loob nito. Nakaligtas ang pagkakamaling ito sa pagsusuri dahil iba ang hitsura ng mga unang octet ng pool kaysa sa mga unang octet ng LAN, at ang ikatlong octet lamang ang nagbubunyag ng pagkakaloob. Isulat ang parehong saklaw sa mga numero bago mo ideklarang magkahiwalay ang mga ito.

Maaari ring lumitaw ang parehong pagkakaloob sa kabaligtaran. Ang isang pool na mukhang bakante dahil wala pang gumagamit nito ay maaari pa ring mahulog sa loob ng isang prefix na inaanunsyo ng ilang site router, at ang plano ng address ang tanging dokumentong nagpapakita nito.

Ang direktang koneksyon ay ARP, hindi routing

Kapag ang isang host na may /22 interface ay nagpadala sa 10.0.101.25, inihahambing ng kernel ang destinasyon sa prefix ng interface at nakakahanap ng tugma. Ang packet ay nagiging paghahanap ng kapitbahay sa halip na isang rutang packet, at sa Ethernet ang paghahanap ng kapitbahay ay isang ARP request para sa address na iyon. Kung ang address ay pag-aari ng isang VPN client sa likod ng rutang gateway, wala sa alinmang host sa LAN ang may-ari nito, kaya nananatiling walang sagot ang request at itinatapon ang mga packet. Walang kasalanan ang tunnel, at hindi kailanman nakikita ng kliyente ang trapiko.

Kaya naman mukhang asimetriko ang pagkabigo at paminsan-minsan ay pumuputol. Madalas na naaabot ng VPN host ang LAN dahil ang sarili nitong mga ruta ay tumuturo sa tamang direksyon, samantalang hindi makasagot ang LAN host, at anumang nag-cache ng lumang ARP entry ay nagpapakislap sa sintomas.

TUN, TAP at ang dinadala ng bawat isa

Nagdadala ng IP packet ang TUN device, at nagdadala ng Ethernet frame ang TAP device. Ang isang rutang TUN link ay hindi kailangang magdala ng ARP upang makapagbigay ng maabot sa IP, at iyon mismo ang dahilan kung bakit inaasahan ang walang sagot na request sa itaas at hindi ito sira. Ang TAP na may sadyang tulay ay maaaring magpalawak ng broadcast domain at paganahin ang ARP, ngunit binabago nito ang nakikita ng kliyente, nangangailangan ng mga endpoint na sumusuporta sa parehong framing, at isa itong muling disenyo ng modelo ng network kaysa pag-aayos para sa magkapatong na prefix. Ang paglilipat ng rutang deployment sa TAP upang gamutin ang pagkakamali sa plano ng address ay nagpapalit ng maliit na problema sa mas malaki.

Itala kung saan lumitaw ang ARP request at aling sistema ang nagpadala nito bago gumawa ng mga konklusyon. Sinasabi sa iyo ng nagpadala kung ano ang pinaniniwalaan nito tungkol sa destinasyon, hindi kung ano ang ginagawa ng tunnel.

Magdisenyo ng pool na hindi maaaring magpatong

Pumili ng pool sa labas ng bawat konektadong prefix at bawat inaanunsyong site prefix, pagkatapos ay idagdag ang mga rutang nagpapaaabot dito sa parehong direksyon. Ang saklaw na tulad ng 10.8.0.0/24 sa hindi ginagamit na bahagi ng plano ay madaling isipin, at ang LAN na kailangang maabot ito ay nakakakuha ng static na ruta na tumuturo sa VPN server. Sabay na baguhin ang alokasyon, ang mga inaanunsyong ruta, ang mga pinapayagang source address at ang mga panuntunan ng firewall, dahil inilalarawan nila ang isang disenyo at hindi apat na setting.

Maaaring itago ng Source NAT sa server ang pool sa likod ng address na naruruta mula sa LAN, at ito ay isang lehitimong kasangkapan sa paglipat. Muling sinusulat din nito ang source, kaya nawawala sa LAN ang kakayahang iugnay ang mga koneksyon sa indibidwal na kliyente at maglapat ng mga patakaran bawat kliyente.

Para sa pagtanggap, gamitin ang address na aktwal na itinalaga sa tunay na kliyente at isang tunay na kahilingan ng application mula sa LAN host, pagkatapos ay tiyakin na sinusunod ng sagot ang planong gateway at hindi ang kabel.