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

Slå av kjelde-NAT på ein Tailscale-subnettrouter, og tunnelen held fram med å verke medan sambanda gjennom han stoppar. Førespurnadene kjem fram til destinasjonen med den eigne overlay-adressa til den eksterne klienten, som nettopp er poenget med endringa, og svara treng no ein veg som LAN-et aldri skulle kjenne. Utan den vegen landar pakkane, svara går ut via den vanlege gatewayen, og feilen framstår som eit brannmurproblem som ingen brannmurregel forklarer. Tunnelen er sunn; returbeinet manglar.

Kva SNAT gøymde

Med SNAT aktivert skriv rutaren om kjeldadressa til si eiga LAN-adresse før han videresender til subnettet, slik at destinasjonen svarar ein vert han alt veit korleis han skal nå, og ingenting anna treng å konfigurerast. Deaktivering bevarer den opphavlege kjelda, og destinasjonen ser då ei adresse innanfor overlay-området i staden for ein nabo på si eiga leidning. Den adressa er ekte og rutbar over tailnettet, og ho er utilgjengeleg frå LAN-et gjennom standardgatewayen. Den dokumenterte brytaren er --snat-subnet-routes=false, brukt på sjølve Linux-subnettrutaren.

Det er ei fast innstilling og ikkje ein brytar per pakke, så returvegen må vere på plass for kvart destinasjonsnett som rutaren tener. Det er dette som gjer endringa til ei utrullingavgjerd i staden for ein avkrysningsboks. Alt som vert tent av den rutaren, arvar kravet i same augneblink.

Kvar returvegen kan bu

Tre plasseringar er vanlege, og dei skil seg i rekkevidd, ikkje i rettleik. Ei statisk rute på destinasjonsverten er den mest direkte og den minst skalerbare, sidan kvar eining treng si eiga kopi. Ei rutetabell i VPC-en eller på rutaren til staden dekkjer eit heilt nettverk på ein gong, og eit DHCP-alternativ med klasselause statiske ruter når klientane automatisk, men feilar lydlaust på einingar som ignorerer det.

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

Kva plassering du enn vel, er neste hopp LAN-adressa til rutaren og aldri tailnet-adressa hans. Ein LAN-vert kan ikkje nå overlayet før han har denne ruta, så eit neste hopp inne i overlayet er sirkulært og sender pakken ingen stad. Den eine feilen forklarer dei fleste konfigurasjonane som ser rette ut og likevel feilar, og han overlever kvar kontroll som berre les den eigne tabellen til rutaren. Skriv ned kva plassering du brukte, elles testar den neste personen den gale.

Å lese feilen som einsretta trafikk

Symptomet er lettare å kjenne att enn årsaka: tenesta svarar på rutaren sjølv og held seg taus frå ein ekstern klient. Eit opptak på destinasjonen viser førespurnader som kjem og svar som går, noko som ser ut som suksess til du legg merke til kvar dei svara er på veg. Dei går til standardgatewayen, noko som betyr at inngongsbeinet verka og returbeinet ikkje.

Ta opp på rutaren i staden, fordi han ser begge retningane av ei utveksling og viser om eit svar nokon gong kom. Viss svaret dukkar opp på destinasjonen men aldri på rutaren, manglar ruta eller ho er feil på destinasjonssida. Viss det dukkar opp på rutaren og stoppar der, ligg problemet lenger framme og høyrer til ei anna undersøking.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Er den ekte adressa ei rute verd

Å halde på SNAT er framleis det enklare svaret når destinasjonsnettet ikkje kan konfigurerast på nytt, og prisen er at kvar klient ser ut som rutaren i loggane og policyen til destinasjonen. Å slå det av er rettferdiggjort når ein applikasjon treng den ekte kjeldadressa, eller når nettverkspolicyen må skilje klientar som deler ein ruter. Begge er legitime grunnar, og ingen av dei er gratis. Fordelen må vere verd å vedlikehalde ei rute på kvart destinasjonsnett, pluss brannmurgjennomgangen som er skildra nedanfor.

For eitt lite LAN løner bytet seg vanlegvis, medan det for ei spreiing av apparat som ikkje kan ta ei statisk rute vanlegvis ikkje gjer det. Noter avgjerda og grunnen ved sida av ruterkonfigurasjonen, slik at den neste administratoren veit kva åtferd som er tilsikta. Ein standard som ingen har skrive ned, kan ikkje skiljast frå ei gløymsle.

Brannmur, logging og den doble rolla

Kvar regel som passa med LAN-adressa til rutaren, passar no med ei anna kjelde, og det omfattar løyvereglar og kvart loggfelt som registrerte rutaren som klient. Les desse reglane før den første testen i staden for etter den første feilen, fordi ein regel som berre tillèt adressa til rutaren, blokkerer den nye kjelda fullstendig. Avgrens erstatninga til klientane og portane som treng henne, og stadfest deretter at ho ikkje i stillheit slepp inn heile tailnettet.

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

Ein node som tener både som utgangsnode og som subnettrouter, er ein dokumentert kombinasjon som kan miste oppstraums trafikk når subnett-SNAT er deaktivert. Å skilje desse rollene på ulike nodar fjernar atterhaldet og gir kvar rute og brannmurpolicy ein eigar. Viss rollene må halde saman, vent denne åtferda og test henne før du klandrar ein klient. Hald ruta, brytarinnstillinga og rollefordelinga i eitt notat, fordi dei vert lesne saman når den neste sambindinga feilar.