Kāpēc apstiprināts Tailscale apakštīkla maršruts joprojām beidzas ar taimautu

Apstiprinājums administrācijas konsolē izskatās kā pēdējais solis, un tas tā nav. Vispirms lietojumprogramma beidzas ar taimautu, un tikai pēc tam jūs atklājat, ka maršrutētājs ir tiešsaistē un maršruts ir apstiprināts. Apstiprināšana ir izplatīšanas solis, nevis atļauja un nevis pārsūtīšanas garantija. Četriem posmiem jāsakrīt, pirms pakete sasniedz resursdatoru aiz apakštīkla maršrutētāja, un katrs no tiem var izdoties, kamēr nākamais neizdodas. Izpildiet tos secīgi un apstājieties pie pirmā posma, kas neiztur.

Četri posmi, viena kļūda

Maršrutētājs izziņo prefiksu, tailnet apstiprina šo izziņojumu, klients pieņem saņemto maršrutu, un piekļuves politika atļauj konkrēto savienojumu. Tie ir četri atsevišķi lēmumi, ko pieņem trīs dažādas sastāvdaļas. Tāpēc apstiprināts maršruts tikai norāda, ka tīkls tagad ir daļa no tailnet maršrutēšanas tabulas.

Ceturtais posms tiek izlaists visbiežāk, jo pirmie trīs rada redzamu stāvokli. Atļauja, kas aptver paša maršrutētāja tailnet adresi, automātiski neaptver privātu apakštīklu aiz tā. Tie ir dažādi galamērķi, un politika tiek novērtēta katram galamērķim atsevišķi.

Linux vidē trešajam posmam ir arī noklusējuma vērtība, kas pārsteidz: apakštīkla maršrutu pieņemšana ir neobligāta. Vairāki GUI klienti pēc noklusējuma pieņem izziņotos maršrutus, tāpēc jauktā parkā viena mašīna var izskatīties bojāta, kamēr pārējās darbojas.

Pārbaudiet iestatījumu bojātajā mašīnā, nevis pieņemiet platformu. Maršruts nekad nav bijis trūkstošā daļa mašīnās, kas darbojas, tāpēc ļaujiet tām pierādīt, ka tailnet puse ir vesela. Tailscale apakštīkla maršrutētāju dokumentācija aptver apstiprināšanu, klienta maršrutu pieņemšanu un politikas posmu.

Pārbaudiet maršrutu tur, kur darbojas klients

Sāciet ar bojāto klientu, nevis ar maršrutētāju. Apstipriniet, ka maršruts pastāv un ka klienta iestatījums vispār atļauj pieņemt maršrutus.

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

Pirmā komanda parāda partneru sarakstu un to, vai apakštīkla maršrutētājs ir sasniedzams, otrā izdrukā klienta iestatījumus, tostarp maršrutu pieņemšanas karodziņu, un trešā jautā kodolam, kuru saskarni tas izmantotu reālam resursdatoram apakštīklā. Ja šī pēdējā komanda nosauc fizisko saskarni, nevis Tailscale saskarni, maršruts nekad nav iekļuvis tabulā. Trūkstošs maršruts ir klienta puses problēma, nevis apstiprināšanas problēma. Izlabojiet to pirms politikas apskates.

Lai Linux vidē pieņemtu maršrutus, atkārtoti izveidojiet savienojumu ar karodziņu, nevis pieņemiet, ka tas ir iestatīts: tailscale up --accept-routes. Klients, kas pievienojies ar citiem karodziņiem, tos saglabā, līdz tos maina, tāpēc pārbaudiet pašreizējo iestatījumu pirms vēl viena pievienošanas. Pirmās komandas atkārtota izpilde pēc izmaiņām parādīs maršrutu tabulā.

Pierādiet pārsūtīšanu un atpakaļceļu

Apstiprināšana nekonfigurē maršrutētāju pakešu pārsūtīšanai un nesakārto atbildi. Abi ir resursdatora līmeņa jautājumi maršrutētāja LAN pusē. Pārbaudiet tos maršrutētājā, nevis klientā.

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

Pirmajai komandai jāziņo 1, citādi kodols izmetīs pārsūtīto paketi. Otrā parāda, vai apakštīkla maršruta maskēšana pārraksta avotu, kas ir noklusējuma uzvedība un parasti tas, ko vēlaties. Trešā parāda, vai pieprasījums sasniedz galamērķi un vai kaut kas atgriežas; pieprasījums bez atbildes ir atpakaļceļa problēma, nevis apstiprināšanas problēma. Izlasiet trīs rezultātus kopā, pirms maināt kādu no tiem.

Ja maskēšana ir atspējota, galamērķa tīklam nepieciešams maršruts atpakaļ uz tailnet adresēm, un katram starpposmam tas jāzina. Maskēšanas atkārtota ieslēgšana ir ātrākais labojums vienam pakalpojumam, bet par cenu, ka galamērķim tiek paslēpta sākotnējā klienta adrese. Šis kompromiss ir svarīgs, ja galamērķis reģistrē avota adreses auditam, tāpēc izlemiet apzināti, nevis pārslēdziet karodziņu incidenta laikā. Dokumentējiet, kuru izvēli izdarījāt, jo nākamā persona redzēs tikai vienu no divām uzvedībām.

Izlasiet resursa piekļuves noteikumu

Kad maršruts ir un pārsūtīšana pierādīta, atlikušais aizdomās turamais ir politika. Izlasiet atļauju, kurai vajadzētu ļaut savienojumu, un pārbaudiet tās galamērķi, ne tikai avotu. Arī paša klienta identitātei jāatbilst politikas selektoram, tāpēc fiksējiet to tajā pašā mašīnā, kas bojāta.

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

Statusa izvade identificē paša klienta adreses un partnerus, ko tas redz, un tam jāatbilst politikas avota selektoram. tailscale ping pierāda tailnet ceļu līdz pašam apakštīkla maršrutētājam; tas atrisina partneru vārdus un tailnet adreses, nevis resursdatorus izziņotā apakštīklā. Trešā komanda sūta parastu ICMP atbalsi pa apakštīkla maršrutu, tāpēc tās rezultāts apraksta galamērķi, nevis maršrutētāju. Noraidījums tailnet līmenī parasti atgriežas kā noraidījums, kamēr pakete, kas aiziet un nekad neatgriežas, beidzas ar taimautu.

Neizdevies nosaukums ir cits jautājums nekā neizdevusies adrese; atrisiniet resursdatoru tieši pirms maršruta vainošanas. Rakstiet atļauju atbilstoši faktiskajai resursa vajadzībai, nevis visam apakštīklam. Atvērt visu /24, lai viena lietojumprogramma darbotos, ir ceļš, kā šaurs pieprasījums kļūst par plašu atļauju, ko vēlāk neviens neuzdrošinās noņemt.

Ja mērķis bija izeja internetā, nevis privāts apakštīkls, pareizā sastāvdaļa ir izejas mezgls, nevis apakštīkla maršrutētājs, un politika un maršrutēšana attiecīgi atšķiras. Pārbaudiet šo lēmumu pirms atļaujas paplašināšanas. Izejas mezgls maina noklusējuma maršrutu; apakštīkla maršrutētājs tikai izziņo prefiksu.