Ensrettet trafik efter deaktivering af Tailscale-subnet-SNAT
Slå SNAT fra på en Tailscale-subnetrouter, og svar holder op med at ankomme. Den rigtige kildeadresse bevares, så LAN'et har brug for en rute tilbage til 100.64.0.0/10.
Slå kilde-NAT fra på en Tailscale-subnetrouter, og tunnelen bliver ved med at virke, mens forbindelserne gennem den stopper. Forespørgsler ankommer til destinationen med den eksterne klients egen overlay-adresse, hvilket netop er meningen med ændringen, og svarene har nu brug for en vej, som LAN'et aldrig skulle kende. Uden den vej lander pakkerne, svarene forlader via den almindelige gateway, og fejlen fremstår som et firewall-problem, som ingen firewall-regel forklarer. Tunnelen er sund; returvejen mangler.
Hvad SNAT skjulte
Med SNAT aktiveret omskriver routeren kildeadressen til sin egen LAN-adresse, før den videresender til undernettet, så destinationen svarer til en vært, den allerede ved, hvordan den skal nå, og intet andet skal konfigureres. Deaktivering bevarer den oprindelige kilde, og destinationen ser derefter en adresse inden for overlay-området i stedet for en nabo på sin egen ledning. Den adresse er reel og rutbar på tværs af tailnettet, og den er uopnåelig fra LAN'et gennem standardgatewayen. Den dokumenterede kontakt er --snat-subnet-routes=false, anvendt på selve Linux-subnetrouteren.
Det er en fast indstilling og ikke en kontakt for hver pakke, så returvejen skal være på plads for hvert destinationsnetværk, som routeren betjener. Det er det, der gør ændringen til en udrulningsbeslutning i stedet for et afkrydsningsfelt. Alt, der betjenes af den router, arver kravet i samme øjeblik.
Hvor returvejen kan bo
Tre placeringer er almindelige, og de adskiller sig i rækkevidde, ikke i korrekthed. En statisk rute på destinationsværten er den mest direkte og den mindst skalerbare, da hver enhed har brug for sin egen kopi. En rutetabel i VPC'en eller på stedets router dækker et helt netværk på én gang, og en DHCP-mulighed med klasseløse statiske ruter når klienterne automatisk, men fejler lydløst på enheder, der ignorerer den.
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
Uanset hvilken placering du vælger, er næste hop routerens LAN-adresse og aldrig dens tailnet-adresse. En LAN-vært kan ikke nå overlayet, før den har denne rute, så et næste hop inde i overlayet er cirkulært og sender pakken ingen steder. Den ene fejl forklarer de fleste konfigurationer, der ser rigtige ud og alligevel fejler, og den overlever enhver kontrol, der kun læser routerens egen tabel. Skriv ned, hvilken placering du brugte, for ellers tester den næste person den forkerte.
At læse fejlen som ensrettet trafik
Symptomet er lettere at genkende end årsagen: tjenesten svarer på routeren selv og forbliver tavs fra en ekstern klient. En optagelse på destinationen viser forespørgsler, der ankommer, og svar, der forlader, hvilket ligner succes, indtil du bemærker, hvor de svar er på vej hen. De går til standardgatewayen, hvilket betyder, at indgangsbenet virkede, og returbenet ikke gjorde.
Optag i stedet på routeren, fordi den ser begge retninger af en udveksling og viser, om et svar nogensinde ankom. Hvis svaret dukker op på destinationen men aldrig på routeren, mangler ruten eller er forkert på destinationssiden. Hvis det dukker op på routeren og stopper der, ligger problemet længere fremme og hører til en anden undersøgelse.
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
Er den rigtige adresse en rute værd
At beholde SNAT er fortsat det enklere svar, når destinationsnetværket ikke kan omkonfigureres, og prisen er, at hver klient ligner routeren i destinationens logfiler og politik. At slå det fra er berettiget, når en applikation har brug for den rigtige kildeadresse, eller når netværkspolitik skal skelne klienter, der deler en router. Begge grunde er legitime, og ingen af dem er gratis. Fordelen skal være værd at vedligeholde en rute på hvert destinationsnetværk plus den firewall-gennemgang, der er beskrevet nedenfor.
For et lille LAN betaler byttet sig normalt, mens det for en spredning af apparater, der ikke kan tage en statisk rute, normalt ikke gør. Notér beslutningen og begrundelsen ved siden af routerkonfigurationen, så den næste administrator ved, hvilken adfærd der er tilsigtet. En standard, som ingen har skrevet ned, kan ikke skelnes fra en forglemmelse.
Firewall, logning og den dobbelte rolle
Hver regel, der matchede routerens LAN-adresse, matcher nu en anden kilde, og det omfatter tilladelsesregler og ethvert logfelt, der registrerede routeren som klient. Læs disse regler før den første test i stedet for efter den første fejl, fordi en regel, der kun tillader routerens adresse, blokerer den nye kilde helt. Begræns erstatningen til de klienter og porte, der har brug for den, og bekræft derefter, at den ikke i stilhed tillader hele tailnettet.
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
En node, der tjener som både exit node og subnetrouter, er en dokumenteret kombination, som kan tabe opstrøms trafik, når subnet-SNAT er deaktiveret. At adskille disse roller på forskellige noder fjerner forbeholdet og giver hver rute og firewallpolitik en enkelt ejer. Hvis rollerne skal blive sammen, forvent denne adfærd, og test den, før du bebrejder en klient. Hold ruten, kontaktindstillingen og rolletildelingen i ét notat, fordi de læses sammen, når den næste forbindelse fejler.