Enkelriktad trafik efter att ha inaktiverat Tailscale-subnätets SNAT

Stäng av käll-NAT på en Tailscale-subnätrouter och tunneln fortsätter att fungera medan anslutningarna genom den stannar. Förfrågningarna når destinationen med den fjärranslutna klientens egen overlay-adress, vilket är precis poängen med ändringen, och svaren behöver nu en väg som LAN aldrig behövde känna till. Utan den vägen landar paketen, svaren lämnar via den vanliga gatewayen, och felet framstår som ett brandväggsproblem som ingen brandväggsregel förklarar. Tunneln är frisk; returbenet saknas.

Vad SNAT dolde

Med SNAT aktiverat skriver routern om källadressen till sin egen LAN-adress innan den vidarebefordrar till subnätet, så destinationen svarar en värd som den redan vet hur den ska nå och inget annat behöver konfigureras. Avstängning bevarar den ursprungliga källan, och destinationen ser då en adress inom overlay-området i stället för en granne på sin egen kabel. Den adressen är verklig och routbar över tailnätet, och den är oåtkomlig från LAN via standardgatewayen. Den dokumenterade växeln är --snat-subnet-routes=false, tillämpad på själva Linux-subnätroutern.

Det är en fast inställning och inte en växel per paket, så returvägen måste finnas för varje destinationsnätverk som routern betjänar. Det är det som gör ändringen till ett driftsättningsbeslut i stället för en kryssruta. Allt som routern betjänar ärver kravet i samma ögonblick.

Var returvägen kan bo

Tre placeringar är vanliga, och de skiljer sig i räckvidd, inte i korrekthet. En statisk väg på destinationsvärden är den mest direkta och den minst skalbara, eftersom varje enhet behöver sin egen kopia. En routingtabell i VPC:n eller på platsens router täcker ett helt nätverk på en gång, och ett DHCP-alternativ med klasslösa statiska vägar når klienterna automatiskt men misslyckas tyst på enheter som ignorerar det.

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

Vilken placering du än väljer är nästa hopp routerns LAN-adress och aldrig dess tailnet-adress. En LAN-värd kan inte nå overlay förrän den har den här vägen, så ett nästa hopp inne i overlay är cirkulärt och skickar paketet ingenstans. Det enda felet förklarar de flesta konfigurationer som ser korrekta ut och ändå misslyckas, och det överlever varje kontroll som bara läser routerns egen tabell. Skriv ner vilken placering du använde, annars testar nästa person den felaktiga.

Att läsa felet som enkelriktad trafik

Symtomet är lättare att känna igen än orsaken: tjänsten svarar på routern själv och förblir tyst från en fjärrklient. En inspelning på destinationen visar förfrågningar som anländer och svar som lämnar, vilket ser ut som framgång tills du märker vart de svaren är på väg. De går till standardgatewayen, vilket betyder att det inkommande benet fungerade och returbenet inte.

Spela in på routern i stället, eftersom den ser båda riktningarna av ett utbyte och visar om ett svar någonsin kom. Om svaret dyker upp på destinationen men aldrig på routern saknas vägen eller är fel på destinationssidan. Om det dyker upp på routern och stannar där ligger problemet längre fram och hör till en annan undersökning.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Är den verkliga adressen värd en väg

Att behålla SNAT är fortfarande det enklare svaret när destinationsnätverket inte kan konfigureras om, och priset är att varje klient ser ut som routern i destinationens loggar och policy. Att stänga av det är motiverat när en applikation behöver den verkliga källadressen eller när nätverkspolicyn måste skilja klienter som delar en router. Båda är legitima skäl och inget av dem är gratis. Nyttan måste vara värd att underhålla en väg på varje destinationsnätverk, plus brandväggsgenomgången som beskrivs nedan.

För ett litet LAN lönar bytet sig oftast, medan det för en spridning av apparater som inte kan ta en statisk väg oftast inte gör det. Anteckna beslutet och skälet bredvid routerkonfigurationen, så att nästa administratör vet vilket beteende som är avsiktligt. En standard som ingen har skrivit ner går inte att skilja från en försummelse.

Brandvägg, loggning och den dubbla rollen

Varje regel som matchade routerns LAN-adress matchar nu en annan källa, inklusive tillåtelseregler och varje loggfält som registrerade routern som klient. Läs dessa regler före det första testet i stället för efter det första felet, eftersom en regel som bara tillåter routerns adress blockerar den nya källan helt. Begränsa ersättningen till de klienter och portar som behöver den, och bekräfta sedan att den inte tyst släpper in hela tailnätet.

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

En nod som tjänar både som utgångsnod och som subnätrouter är en dokumenterad kombination som kan tappa uppströms trafik när subnät-SNAT är inaktiverat. Att separera dessa roller på olika noder tar bort förbehållet och ger varje väg och brandväggspolicy en enda ägare. Om rollerna måste vara kvar tillsammans, förvänta dig det beteendet och testa det innan du skyller på en klient. Håll vägen, växelinställningen och rolltilldelningen i en och samma anteckning, eftersom de läses tillsammans när nästa anslutning misslyckas.