Bakit nag-timeout pa rin ang isang aprubadong Tailscale subnet route

Ang pag-apruba sa admin console ay mukhang huling hakbang, at hindi ito. Na-timeout muna ang aplikasyon, at pagkatapos mo lang matuklasan na online ang router at aprubado ang ruta. Ang pag-apruba ay hakbang sa pamamahagi, hindi permiso at hindi garantiya ng pagpapasa. Apat na yugto ang dapat magtugma bago maabot ng packet ang host sa likod ng subnet router, at maaaring magtagumpay ang bawat isa habang nabigo ang susunod. Sundin ang mga ito sa pagkakasunod-sunod at huminto sa unang yugtong hindi naninindigan.

Apat na yugto, isang pagkabigo

Inaanunsyo ng router ang prefix, inaprubahan ng tailnet ang anunsyo, tinatanggap ng kliyente ang rutang natanggap, at pinapayagan ng patakaran sa pag-access ang partikular na koneksyon. Apat na magkakahiwalay na desisyon ito mula sa tatlong magkakaibang bahagi. Kaya ang aprubadong ruta ay nagsasabi lamang na ang network ay bahagi na ng routing table ng tailnet.

Ang ikaapat na yugto ang pinakamadalas laktawan, dahil naglalabas ang unang tatlo ng nakikitang estado. Ang pahintulot na sumasaklaw sa sariling tailnet address ng router ay hindi awtomatikong sumasaklaw sa pribadong subnet sa likod nito. Magkaibang destinasyon ang mga ito, at sinusuri ang patakaran bawat destinasyon.

Sa Linux ang ikatlong yugto ay may default ding nakakagulat: opsyonal ang pagtanggap ng mga subnet route. Maraming GUI client ang tumatanggap ng inaanunsyong ruta bilang default, kaya sa halong fleet ay maaaring may isang makinang nabibigo habang gumagana ang iba.

Kumpirmahin ang setting sa makinang nabibigo sa halip na ipagpalagay ang platform. Hindi kailanman naging kulang na piraso ang ruta sa mga makinang gumagana, kaya hayaan silang patunayan na malusog ang panig ng tailnet. Sinasaklaw ng dokumentasyon ng Tailscale tungkol sa mga subnet router ang pag-apruba, pagtanggap ng ruta sa kliyente at yugto ng patakaran.

Suriin ang ruta kung saan tumatakbo ang kliyente

Magsimula sa kliyenteng nabibigo, hindi sa router. Kumpirmahin na may ruta at pinapayagan ng setting ng kliyente ang pagtanggap ng mga ruta.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Ipinapakita ng unang utos ang listahan ng peer at kung maaabot ang subnet router, ipinapakita ng pangalawa ang mga kagustuhan ng kliyente kasama ang flag ng pagtanggap ng ruta, at tinatanong ng pangatlo ang kernel kung aling interface ang gagamitin para sa tunay na host sa subnet. Kung pinangalanan ng huling utos ang pisikal na interface sa halip na interface ng Tailscale, hindi kailanman nakapasok ang ruta sa table. Ang kulang na ruta ay problema sa panig ng kliyente, hindi problema sa pag-apruba. Ayusin ito bago tingnan ang patakaran.

Para tumanggap ng mga ruta sa Linux, muling kumonekta gamit ang flag sa halip na ipagpalagay na nakatakda ito: tailscale up --accept-routes. Ang kliyenteng sumali gamit ang ibang mga flag ay nagpapanatili ng mga ito hanggang mabago, kaya suriin ang kasalukuyang setting bago magdagdag ng isa pa. Ang muling pagpapatakbo ng unang utos pagkatapos ng pagbabago ay dapat magpakita ng ruta sa table.

Patunayan ang pagpapasa at ang pabalik na landas

Hindi kinokonfigura ng pag-apruba ang router na magpasa ng mga packet, at hindi inaayos ang sagot. Pareho itong usapin sa antas ng host sa panig ng LAN ng router. Subukan ang mga ito sa router, hindi sa kliyente.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Dapat mag-ulat ang unang utos ng 1, kung hindi ay itatapon ng kernel ang naipasang packet. Ipinapakita ng pangalawa kung muling isinusulat ng masking ng subnet route ang pinagmulan, na siyang default na pag-uugali at kadalasan ang gusto mo. Ipinapakita ng pangatlo kung naaabot ng kahilingan ang destinasyon at kung may bumabalik; ang kahilingang walang sagot ay problema sa pabalik na landas, hindi sa pag-apruba. Basahin ang tatlong resulta nang sabay bago baguhin ang alinman sa mga ito.

Kung na-disable ang masking, kailangan ng destinasyong network ng rutang pabalik sa mga address ng tailnet, at dapat itong malaman ng bawat hop sa pagitan. Ang muling pag-enable ng masking ang pinakamabilis na pagwawasto para sa isang serbisyo, kapalit ng pagtatago ng orihinal na address ng kliyente sa destinasyon. Mahalaga ang pagpapalit na ito kapag nila-log ng destinasyon ang mga source address para sa audit, kaya sadyang magpasya sa halip na ibaligtad ang flag habang may insidente. Idokumento kung aling pagpipilian ang ginawa mo, dahil isa lamang sa dalawang pag-uugali ang makikita ng susunod na tao.

Basahin ang panuntunan sa pag-access para sa resource

Kapag may ruta at napatunayan ang pagpapasa, ang natitirang pinaghihinalaan ay ang patakaran. Basahin ang pahintulot na dapat magbigay-daan sa koneksyon at suriin ang destinasyon nito, hindi lamang ang pinagmulan. Kailangan ding tumugma ng pagkakakilanlan ng kliyente mismo sa selector ng patakaran, kaya itala ito mula sa parehong makinang nabibigo.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Tinutukoy ng status output ang sariling mga address ng kliyente at ang mga peer na nakikita nito, at dapat tumugma rito ang selector ng pinagmulan ng patakaran. Pinatutunayan ng tailscale ping ang landas ng tailnet hanggang sa subnet router mismo; nireresolba nito ang mga pangalan ng peer at address ng tailnet, hindi ang mga host sa loob ng inaanunsyong subnet. Nagpapadala ang ikatlong utos ng karaniwang ICMP echo sa subnet route, kaya inilalarawan ng resulta ang destinasyon sa halip na ang router. Ang pagtanggi sa antas ng tailnet ay kadalasang bumabalik bilang pagtanggi, habang ang packet na aalis at hindi na bumabalik ay nag-timeout.

Ang nabigong pangalan ay ibang tanong kaysa nabigong address; lutasin ang host nang direkta bago sisihin ang ruta. Isulat ang pahintulot ayon sa tunay na pangangailangan ng resource at hindi sa buong subnet. Ang pagbubukas ng buong /24 para gumana ang isang aplikasyon ay ang paraan ng pagiging malawak na pahintulot ng makitid na kahilingan na wala nang mangangahas na alisin.

Kung ang layunin ay paglabas sa internet at hindi pribadong subnet, ang tamang bahagi ay exit node, hindi subnet router, at nagkakaiba ang patakaran at routing ayon dito. Suriin ang desisyong iyon bago palawakin ang pahintulot. Binabago ng exit node ang default na ruta; ang subnet router ay nagaanunsyo lamang ng prefix.