Eerrige verkeer nadat Tailscale-subnet-SNAT afgeskakel is

Skakel bron-NAT op 'n Tailscale-subnetroeteer af, en die tonnel bly werk terwyl die verbindings daardeur stop. Versoeke arriveer by die bestemming met die afgeleë kliënt se eie overlay-adres, wat juis die punt van die verandering is, en antwoorde het nou 'n pad nodig wat die LAN nooit moes ken nie. Sonder daardie pad land die pakkette, die antwoorde vertrek deur die gewone gateway, en die fout lyk soos 'n firewall-probleem wat geen firewall-reël verklaar nie. Die tonnel is gesond; die terugbeen ontbreek.

Wat SNAT verberg het

Met SNAT geaktiveer, herskryf die roeteerder die bronadres na sy eie LAN-adres voordat dit na die subnet deurstuur, so die bestemming antwoord aan 'n gasheer wat hy al ken en niks anders hoef opgestel te word nie. Deur dit te deaktiveer, bly die oorspronklike bron behoue, en die bestemming sien dan 'n adres binne die overlay-reeks eerder as 'n buur op sy eie draad. Daardie adres is werklik en roetebaar oor die tailnet, en dit is onbereikbaar vanaf die LAN deur die verstek-gateway. Die gedokumenteerde skakelaar is --snat-subnet-routes=false, toegepas op die Linux-subnetroeteerder self.

Dit is 'n staande instelling eerder as 'n per-pakket-skakelaar, so die terugpad moet in plek wees vir elke bestemmingsnetwerk wat daardie roeteerder bedien. Dit is wat die verandering 'n ontplooiingsbesluit maak eerder as 'n merkblokkie. Enigiets wat deur daardie roeteerder bedien word, erf die vereiste op dieselfde oomblik.

Waar die terugpad kan woon

Drie plasings is algemeen, en hulle verskil in bereik eerder as in korrektheid. 'n Statiese roete op die bestemmingsgasheer is die mees direkte en die mins skaleerbare, want elke toestel het sy eie kopie nodig. 'n Roetetabel in die VPC of die werfroeteerder dek 'n hele netwerk gelyktydig, en 'n DHCP-opsie wat klasselose statiese roetes dra, bereik kliënte outomaties maar misluk stil op toestelle wat dit ignoreer.

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

Watter plasing jy ook kies, die volgende hop is die roeteerder se LAN-adres en nooit sy tailnet-adres nie. 'n LAN-gasheer kan nie die overlay bereik voordat hy hierdie roete het nie, so 'n volgende hop binne die overlay is sirkelvormig en stuur die pakket nêrens heen nie. Daardie enkele fout verklaar die meeste konfigurasies wat reg lyk en steeds misluk, en dit oorleef elke kontrole wat net die roeteerder se eie tabel lees. Skryf neer watter plasing jy gebruik het, want die volgende persoon sal andersins die verkeerde een toets.

Die fout lees as eenrigtingverkeer

Die simptoom is makliker om te herken as die oorsaak: die diens antwoord op die roeteerder self en bly stil vanaf 'n afgeleë kliënt. 'n Opname op die bestemming wys versoeke wat aankom en antwoorde wat vertrek, wat soos sukses lyk totdat jy oplet waarheen daardie antwoorde op pad is. Hulle gaan na die verstek-gateway, wat beteken die inkomende been het gewerk en die terugbeen het nie.

Neem eerder op die roeteerder op, want dit sien beide rigtings van een uitruiling en wys of 'n antwoord ooit aangekom het. As die antwoord op die bestemming verskyn maar nooit op die roeteerder nie, ontbreek die roete of is dit verkeerd aan die bestemmingskant. As dit op die roeteerder verskyn en daar stop, lê die probleem verder aan en hoort dit by 'n ander ondersoek.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Of die werklike adres 'n roete werd is

Om SNAT te behou bly die eenvoudiger antwoord wanneer die bestemmingsnetwerk nie herkonfigureer kan word nie, en die koste is dat elke kliënt soos die roeteerder in die bestemming se logs en beleid lyk. Om dit af te skakel is geregverdig wanneer 'n toepassing die werklike bronadres nodig het of wanneer netwerkbeleid kliënte wat 'n roeteerder deel, moet onderskei. Beide is geldige redes en nie een is gratis nie. Die voordeel moet die moeite werd wees om 'n roete op elke bestemmingsnetwerk te onderhou, plus die firewall-hersiening wat hieronder beskryf word.

Vir een klein LAN betaal die ruil gewoonlik, terwyl dit vir 'n uitgestrektheid van toestelle wat nie 'n statiese roete kan neem nie, gewoonlik nie betaal nie. Teken die besluit en die rede langs die roeteerder-konfigurasie aan, sodat die volgende administrateur weet watter gedrag doelbewus is. 'n Verstek wat niemand neergeskryf het nie, is nie van 'n versuim te onderskei nie.

Firewall, logboeke en die dubbele rol

Elke reël wat by die roeteerder se LAN-adres gepas het, pas nou by 'n ander bron, en dit sluit toelaatreëls en enige logveld in wat die roeteerder as die kliënt aangeteken het. Lees daardie reëls voor die eerste toets eerder as ná die eerste mislukking, want 'n reël wat net die roeteerder se adres toelaat, blokkeer die nuwe bron heeltemal. Vernou die vervanging tot die kliënte en poorte wat dit nodig het, en bevestig dan dat dit nie stilweg die hele tailnet inlaat nie.

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

Een node wat as beide uitgangsknooppunt en subnetroeteerder dien, is 'n gedokumenteerde kombinasie wat opstroomverkeer kan laat val sodra subnet-SNAT gedeaktiveer is. Om daardie rolle na verskillende nodes te skei, verwyder die voorbehoud en gee elke roete en firewall-beleid 'n enkele eienaar. As die rolle saam moet bly, verwag die gedrag en toets dit voordat jy 'n kliënt blameer. Hou die roete, die skakelaar-instelling en die roltoewysing in een nota, want hulle word saam gelees wanneer die volgende verbinding misluk.