Eenrichtingsverkeer na uitschakelen van Tailscale-subnet-SNAT

Schakel bron-NAT uit op een Tailscale-subnetrouter en de tunnel blijft werken terwijl de verbindingen erdoor stoppen. Verzoeken komen aan bij de bestemming met het eigen overlay-adres van de externe client, wat precies het doel van de wijziging is, en de antwoorden hebben nu een pad nodig dat het LAN nooit hoefde te kennen. Zonder dat pad landen de pakketten, verlaten de antwoorden het netwerk via de gewone gateway, en de fout ziet eruit als een firewallprobleem dat geen firewallregel verklaart. De tunnel is gezond; het terugwegstuk ontbreekt.

Wat SNAT verborg

Met SNAT ingeschakeld herschrijft de router het bronadres naar zijn eigen LAN-adres voordat hij naar het subnet doorstuurt, zodat de bestemming antwoordt aan een host die al weet hoe hij die moet bereiken en niets anders hoeft te worden geconfigureerd. Uitschakelen behoudt de oorspronkelijke bron, en de bestemming ziet dan een adres binnen het overlay-bereik in plaats van een buur op zijn eigen kabel. Dat adres is echt en routeerbaar over de tailnet, en het is vanaf het LAN via de standaardgateway onbereikbaar. De gedocumenteerde schakelaar is --snat-subnet-routes=false, toegepast op de Linux-subnetrouter zelf.

Het is een vaste instelling en niet een schakelaar per pakket, dus het terugpad moet aanwezig zijn voor elk bestemmingsnetwerk dat die router bedient. Dat maakt de wijziging een implementatiebeslissing in plaats van een selectievakje. Alles wat die router bedient, erft de eis op hetzelfde moment.

Waar het terugpad kan leven

Drie plaatsingen zijn gebruikelijk, en ze verschillen in bereik, niet in juistheid. Een statische route op de bestemmingshost is het meest direct en het minst schaalbaar, omdat elk apparaat zijn eigen kopie nodig heeft. Een routetabel in de VPC of in de siterouter dekt een heel netwerk in één keer, en een DHCP-optie met klasseloze statische routes bereikt clients automatisch maar faalt stil op apparaten die deze negeren.

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

Welke plaatsing je ook kiest, de volgende hop is het LAN-adres van de router en nooit zijn tailnet-adres. Een LAN-host kan het overlay pas bereiken als hij deze route heeft, dus een volgende hop binnen het overlay is circulair en stuurt het pakket nergens heen. Die ene fout verklaart de meeste configuraties die er goed uitzien en toch falen, en hij overleeft elke controle die alleen de eigen tabel van de router leest. Schrijf op welke plaatsing je hebt gebruikt, anders test de volgende persoon de verkeerde.

De fout lezen als eenrichtingsverkeer

Het symptoom is makkelijker te herkennen dan de oorzaak: de dienst antwoordt op de router zelf en blijft stil vanaf een externe client. Een capture op de bestemming toont verzoeken die aankomen en antwoorden die vertrekken, wat op succes lijkt tot je opmerkt waar die antwoorden naartoe gaan. Ze gaan naar de standaardgateway, wat betekent dat het inkomende been werkte en het terugwegdeel niet.

Capture in plaats daarvan op de router, want die ziet beide richtingen van één uitwisseling en toont of een antwoord ooit aankwam. Als het antwoord op de bestemming verschijnt maar nooit op de router, ontbreekt de route of is hij verkeerd aan de bestemmingskant. Als het op de router verschijnt en daar stopt, ligt het probleem verderop en hoort het bij een ander onderzoek.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Is het echte adres een route waard

SNAT behouden blijft het eenvoudigere antwoord wanneer het bestemmingsnetwerk niet opnieuw kan worden geconfigureerd, en de prijs is dat elke client er in de logs en het beleid van de bestemming uitziet als de router. Uitschakelen is gerechtvaardigd wanneer een toepassing het echte bronadres nodig heeft of wanneer netwerkbeleid clients die een router delen moet onderscheiden. Beide zijn legitieme redenen en geen ervan is gratis. Het voordeel moet het onderhoud van een route op elk bestemmingsnetwerk waard zijn, plus de hieronder beschreven firewallbeoordeling.

Voor één klein LAN betaalt de ruil zich meestal uit, terwijl dat voor een uitgestrektheid aan apparaten die geen statische route kunnen aannemen meestal niet zo is. Leg de beslissing en de reden vast naast de routerconfiguratie, zodat de volgende beheerder weet welk gedrag bewust is. Een standaard die niemand heeft opgeschreven, is niet te onderscheiden van een vergissing.

Firewall, logboekregistratie en de dubbele rol

Elke regel die overeenkwam met het LAN-adres van de router komt nu overeen met een andere bron, inclusief toestemmingsregels en elk logveld dat de router als client vastlegde. Lees die regels vóór de eerste test in plaats van na de eerste fout, want een regel die alleen het adres van de router toestaat, blokkeert de nieuwe bron volledig. Beperk de vervanging tot de clients en poorten die deze nodig hebben, en bevestig dan dat hij niet stil de hele tailnet toelaat.

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

Eén node die zowel als exit-node als als subnetrouter dient, is een gedocumenteerde combinatie die upstreamverkeer kan laten vallen zodra subnet-SNAT is uitgeschakeld. Het scheiden van die rollen op verschillende nodes verwijdert dat voorbehoud en geeft elke route en elk firewallbeleid één eigenaar. Als de rollen bij elkaar moeten blijven, verwacht dan dat gedrag en test het voordat je een client de schuld geeft. Houd de route, de schakelaarinstelling en de roltoewijzing in één notitie, want ze worden samen gelezen wanneer de volgende verbinding faalt.