Kwa nini mwenyeji wa LAN hutuma ARP kwa anwani ya mteja wa OpenVPN

Matatizo ya ufikiaji kati ya mwenyeji wa LAN na mteja wa VPN mara nyingi huanzia kwenye mpango wa anwani wenyewe. Mpe mwenyeji huyo kiolesura kwenye 10.0.100.0/22 na atachukua kila anwani kutoka 10.0.100.0 hadi 10.0.103.255 kama iliyounganishwa moja kwa moja, ikiwa ni pamoja na bwawa la wateja lililowekwa kimya kwenye 10.0.101.0/24. Jibu haliendi kamwe kwa kipanga njia, kwa sababu kwa mtazamo wa mwenyeji hakuna kipanga njia kinachohusika. Kifurushi kimeelekezwa kwa jirani na kinaombwa kwenye waya.

Utaratibu huo uko nyuma ya familia nzima ya ripoti: handaki limewashwa, seva ina njia, na mwenyeji wa LAN bado hawezi kumfikia mteja.

Kiambishi /22 kinachomeza /24

Soma kiambishi kama masafa, sio kama mfuatano wa herufi. Kiambishi /22 kina anwani 1024, na 10.0.100.0/22 inaenea kutoka 10.0.100.0 hadi 10.0.103.255, hivyo bwawa kwenye 10.0.101.0/24 liko ndani kabisa. Hitilafu hii hupita ukaguzi kwa sababu okteti za kwanza za bwawa zinaonekana tofauti na okteti za kwanza za LAN, na okteti ya tatu pekee ndiyo inayofichua umoja huo. Andika masafa yote mawili kwa nambari kabla ya kuyatangaza kuwa tofauti.

Umoja huo huo unaweza kuonekana kinyume chake. Bwawa linaloonekana tupu kwa sababu hakuna anayelitumia kwa sasa bado linaweza kuangukia ndani ya kiambishi kinachotangazwa na kipanga njia fulani cha tovuti, na mpango wa anwani ndio hati pekee inayoonyesha hilo.

Muunganisho wa moja kwa moja humaanisha ARP, sio uelekezaji

Mwenyeji mwenye kiolesura cha /22 anapotuma kwa 10.0.101.25, kiini hulinganisha lengo na kiambishi cha kiolesura na kupata ulinganifu. Kifurushi kinakuwa utafutaji wa jirani badala ya kifurushi kilichoelekezwa, na kwenye Ethernet utafutaji wa jirani ni ombi la ARP kwa anwani hiyo. Ikiwa anwani ni ya mteja wa VPN aliye nyuma ya lango lililoelekezwa, hakuna mwenyeji yeyote kwenye LAN anayeimiliki, kwa hiyo ombi linabaki bila jibu na vifurushi hutupwa. Handaki halina lawama, na mteja haoni trafiki hiyo kamwe.

Ndio maana hitilafu inaonekana isiyo na usawa na mara kwa mara inakatika. Mwenyeji wa VPN mara nyingi huifikia LAN kwa sababu njia zake mwenyewe zinaelekeza upande sahihi, wakati mwenyeji wa LAN hawezi kujibu, na chochote kinachohifadhi kumbukumbu ya ARP ya zamani hufanya dalili kupepesa.

TUN, TAP na kila kimoja hubeba nini

Kifaa cha TUN hubeba vifurushi vya IP, na kifaa cha TAP hubeba fremu za Ethernet. Kiungo cha TUN kilichoelekezwa hakihitaji kubeba ARP ili kutoa ufikiaji wa IP, na ndio sababu ombi lisilo na jibu hapo juu linatarajiwa na sio bovu. TAP yenye daraja la kusudi inaweza kupanua kikoa cha matangazo na kuifanya ARP ifanye kazi, lakini inabadilisha kile mteja anachoweza kuona, inahitaji ncha zinazotumia ufremu sawa, na ni ubunifu upya wa modeli ya mtandao badala ya ukarabati wa kiambishi kinachopishana. Kubadilisha usambazaji ulioelekezwa kwenda TAP ili kuponya hitilafu ya mpango wa anwani hubadilisha tatizo dogo kwa kubwa zaidi.

Rekodi ombi la ARP lilitokea wapi na mfumo upi ulilituma kabla ya kufikia hitimisho. Mtumaji anakueleza anachokiamini kuhusu lengo, sio handaki linafanya nini.

Buni bwawa lisiloweza kupishana

Chagua bwawa nje ya kila kiambishi kilichounganishwa na kila kiambishi cha tovuti kinachotangazwa, kisha ongeza njia zinazoifanya ifikike kwa pande zote mbili. Masafa kama 10.8.0.0/24 katika sehemu isiyotumika ya mpango ni rahisi kufikiria, na LAN inayohitaji kuifikia hupata njia tuli inayoelekeza kwenye seva ya VPN. Badilisha kwa pamoja mgao, njia zinazotangazwa, anwani za chanzo zinazoruhusiwa na kanuni za ngome, kwa sababu zinaeleza muundo mmoja na sio mipangilio minne.

Source NAT kwenye seva inaweza kuficha bwawa nyuma ya anwani inayoelekezwa kutoka LAN, na ni chombo halali cha uhamaji. Pia huandika upya chanzo, hivyo LAN inapoteza uwezo wa kuhusisha miunganisho na wateja binafsi na kutumia kanuni kwa kila mteja.

Kwa ukubalifu, tumia anwani iliyotolewa kwa mteja halisi na ombi halisi la programu kutoka kwa mwenyeji wa LAN, kisha thibitisha kwamba jibu linafuata lango lililopangwa na sio waya.