Pse klienti Tailscale në Linux injoron rrugët e nënrrjetit të shpallura

Jeni në një laptop Linux, tailscale status liston makinat e tjera, dhe NAS-i në 10.80.0.25 ende skadon. Tailnet-i është i shëndetshëm, ruteri i nënrrjetit është online, dhe asgjë në daljen e klientit nuk thotë pse LAN-i pas tij është i paarritshëm. Udhëzimi më poshtë lëviz nga ai simptom nga jashtë: flamuri në këtë klient, pastaj shpallja në ruter, pastaj miratimi, pastaj politika, dhe vetëm pastaj vetë destinacioni. Çdo portë dështon me të njëjtin skadim, prandaj rendi ka më shumë rëndësi se komandat.

Çfarë refuzon të instalojë klienti Linux

Klientët Tailscale në Linux nuk i pranojnë rrugët e nënrrjetit të shpallura nëse nuk i kërkoni. Pa këtë rregullim klienti bashkohet me tailnet-in dhe arrin adresat e kolegëve, ndërsa çdo prefiks që shpall ruteri mbetet i papërdorur. Vlera e parazgjedhur është e qëllimshme, dhe për këtë simptomi duket si ruter i prishur dhe jo si vendim lokal.

Këtu dy gjëra të ndryshme quhen rrugëzim, dhe vetëm njëra është e juaja. Ruteri shpall një prefiks në tailnet; makina juaj vendos nëse do ta instalojë. Një dështim në cilëndo prej tyre jep të njëjtin skadim, prandaj hamendësimi humb një pasdite. Zbuloni cila anë refuzon përpara se të ndryshoni diçka.

Aktivizoni pranimin e rrugëve për këtë makinë

Vendosni preferencën në klient, pastaj shikoni çfarë ndryshoi në vend që të supozoni se komanda funksionoi. Forma aktuale e zbaton rregullimin pa përsëritur rrjedhën e hyrjes, gjë që ka rëndësi kur jeni në mes të një sesioni.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale instalon rrugët e pranuara në tabelën e vet në Linux, prandaj një prefiks që shfaqet në tabelën 52 është provë e drejtpërdrejtë se ky klient instaloi shpalljen. Nëse diapazoni juaj mungon në atë tabelë, ndaloni: problemi është lokal dhe asnjë punë në ruter nuk do ta ndryshojë.

Klientët më të vjetër e ofrojnë të njëjtën preferencë si flamur të komandës së hyrjes, prandaj sudo tailscale up --accept-routes është alternativa kur mungon tailscale set. Përdoreni në vend që t'i modifikoni rrugët me dorë, sepse daemoni rishkruan tabelën e vet dhe modifikimi juaj zhduket në rilidhjen tjetër. Kontrolloni versionin përpara se të kopjoni një komandë nga një shkrim i vjetër.

Kontrolloni shpalljen dhe miratimin veçmas

Në ruterin e nënrrjetit prefiksi duhet të shpallet, dhe kernel-i duhet të përcjellë paketat midis ndërfaqeve. Shpallja pa përcjellje ju jep një rrugë të miratuar që i hedh trafikun në heshtje, dhe ky është rregullimi gjysmë i përfunduar më i zakonshëm.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Krahasoni prefiksin e shpallur me adresën që vërtet po përpiqeni të arrini, karakter për karakter. Një ruter që shpall 10.70.0.0/24 nuk thotë asgjë për një NAS në 10.80.0.25, dhe mospërputhja është e padukshme në çdo dalje statusi sepse të dy numrat duken njësoj të besueshëm. Shumica e raporteve për një rrugë të prishur mbarojnë këtu. Rregulloni shpalljen përpara se të prekni diçka më poshtë.

Miratimi është porta tjetër, dhe është e lehtë ta anashkalosh kur ruteri është konfiguruar nga një shell. Shpallja duhet të aktivizohet për atë pajisje në konsolën e administrimit përpara se makinat e tjera ta përdorin. Pranimi i rrugëve në klient nuk miraton asgjë dhe nuk anashkalon asnjë rregull hyrjeje.

Provoni adresën private përpara emrit të hostit

Një lidhje e suksesshme me adresën tailnet të vetë ruterit provon se tailnet-i funksionon, gjë që e dinit tashmë. Testi i dobishëm është shërbimi që ju nevojitet vërtet, së pari ndaj adresës private, që një dështim DNS të mos mund të shtiret si dështim rrugëzimi.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Nëse adresa përgjigjet dhe emri i hostit jo, keni një problem zgjidhjeje emrash dhe duhet të hiqni dorë nga trajtimi i tij si problem rrugë. Nëse asnjëra nuk përgjigjet, kthehuni një seksion mbrapsht dhe konfirmoni që shpallja mbulon adresën. Dy dështimet duken identike nga aplikacioni dhe rregullohen në vende të ndryshme.

Një kontroll lokal ia vlen përpara se të fajësoni tailnet-in. Kur LAN-i juaj aktual përdor të njëjtin prefiks si nënrrjeti i largët, kernel-i preferon rrugën e lidhur drejtpërdrejt dhe trafiku nuk e lë kurrë makinën; kjo ndodh kur një shtëpi dhe një zyrë zgjedhin të dyja 192.168.1.0/24.

Pse një flamur klienti nuk është rregullim i ruterit

Këto janë role të ndryshme me kërkesa të ndryshme, dhe kopjimi i një flamuri klienti në një ruter është mënyra se si një tailnet funksional fiton një lak. Një makinë që shpall rrugë ka nevojë për përcjellje, rregulla firewall-i që lejojnë trafikun e përcjellë, dhe një vendim për prefikset që shpall. Asnjë prej këtyre nuk nënkuptohet nga --accept-routes.

Dokumentacioni i ruterëve të nënrrjetit paralajmëron kundër aktivizimit të pranimit të rrugëve në ruterë të tepërt që shpallin një prefiks, pasi një nyje gatishmërie mund ta shtyjë trafikun që tashmë është lokal përmes asaj aktive. Nëse drejtoni një çift HA, trajtojeni atë si kufizim projektimi dhe jo si shënim poshtë, dhe vendosni cila nyje zotëron prefiksin përpara se ta miratoni në të dyja. Në një ruter të vetëm i njëjti paralajmërim lexohet si kujtesë që pranimi u takon klientëve, jo makinës që shpall. Shkruani cila portë ishte e mbyllur.

Për një klient të zakonshëm sekuenca mbaron me testin e aplikacionit që dështoi në fillim. Për ruterin, rishikoni përcjelljen, shpalljen, miratimin dhe firewall-in në atë rend, sepse i pari që mungon prodhon pikërisht atë skadim me të cilin filluat.