Mteja wa VPN aliye na anwani ya LAN hayupo kwenye LAN

Mteja anaunganisha, anapokea 10.50.0.200 na hawezi kufikia seva iliyo 10.50.0.20 ingawa namba zote mbili ziko kwenye /24 moja. Imani iliyo nyuma ya usanidi huo ni kwamba anwani kutoka kiambishi cha LAN humfanya mteja kuwa sehemu ya LAN. Haifanyi hivyo. Mteja yuko kwenye kiungo cha nukta-hadi-nukta, seva inachukulia lengo kuwa la ndani, na sehemu inayokosekana ni jibu la jirani ambalo hakuna anayetuma.

Hadithi: kiambishi kimoja kinamaanisha sehemu moja

Kiambishi cha anwani humweleza mwenyeji ni malengo gani anayafikia moja kwa moja na yapi yanahitaji kipanga njia. Hakimwelezi mwenyeji jinsi lengo lilivyounganishwa kimwili, na hakika hakihakikishi kwamba lengo linaweza kujibu ombi la safu ya kiungo. Haya ni maswali tofauti, yanayojibiwa na majedwali tofauti kwenye mwenyeji. Maski hujibu la kwanza na jedwali la majirani hujibu la pili, na ni la kwanza tu lililo chini ya udhibiti wako kutoka upande wa VPN.

Seva inapotuma kwa 10.50.0.200, hulinganisha lengo na maski yake, huamua kwamba anwani ni on-link, na huuliza sehemu ya ndani anwani ya maunzi inayomilikiwa nayo. Ombi hilo hutoka kwenye kiolesura cha Ethernet, na mteja wa VPN hayupo hapo kuliskia.

Hakuna kitu kwenye usanidi wa mteja kinachoweza kurekebisha hili kutoka upande wake. Njia ya jibu inategemea kifaa kilicho kwenye LAN kujibu kwa niaba ya mteja, au mteja kuwa na anwani ambayo seva haichukulii kuwa ya ndani.

Mwenyeji wa ndani hufanya nini kwa kweli na anwani hiyo

Tabia ni rahisi kuona na inafaa kuonekana kabla ya kubadilisha chochote. Angalia jedwali la majirani kwenye mwenyeji wa LAN baada ya kujaribu kufikia mteja: ingizo lisilokamilika au lililoshindwa ni utambuzi wote katika mstari mmoja. Mstari huo pia unakuambia kwamba hitilafu ni ya ndani kwa sehemu na si mahali fulani ndani ya handaki.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Utafutaji wa njia utaripoti lengo kama on-link kupitia kiolesura cha Ethernet, na hilo ndilo tatizo. Ikiwa ingizo la jirani linabaki lisilokamilika wakati kikao cha VPN kikiwa hai, umethibitisha kwamba sehemu inayokosekana ni utatuzi wa safu ya kiungo na si uelekezaji au sera ya ngome.

Fanya ukaguzi huo huo kutoka kwa mwenyeji katika subnet nyingine na linganisha. Mwenyeji anayefikia mteja kupitia kipanga njia hahitaji ingizo la jirani kabisa, na tofauti hiyo ni uamuzi wa usanifu kwa kiwango kidogo.

Jinsi proxy ARP inavyotoa hatua inayofuata

proxy ARP hufanya lango lijibu ombi la safu ya kiungo kwa niaba ya lengo ambalo linaweza kulifikia kupitia kiolesura kingine. Mwenyeji wa LAN hupokea anwani ya maunzi, hutuma fremu kwa lango, na lango hupeleka pakiti kwenye kikao cha VPN. Kwa mtazamo wa mwenyeji mteja anaonekana kuwa nyuma ya lango. Hakuna kitu kwenye usanidi wa mteja kinachobadilika.

Nyaraka za RouterOS ARP za MikroTik zinaelezea matumizi hayo kwa wateja wa dial-in wanaokopa nafasi ya anwani ya LAN iliyounganishwa. Utaratibu ni ukarabati wa utatuzi wa majirani, na hufanya kazi kwa sababu lango liko kwenye njia zote mbili kwa kweli.

Hii si sawa na kuweka daraja la mteja ndani ya LAN. Lango bado linapaswa kupeleka pakiti kwenye kikao sahihi kinachotumika, na uelekezaji wake na sera ya ngome bado zinapaswa kuruhusu huduma. proxy ARP hubadilisha nani anajibu ombi la jirani, si nani anaruhusiwa kuzungumza.

Soma majina ya hali ya jukwaa kwa makini. RouterOS hutenganisha proxy-arp na local-proxy-arp, na ya pili hushughulikia trafiki inayoingia na kutoka kupitia kiolesura kimoja. Hizi si tahajia zinazoweza kubadilishana, na kuwasha zote mbili bila tofauti si njia ya mkato.

Kile proxy ARP haikupi

Haikupi ugunduzi wa broadcast au multicast. Mteja anayehitaji kupata huduma kwa broadcast bado atashindwa, kwa sababu lango hupeleka unicast kwenye kikao na hailimfanyi mteja kuwa mwanachama wa kikoa cha broadcast cha LAN. Itifaki za ugunduzi zinazotegemea broadcast ni chanzo cha kawaida cha ripoti kwamba inafanya kazi kwa kitu kimoja na si kingine katika miundo ya anwani zilizokopwa.

Haiahifadhi anwani. Ikiwa namba iliyokopwa pia iko kwenye dimbwi la DHCP au ugawaji tuli, vifaa viwili vinaweza kuishia na anwani moja na tabia inayotokana inategemea muda. Kuingia kwa mafanikio si uhifadhi.

Na haiondoi hitaji la kuratibu na mmiliki wa LAN. Ingizo la proxy ARP linalomshangaza mmiliki wa mpango wa anwani ni tukio la msaada linalosubiri wiki tulivu.

Kulinganisha na dimbwi lililoelekezwa kwa tofauti

Njia mbadala ni kuwapa wateja wa VPN kiambishi chao wenyewe na kuwaacha wenyeji wa LAN waelekee huko. Wakati huo seva hutuma majibu ya off-link kwa lango lake, lango huelekeza kiambishi hadi mwisho wa VPN, na kwenye sehemu ya LAN hakuna haja ya utatuzi wa majirani kabisa. Hizi ni sehemu chache zinazohama kuliko anwani iliyokopwa pamoja na jibu la proxy.

Muundo huo ni rahisi kufikiria na rahisi kukagua, kwa sababu masafa ya wateja yametenganishwa kwa wazi na masafa ya LAN. Unagharimu njia moja, njia ya kurudi na kanuni ya ufikiaji, vitu vile vile ambavyo muundo wa proxy ARP unahitaji mahali pasipo dhahiri.

Chagua kati ya miundo kwa makusudi na si kwa bahati. proxy ARP hurekebisha uhusiano mmoja maalum; dimbwi lililoelekezwa huepusha hitaji la ukarabati huo. Andika ulichochagua na kwa nini, na mtu anayefuata hatalazimika kuugundua upya kutoka kwa ingizo la jirani lililoshindwa.