Pse një rrugë nënrrjeti e Tailscale e miratuar ende skadon

Miratimi në konsolën e administrimit duket si hapi i fundit, dhe nuk është. Së pari aplikacioni skadon, dhe vetëm pas kësaj zbuloni se routeri është në linjë dhe rruga është miratuar. Miratimi është një hap shpërndarjeje, jo një leje dhe jo një garanci përcjelljeje. Katër faza duhet të përputhen përpara se një paketë të arrijë një host pas një routeri nënrrjeti, dhe secila mund të ketë sukses ndërsa e tjetra dështon. Kalojini sipas radhës dhe ndaloni në fazën e parë që nuk mbahet.

Katër faza, një dështim

Routeri shpall prefiksin, tailnet-i miraton atë shpallje, klienti pranon rrugën që mori, dhe politika e aksesit lejon lidhjen konkrete. Këto janë katër vendime të ndara marrë nga tre komponentë të ndryshëm. Prandaj një rrugë e miratuar thotë vetëm se rrjeti tani është pjesë e tabelës së rrugëzimit të tailnet-it.

Faza e katërt hidhet më shpesh, sepse tre të parat prodhojnë një gjendje të dukshme. Një leje që mbulon adresën e vetë routerit në tailnet nuk mbulon automatikisht një nënrrjet privat pas tij. Këto janë destinacione të ndryshme, dhe politika vlerësohet për secilin destinacion.

Në Linux faza e tretë ka gjithashtu një vlerë të parazgjedhur që i habit njerëzit: pranimi i rrugëve të nënrrjetit është opsional. Disa klientë me ndërfaqe grafike pranojnë si parazgjedhje rrugët e shpallura, kështu që një flotë e përzier mund të tregojë një makinë që dështon ndërsa të tjerat funksionojnë.

Konfirmoni cilësimin në makinën që dështon në vend që të supozoni një platformë. Rruga nuk ishte kurrë pjesa që mungonte në makinat që funksionojnë, prandaj lërini ato të provojnë se ana e tailnet-it është e shëndoshë. Dokumentacioni i Tailscale për routerët e nënrrjetit mbulon miratimin, pranimin e rrugëve nga klienti dhe fazën e politikës.

Kontrolloni rrugën atje ku ekzekutohet klienti

Filloni nga klienti që dështon, jo nga routeri. Konfirmoni që rruga ekziston dhe që cilësimi i klientit lejon pranimin e rrugëve.

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

Komanda e parë tregon listën e partnerëve dhe nëse routeri i nënrrjetit është i arrirshëm, e dyta shtyp preferencat e klientit duke përfshirë flamurin e pranimit të rrugëve, dhe e treta pyet kernelin se cilën ndërfaqe do të përdorte për një host real në nënrrjet. Nëse ajo komanda e fundit përmend ndërfaqen fizike në vend të ndërfaqes së Tailscale, rruga nuk hyri kurrë në tabelë. Një rrugë që mungon është problem i anës së klientit, jo i miratimit. Rregullojeni përpara se të shikoni politikën.

Për të pranuar rrugë në Linux, rilidhuni me flamurin në vend që të supozoni se është vendosur: tailscale up --accept-routes. Një klient që u bashkua me flamuj të tjerë i mban ata derisa të ndryshohen, prandaj kontrolloni cilësimin aktual përpara se të shtoni një tjetër. Ekzekutimi përsëri i komandës së parë pas ndryshimit duhet të tregojë rrugën në tabelë.

Provoni përcjelljen dhe rrugën e kthimit

Miratimi nuk e konfiguron routerin të përcjellë paketa dhe nuk e rregullon përgjigjen. Të dyja janë çështje në nivel hosti në anën LAN të routerit. Provoni ato në router, jo në klient.

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

Komanda e parë duhet të raportojë 1, përndryshe kerneli do të hedhë paketën e përcjellë. E dyta tregon nëse maskimi i rrugës së nënrrjetit rishkruan burimin, që është sjellja e parazgjedhur dhe zakonisht ajo që dëshironi. E treta tregon nëse kërkesa arrin destinacionin dhe nëse kthehet diçka; një kërkesë pa përgjigje është problem i rrugës së kthimit, jo i miratimit. Lexoni tre rezultatet së bashku përpara se të ndryshoni ndonjë prej tyre.

Nëse maskimi është çaktivizuar, rrjeti i destinacionit ka nevojë për një rrugë kthimi drejt adresave të tailnet-it, dhe çdo hop në mes duhet ta dijë atë. Rindezja e maskimit është rregullimi më i shpejtë për një shërbim të vetëm, me koston e fshehjes së adresës origjinale të klientit nga destinacioni. Ky shkëmbim ka rëndësi kur destinacioni regjistron adresat e burimit për auditim, prandaj vendoseni me qëllim në vend që ta ktheni flamurin gjatë një incidenti. Dokumentoni cilën zgjedhje bëtë, sepse personi tjetër do të shohë vetëm një nga dy sjelljet.

Lexoni rregullin e aksesit për burimin

Kur rruga është e pranishme dhe përcjellja është provuar, i dyshuari i mbetur është politika. Lexoni lejen që duhet të lejojë lidhjen dhe kontrolloni destinacionin e saj, jo vetëm burimin. Edhe identiteti i vetë klientit duhet të përputhet me përzgjedhësin e politikës, prandaj regjistrojeni nga e njëjta makinë që dështon.

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

Dalja e statusit identifikon adresat e vetë klientit dhe partnerët që ai sheh, dhe me këto duhet të përputhet përzgjedhësi i burimit të politikës. tailscale ping provon rrugën e tailnet-it deri në vetë routerin e nënrrjetit; ai zgjidh emrat e partnerëve dhe adresat e tailnet-it, jo hostet brenda një nënrrjeti të shpallur. Komanda e tretë dërgon një jehonë ICMP normale përmes rrugës së nënrrjetit, prandaj rezultati i saj përshkruan destinacionin dhe jo routerin. Refuzimi në nivel tailnet-i zakonisht kthehet si refuzim, ndërsa një paketë që del dhe nuk kthehet kurrë skadon.

Një emër që dështon është një pyetje tjetër nga një adresë që dështon; zgjidhni hostin drejtpërdrejt përpara se të fajësoni rrugën. Shkruani lejen sipas nevojës reale të burimit dhe jo sipas të gjithë nënrrjetit. Hapja e një /24 të tërë që një aplikacion të funksionojë është mënyra se si një kërkesë e ngushtë bëhet një leje e gjerë që më pas askush nuk guxon ta heqë.

Nëse qëllimi ishte dalja në internet dhe jo një nënrrjet privat, komponenti i saktë është një nyje daljeje, jo një router nënrrjeti, dhe politika e rrugëzimi ndryshojnë në përputhje me këtë. Kontrolloni atë vendim përpara se të zgjeroni një leje. Një nyje daljeje ndryshon rrugën e parazgjedhur; një router nënrrjeti shpall vetëm një prefiks.