Ensrettet trafikk etter å ha slått av Tailscale-subnett-SNAT

Slå av kilde-NAT på en Tailscale-subnettrouter, og tunnelen fortsetter å virke mens forbindelsene gjennom den stopper. Forespørsler ankommer destinasjonen med den eksterne klientens egen overlay-adresse, som nettopp er poenget med endringen, og svarene trenger nå en vei som LAN-et aldri skulle kjenne. Uten den veien lander pakkene, svarene forlater via den vanlige gatewayen, og feilen fremstår som et brannmurproblem som ingen brannmurregel forklarer. Tunnelen er sunn; returbeinet mangler.

Hva SNAT skjulte

Med SNAT aktivert skriver ruteren om kildeadressen til sin egen LAN-adresse før den videresender til subnettet, slik at destinasjonen svarer en vert den allerede vet hvordan den skal nå, og ingenting annet trenger å konfigureres. Deaktivering bevarer den opprinnelige kilden, og destinasjonen ser da en adresse innenfor overlay-området i stedet for en nabo på sin egen ledning. Den adressen er ekte og rutbar over tailnettet, og den er utilgjengelig fra LAN-et gjennom standardgatewayen. Den dokumenterte bryteren er --snat-subnet-routes=false, brukt på selve Linux-subnettruteren.

Det er en fast innstilling og ikke en bryter per pakke, så returveien må være på plass for hvert destinasjonsnett som ruteren betjener. Det er dette som gjør endringen til en utrullingsbeslutning i stedet for en avkrysningsboks. Alt som betjenes av den ruteren, arver kravet i samme øyeblikk.

Hvor returveien kan bo

Tre plasseringer er vanlige, og de skiller seg i rekkevidde, ikke i riktighet. En statisk rute på destinasjonsverten er den mest direkte og den minst skalerbare, siden hver enhet trenger sin egen kopi. En rutetabell i VPC-en eller på stedets ruter dekker et helt nettverk på én gang, og et DHCP-alternativ med klasseløse statiske ruter når klientene automatisk, men feiler lydløst på enheter som ignorerer det.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Uansett hvilken plassering du velger, er neste hopp ruterens LAN-adresse og aldri dens tailnet-adresse. En LAN-vert kan ikke nå overlayet før den har denne ruten, så et neste hopp inne i overlayet er sirkulært og sender pakken ingen steder. Den ene feilen forklarer de fleste konfigurasjonene som ser riktige ut og likevel feiler, og den overlever enhver kontroll som bare leser ruterens egen tabell. Skriv ned hvilken plassering du brukte, ellers tester den neste personen den gale.

Å lese feilen som ensrettet trafikk

Symptomet er lettere å kjenne igjen enn årsaken: tjenesten svarer på ruteren selv og forblir taus fra en ekstern klient. En opptak på destinasjonen viser forespørsler som kommer og svar som går, noe som ser ut som suksess til du legger merke til hvor de svarene er på vei. De går til standardgatewayen, noe som betyr at inngangsbeinet virket og returbeinet ikke.

Ta opp på ruteren i stedet, fordi den ser begge retninger av en utveksling og viser om et svar noen gang kom. Hvis svaret dukker opp på destinasjonen men aldri på ruteren, mangler ruten eller er feil på destinasjonssiden. Hvis det dukker opp på ruteren og stopper der, ligger problemet lenger fremme og hører til en annen undersøkelse.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Er den ekte adressen en rute verd

Å beholde SNAT er fortsatt det enklere svaret når destinasjonsnettet ikke kan konfigureres på nytt, og prisen er at hver klient ser ut som ruteren i destinasjonens logger og policy. Å slå det av er berettiget når en applikasjon trenger den ekte kildeadressen, eller når nettverkspolicyen må skille klienter som deler en ruter. Begge er legitime grunner, og ingen av dem er gratis. Fordelen må være verdt å vedlikeholde en rute på hvert destinasjonsnett, pluss brannmurgjennomgangen som beskrives nedenfor.

For ett lite LAN lønner byttet seg vanligvis, mens det for en spredning av apparater som ikke kan ta en statisk rute vanligvis ikke gjør det. Noter beslutningen og grunnen ved siden av ruterens konfigurasjon, slik at den neste administratoren vet hvilken atferd som er tilsiktet. En standard som ingen har skrevet ned, kan ikke skilles fra en forglemmelse.

Brannmur, logging og den doble rollen

Hver regel som matchet ruterens LAN-adresse, matcher nå en annen kilde, og det inkluderer tillatelsesregler og ethvert loggfelt som registrerte ruteren som klient. Les disse reglene før den første testen i stedet for etter den første feilen, fordi en regel som bare tillater ruterens adresse, blokkerer den nye kilden fullstendig. Begrens erstatningen til klientene og portene som trenger den, og bekreft deretter at den ikke i stillhet slipper inn hele tailnettet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

En node som tjener både som utgangsnode og som subnettrouter, er en dokumentert kombinasjon som kan miste oppstrøms trafikk når subnett-SNAT er deaktivert. Å skille disse rollene på forskjellige noder fjerner forbeholdet og gir hver rute og brannmurpolicy én eier. Hvis rollene må holde sammen, forvent denne atferden og test den før du klandrer en klient. Hold ruten, bryterinnstillingen og rollefordelingen i ett notat, fordi de leses sammen når den neste forbindelsen feiler.