Ang address ng tunnel na iyon ay isang kapares, hindi subnet na maaari mong i-browse

Kumokonekta ang iyong client at nagpapakita ng pares ng address, o isang address na may 255.255.255.255 mask, at ang unang reaksyon ay nagbigay ang server ng sirang bagay. Wala namang sira: ang tunnel interface ay point-to-point na link, at inilalarawan ng mask ang malayong dulo ng iisang link na iyon, hindi ang hanay ng mga kapitbahay. Ang pagbasa sa pares bilang lokal at kapares ay nagpapaliwanag ng kakaibang mask, ang rutang isang host sa tabi nito at ang nawawalang talahanayan ng kapitbahay. Ang hindi kayang bigyang-katwiran ng parehong pagbasa ay isang plano ng address na nagsasapawan sa network ng opisina.

Bakit mukhang mali ang mask sa isang tunnel link

Sa isang Ethernet interface, ang address at mask ay nagsasabi ng dalawang bagay: pag-aari ng host na ito ang address, at lahat ng nasa loob ng prefix ay direktang kapitbahay. Hinango ng kernel ang ruta sa link mula sa dalawang katotohanang iyon at pagkatapos ay nilulutas ang mga address ng link para sa mga kapitbahay na inaakala nitong naroroon. Pinapanatili ng point-to-point interface ang pagmamay-ari at inaalis ang mga kapitbahay, kaya ang ikalawang address sa linya ng client ay ang malayong dulo at hindi ibang host sa isang pinagsasaluhang segment. Walang hardware addressing, walang trapik ng resolusyon at walang broadcast domain na sasalihan, kaya kumikilos ang interface na parang tubo na may eksaktong isang destinasyon.

Ito rin ang dahilan kung bakit normal dito ang rutang isang host sa tabi ng malawak na mask at hindi sintomas. Ang maabot sa link na ito ay nangangahulugang isang address, at iyon mismo ang isinusulat ng kernel. Basahin ang dalawang address nang magkasama bago magpasyang mali ang configuration, dahil ang bawat isa ay mukhang pagkakamali kapag nag-iisa.

Dalawang topolohiya, dalawang hugis ng address

Ang mas lumang point-to-point na topolohiya ay nagbibigay sa bawat client ng maliit na bloke at gumagamit ng dalawang gitnang address, kaya ang mask ay mukhang piraso ng network at hindi pool. Ang subnet na topolohiya ay nagbibigay ng address mula sa pool kasama ang mask ng pool at tinatawag na kapares ang tunnel address ng server. Pareho silang gumagawa ng balidong link, at nagkakaiba lamang sa kung aling mga address ang lumalabas sa profile at sa mask na malamang pagtatanungan ng user.

Alinmang hilera ang tugma sa iyong client, basahin muna ang kapares, dahil pinapangalanan nito ang malayong dulo at kaya nagpapaliwanag ng mask. Ang profile na kinopya sa pagitan ng mga server na may magkakaibang topolohiya ay magpapakita ng maling hugis para sa bago nitong tahanan, at ang pagkakaibang iyon ay madaling napagkakamalang depekto ng server.

Kapag ang pool at ang network ng opisina ay parehong nangangailangan ng parehong bits

Dahil naka-route ang link, kailangan ng pool ang prefix na wala kahit saan sa mga network na maaabot ng server. Magbahagi ng isa at ang client ay may isang ruta para sa hanay na nangangahulugang dalawang lugar, at ang rutang huling na-install ang nagpapasya kung aling lugar ang mananalo. Lumilitaw ang depekto sa client kahit ang desisyon sa likod nito ay pag-aari ng plano ng address. Ang iniuulat ng mga user ay nawawala ang lokal na router kapag umangat ang tunnel, o kakaunti lang na host ng opisina ang sumasagot.

Ang mga prefix na mukhang magkatulad lamang ay ibang kaso, at ang paghahambing ng mga octet sa mata ay hindi paghahambing ng prefix. Isulat ang dalawa at bilangin ang mga bit na na-mask: 192.168.4.0/24 kumpara sa 192.168.6.0/24 tugma hanggang bit 22 at naghihiwalay sa bit 23, dahil ang ikatlong octet ay binabasa bilang 00000100 kumpara sa 00000110, kaya ang dalawang network na iyon ay tunay na magkahiwalay. Ilagay ang 10.8.0.0/24 sa tabi ng isa pang 10.8.0.0/24 at tugma ang lahat ng 24 na bit na na-mask, ibig sabihin ay hindi maipapahayag ng isang ruta ang dalawang lugar. Ang haba ng mask ang nagpapasya kung saan humihinto ang paghahambing, at ang network na na-install pangalawa ang natatalo.

Ang hindi kayang ihatid ng naka-route na link

Ang broadcast at multicast ay hindi tumatawid sa naka-route na link, at maraming pamilyar na tampok ay nakabatay sa mga ito. Ang mga listahan ng browse, mga anunsyo ng pangalan at pagtuklas ng serbisyo ay pawang nagpapalagay ng pinagsasaluhang segment, kaya ang isang file server ay makakasagot sa bawat kahilingan sa pamamagitan ng address at gayunpaman ay hindi kailanman lalabas sa isang listahan. Ang resolusyon ng pangalan na umaasa sa lokal na broadcast ng link ay nabigo sa parehong dahilan, at walang pag-edit ng profile ang makakabago sa kayang dalhin ng tunnel. Kung mahalaga iyon ay tanong ng mga pangangailangan, hindi ng routing.

Ang client na talagang nangangailangan ng mga paghahatid na iyon ay kailangan ng tulay na interface, na nagdadala ng Ethernet frames at kaya pinapanatili ang broadcast domain. Ang presyo ay mas maingay na link, pagkawala ng malinis na addressing na inilarawan sa itaas, at mas malaking lugar ng depekto kapag lumitaw ang mga loop. Bigyang-katwiran ang pangangailangan bago lumipat, at piliin ang serbisyo ng pangalan na gumagana sa mga naka-route na link kapag ang pangangailangan ay tungkol lamang sa mga pangalan.

Pagbasa sa interface bago i-edit ang profile

Itanong sa kernel kung ano ang in-install nito, hindi kung ano ang parang sinasabi ng profile. Ipinapakita ng output ng address ang kapares na nagpapaliwanag ng mask, at ipinapakita ng output ng ruta kung may daan patungo rito. Ang pagpapatakbo ng dalawa laban sa tunnel device ay tumatagal ng sandali at nilulutas ang tanong.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Kung tugma ang tatlong iyon, ginagawa ng profile ang inilaan para gawin nito, at ang natitirang problema ay nasa ibang lugar. Palitan lang ang topolohiya dahil sa dahilang nagpapangalan ng kulang na kakayahan, dahil ang hindi pamilyar na mask ay hindi ganoon.