Kial aprobita Tailscale-subreta itinero ankoraŭ atingas tempolimon

Aprobo en la administra konzolo aspektas kiel la lasta paŝo, sed ĝi ne estas. Unue la aplikaĵo atingas tempolimon, kaj nur poste vi trovas la enkursigilon enrete kaj la itineron aprobita. Aprobo estas disdona paŝo, ne permeso kaj ne garantio pri plusendado. Kvar etapoj devas kongrui antaŭ ol paketo atingas gastiganton malantaŭ subreta enkursigilo, kaj ĉiu povas sukcesi dum la sekva malsukcesas. Trairu ilin laŭorde kaj haltu ĉe la unua etapo, kiu ne teniĝas.

Kvar etapoj, unu malsukceso

La enkursigilo anoncas la prefikson, la reto tailnet aprobas tiun anoncon, la kliento akceptas la itineron, kiun ĝi ricevis, kaj la alira politiko permesas la konkretan konekton. Temas pri kvar apartaj decidoj faritaj de tri diversaj komponantoj. Aprobita itinero do nur diras, ke la reto nun estas parto de la enkursiga tabelo de tailnet.

La kvara etapo estas tiu, kiu plej ofte estas preterlasata, ĉar la unuaj tri produktas videblan staton. Permeso, kiu kovras la propran tailnet-adreson de la enkursigilo, ne aŭtomate kovras privatan subreton malantaŭ ĝi. Temas pri diversaj celoj, kaj la politiko estas taksata por ĉiu celo aparte.

En Linux la tria etapo havas ankaŭ defenditan valoron, kiu surprizas homojn: akcepti subretajn itinerojn estas laŭvola. Pluraj GUI-klientoj akceptas anoncitajn itinerojn defaŭlte, do miksa aro povas montri unu malsukcesan maŝinon dum la ceteraj funkcias.

Konfirmu la agordon sur la malsukcesa maŝino anstataŭ supozi platformon. La itinero neniam estis la mankanta peco sur la funkciantaj maŝinoj, do lasu ilin pruvi, ke la flanko de tailnet estas sana. La dokumentaro de Tailscale pri subretaj enkursigiloj kovras aprobon, klientan itineran akcepton kaj la politikan etapon.

Kontrolu la itineron tie, kie la kliento funkcias

Komencu ĉe la kliento, kiu malsukcesas, ne ĉe la enkursigilo. Konfirmu, ke la itinero ĉeestas kaj ke la klienta agordo entute permesas akcepti itinerojn.

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

La unua komando montras la liston de samtavolanoj kaj ĉu la subreta enkursigilo estas atingebla, la dua presas la agordojn de la kliento inkluzive de la flago por itinera akcepto, kaj la tria demandas la kernon, kiun interfacon ĝi uzus por reala gastiganto en la subreto. Se tiu lasta komando nomas la fizikan interfacon anstataŭ la interfacon de Tailscale, la itinero neniam eniris la tabelon. Mankanta itinero estas problemo ĉe la klienta flanko, ne aproba problemo. Riparu ĝin antaŭ ol rigardi la politikon.

Por akcepti itinerojn en Linux, rekonektu kun la flago anstataŭ supozi, ke ĝi estas agordita: tailscale up --accept-routes. Kliento aliĝinta kun aliaj flagoj konservas ilin ĝis ili ŝanĝiĝos, do kontrolu la nunan agordon antaŭ ol aldoni plian. Ripeto de la unua komando post la ŝanĝo devus montri la itineron en la tabelo.

Pruvu plusendadon kaj la revenan vojon

Aprobo ne agordas la enkursigilon por plusendi paketojn, kaj ĝi ne aranĝas la respondon. Ambaŭ estas aferoj je gastiganta nivelo ĉe la LAN-flanko de la enkursigilo. Testu ilin sur la enkursigilo, ne sur la kliento.

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

La unua komando devas raporti 1, alie la kerno forĵetos la plusenditan paketon. La dua montras, ĉu la maskado de la subreta itinero reskribas la fonton, kio estas la defaŭlta konduto kaj kutime tio, kion vi volas. La tria montras, ĉu la peto alvenas al la celo kaj ĉu io revenas; peto sen respondo estas problemo de la reva vojo, ne aproba problemo. Legu la tri rezultojn kune antaŭ ol ŝanĝi iun ajn el ili.

Se la maskado estis malŝaltita, la cela reto bezonas itineron reen al la adresoj de tailnet, kaj ĉiu hopo intere devas scii tion. Reŝalti la maskadon estas la pli rapida solvo por unu servo, je la kosto kaŝi la originan klientan adreson de la celo. Tiu kompromiso gravas, kiam la celo registras fontadresojn por revizio, do decidu ĝin konscie anstataŭ ŝalti la flagon dum incidento. Dokumentu, kiun elekton vi faris, ĉar la sekva persono vidos nur unu el la du kondutoj.

Legu la aliran regulon por la rimedo

Kun la itinero ĉeestanta kaj la plusendado pruvita, la restanta suspektato estas la politiko. Legu la permeson, kiu devus permesi la konekton, kaj kontrolu ĝian celon, ne nur ĝian fonton. La identeco de la kliento mem devas ankaŭ kongrui kun la politika selektilo, do kaptu ĝin de la sama maŝino, kiu malsukcesas.

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

La stateligilo identigas la proprajn adresojn de la kliento kaj la samtavolanojn, kiujn ĝi vidas, kaj kun tio devas kongrui la fonta selektilo de la politiko. tailscale ping pruvas la itineron de tailnet ĝis la subreta enkursigilo mem; ĝi solvas nomojn de samtavolanoj kaj adresojn de tailnet, ne gastigantojn ene de anoncita subreto. La tria komando sendas ordinaran ICMP-ekon tra la subreta itinero, do ĝia rezulto priskribas la celon anstataŭ la enkursigilon. Rifuzo je tailnet-nivelo kutime revenas kiel rifuzo, dum paketo, kiu foriras kaj neniam revenas, atingas tempolimon.

Malsukcesa nomo estas alia demando ol malsukcesa adreso; solvu la gastiganton rekte antaŭ ol kulpigi la itineron. Skribu la permeson laŭ la fakta bezono de la rimedo, ne laŭ la tuta subreto. Malfermi tutan /24 por ke unu aplikaĵo funkciu estas la maniero, kiel mallarĝa peto fariĝas larĝa permeso, kiun poste neniu kuraĝas forigi.

Se la celo estis eliro al la interreto, ne privata subreto, la ĝusta komponanto estas elira nodo, ne subreta enkursigilo, kaj la politiko kaj enkursigado diferencas laŭe. Kontrolu tiun decidon antaŭ ol larĝigi permeson. Elira nodo ŝanĝas la defaŭltan itineron; subreta enkursigilo nur anoncas prefikson.