169.254 sa pamamagitan ng VPN: hindi kailanman naging rutable ang address
Itinatapon ang isang link-local na destinasyon bago pa ito makarating sa tunnel, kaya ang pagdaragdag ng ruta ay nagpapalawak lamang ng pagkabigo. Pumili sa pagitan ng pag-aayos ng subnet at paggawa ng tulay.
Nagdaragdag ka ng ruta, tumataas ang tunnel, at gayon pa man namamatay ang ping papunta sa kabilang panig nang may ganap na pagkawala sa halip na «network unreachable». Mahalaga ang pagkakaibang iyon, dahil inililihis nito ang tingin mula sa talahanayan ng ruta patungo sa address mismo. Ang destinasyong 169.254 ay link-local, at nagtatapos ang saklaw nito sa unang hop ayon sa disenyo, hindi dahil sa maling pagsasaayos.
Ang desisyong sumusunod ay makitid at sulit gawin nang tahasan: ayusin ang subnet sa panig ng server, o palawakin ang segment ng layer 2 upang muling magkaroon ng lokal na kahulugan ang address. Ang lahat ng iba pa, kabilang ang mas malawak na ruta, ay ginagawa lamang na ang parehong pagkabigo ay umiral para sa mas maraming destinasyon.
Ang address ay hindi walang ruta, hindi ito maruruta
Ang IPv4 link-local na address ay nagbibigay sa sarili kapag walang mas mabuting sumasagot; dito nagmumula ang awtomatikong pribadong pag-address sa Windows at ang katumbas sa ibang sistema. Ginagamit ang saklaw sa bawat link nang sabay, at iyon ang dahilan kung bakit gumagana ito: dalawang host sa parehong segment ay makakapag-usap nang walang anumang koordinasyon.
Dahil sa parehong katangian, hindi dapat ipasa ng router ang mga packet na ito sa pagitan ng mga network. Ang pagtanggap ng packet na nakatuon sa isang link-local na destinasyon at pagpapadala nito sa ibang interface ay lilikha ng kalabuan, dahil ang «lokal» ng nagpadala at ang «lokal» ng tumatanggap ay magkaibang lugar. Walang paghahanap na makakapagpasya kung alin sa dalawa ang ibig sabihin ng nagpadala. Ang pagpasa dito ay hindi opsyon sa patakaran na maaaring buksan ng administrador; ibinubukod ito ng klase ng address.
Kaya ang gateway na naglalagay ng 169.254.1.10 bilang naaabot sa pamamagitan ng tunnel ay humihiling sa kernel ng bagay na ipinagbabawal ng format ng address. Itinatapon ang packet bago pa ito makarating sa malayong host, at walang katumpakan ng ruta ang makapagbabago niyon.
Bakit ginagawang nakikita ng tunnel ang problema sa saklaw
Ang interface ng TUN ay nagdadala ng IP packet sa pagitan ng dalawang kapareha at walang nakabahaging segment sa likod nito. Walang broadcast, walang ARP para sa kabilang panig, at walang pagtuklas ng kapitbahay na makapagpapalit ng link-local na destinasyon sa address ng layer ng link. Kahit na pinayagan pa ang pagpasa, walang paraan ang kliyente upang malaman kung aling kapareha ang dapat sumagot.
Tugma ang mga sintomas kapag alam mo ang hahanapin. Nasa talahanayan ang ruta, nag-uulat ang ping ng ganap na pagkawala sa halip na hindi maabot na network, at nagpapakita ang talahanayan ng kapitbahay ng hindi kumpleto o nabigong entry. Ang pagkuha sa tunnel ay nagpapakita ng packet na lumalabas, na nagtutulak sa mga tao na tumingin sa malayong dulo sa halip na sa klase ng address.
Sa Windows may pangalawang sintomas, na tila walang kaugnayan, na may parehong ugat: ang adapter na natitira lamang ang link-local na address ay walang magamit na gateway, kaya hindi mauri ng pagkilala ng network ang koneksyon at bumabagsak ang profile ng firewall sa public. Hindi ang tunnel ang dahilan; ang address ang dahilan.
Magpasya sa tatlong tanong
Ang pagpili sa pagitan ng pag-aayos ng subnet at pag-tulay sa link ay nakasalalay sa tatlong kondisyon, at alinman sa mga ito ay makakapagpasya bago mo buksan ang file ng pagsasaayos.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
Karamihan sa mga kaso ay humihinto sa unang tanong. Ang host na nagpapakita ng link-local na address ay karaniwang nangangahulugan na hindi sumagot ang DHCP, mali ang cable o VLAN, o may nag-type ng address nang manu-mano. Mas mura ang pag-aayos niyon kaysa sa anumang gawain sa tunnel, at inaalis nito ang problema para sa bawat susunod na kliyente, hindi lamang dito. Iniiwan din nito ang site na may gumaganang DHCP scope, na siyang tunay na ninanais mo.
Suriin ang panig ng server bago magpalagay ng anuman. Patakbuhin ang ip addr show at ip route sa host, at arp -n o route print -4 sa kliyente, upang makita kung tunay na mayroon ang prefix o isang lumang entry lamang ang nagsasabi niyon.
Magkano ang tulay kapag iyon ang tamang sagot
Ang pag-tulay ng pisikal na adapter sa adapter ng TAP ay ginagawang bahagi ng lokal na broadcast domain ang malayong kliyente. Gumagana noon ang broadcast at pagtuklas ng kapitbahay, at muling nagkakaroon ng kahulugan ang link-local na address dahil tunay na lokal ang kliyente sa link na iyon.
Totoo ang mga gastos at dapat sabihin bago may pumayag. Tumatawid ang trapiko ng broadcast sa tunnel, nalalantad ang kliyente sa lokal na segment para sa lahat ng layunin at hindi lamang sa mga serbisyong kailangan nito, at kailangan na ngayon ng server na ipasa ang mga frame sa halip na i-ruta ang mga packet. Makatwirang palitan ito para sa isang bangko ng laboratoryo o aparatong walang rutableng landas ng pagsasaayos, at masamang default para sa malayong pag-access.
Kapag nag-tulay ka, kailangan ang dalawang hati: ang tulay sa server at isang ruta sa profile ng kliyente na nagsasabi kung aling mga destinasyon ang nasa kabilang panig. Ang tulay lamang ay nag-iiwan sa kliyente na manghula, at ang ruta lamang ay hindi makapag-aayos ng klase ng address.