Ienrichingsferkear nei it útskeakeljen fan Tailscale-subnet-SNAT
Skeakelje SNAT út op in Tailscale-subnetrûter en antwirden komme net mear oan. It echte boarneadres bliuwt, dus it LAN hat in weromrûte nei 100.64.0.0/10 nedich.
Skeakelje boarne-NAT út op in Tailscale-subnetrûter en de tunnel bliuwt wurkjen wylst de ferbiningen der trochhinne stopje. Oanfragen komme by de bestimming oan mei it eigen overlay-adres fan 'e fiere klant, wat krekt it punt fan 'e feroaring is, en de antwirden hawwe no in paad nedich dat it LAN nea kend hawwe moatten hie. Sûnder dat paad lânje de pakketten, geane de antwirden fia de gewoane gateway fuort, en de flater docht him foar as in firewall-probleem dat gjin firewall-regel ferklearret. De tunnel is sûn; de weromweis mist.
Wat SNAT ferburch
Mei SNAT oan skriuwt de rûter it boarneadres om nei syn eigen LAN-adres foar it trochstjoeren nei it subnet, sadat de bestimming antwurdet oan in host dêr't it al wit hoe't it komme moat en neat oars hoecht te wurden konfigurearre. It útskeakeljen behâldt de oarspronklike boarne, en de bestimming sjocht dan in adres binnen it overlay-berik ynstee fan in buorman op syn eigen tried. Dat adres is echt en rûtber oer it tailnet, en it is net berikber fan it LAN ôf fia de standertgateway. De dokumintearre skeakel is --snat-subnet-routes=false, tapast op 'e Linux-subnetrûter sels.
It is in fêste ynstelling en net in skeakel per pakket, dus it werompaad moat oanwêzich wêze foar elk bestimmingsnetwurk dat dy rûter betsjinnet. Dat makket de feroaring in útrôlbeslissing ynstee fan in ôfcheckfakje. Alles dat dy rûter betsjinnet, erft de eask op itselde momint.
Wêr't it werompaad wenje kin
Trije pleatsings binne gewoan, en se ferskille yn berik, net yn krektens. In statyske rûte op 'e bestimmingshost is de meast direkte en de minst skaalbere, om't elk apparaat syn eigen kopy nedich hat. In rûtetabel yn 'e VPC of de plakrûter dekt in hiel netwurk tagelyk, en in DHCP-opsje mei klassleaze statyske rûtes berikt kliïnten automatysk mar falt stilwei om op apparaten dy't it negearje.
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
Hokker pleatsing jo ek kieze, de folgjende hop is it LAN-adres fan 'e rûter en nea syn tailnet-adres. In LAN-host kin it overlay net berikke foardat it dizze rûte hat, dus in folgjende hop binnen it overlay is sirkelfoarmich en stjoert it pakket nearne hinne. Dy iene flater ferklearret de measte konfiguraasjes dy't goed lykje en dochs misse, en hy oerlibbet elke kontrôle dy't allinnich de eigen tabel fan 'e rûter lêst. Skriuw op hokker pleatsing jo brûkt hawwe, want oars testet de folgjende persoan de ferkearde.
De flater lêze as ienrichingsferkear
It symptoom is makliker te werkenne as de oarsaak: de tsjinst antwurdet op 'e rûter sels en bliuwt stil fan in fiere klant. In opname op 'e bestimming toant oanfragen dy't oankomme en antwirden dy't fuortgeane, wat op sukses liket oant jo fernimme wêr't dy antwirden hinne geane. Se geane nei de standertgateway, wat betsjut dat it yngongsskonk wurke en it weromskonk net.
Nim dan op 'e rûter op, want dy sjocht beide rjochtingen fan ien útwikseling en toant oft in antwurd ea oankaam. As it antwurd op 'e bestimming ferskynt mar nea op 'e rûter, mist de rûte of is dy ferkeard oan 'e bestimmingskant. As it op 'e rûter ferskynt en dêr stopt, leit it probleem fierder en heart it by in oar ûndersyk.
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
Is it echte adres in rûte wurdich
SNAT hâlde bliuwt it ienfâldiger antwurd wannear't it bestimmingsnetwurk net op 'e nij konfigurearre wurde kin, en de kosten binne dat elke klant der as de rûter útsjocht yn 'e logboeken en it belied fan 'e bestimming. It útskeakeljen is rjochtfeardige as in applikaasje it echte boarneadres nedich hat of as netwurkbelied kliïnten ûnderskiede moat dy't in rûter diele. Beide binne legitime redenen en gjinien is fergees. It foardiel moat it ûnderhâlden fan in rûte op elk bestimmingsnetwurk wurdich wêze, plus de hjirûnder beskreaune firewall-beoardieling.
Foar ien lyts LAN betellet de útwikseling meastentiids, wylst dat foar in fersprieding fan apparaten dy't gjin statyske rûte nimme kinne meastentiids net betellet. Skriuw de beslissing en de reden njonken de rûterkonfiguraasje, sadat de folgjende behearder wit hokker gedrach bewust is. In standert dy't nimmen opskreaun hat, is net te ûnderskieden fan in fersom.
Firewall, logging en de dûbele rol
Elke regel dy't by it LAN-adres fan 'e rûter paste, past no by in oare boarne, en dat omfettet tastieningsregels en elk logfjild dat de rûter as klant fêstlei. Lês dy regels foar de earste test ynstee fan nei de earste mislearring, want in regel dy't allinnich it adres fan 'e rûter tastiet, blokkearret de nije boarne folslein. Beheine de ferfanging ta de kliïnten en poarten dy't it nedich hawwe, en befêstigje dan dat it net stilwei it hiele tailnet talit.
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
Ien knooppunt dat sawol as útgongsknooppunt as as subnetrûter tsjinnet, is in dokumintearre kombinaasje dy't opstreamferkear falle litte kin sadree't subnet-SNAT útskeakele is. It skieden fan dy rollen op ferskillende knooppunten hellet de foarbehâld fuort en jout elke rûte en firewall-belied ien eigner. As de rollen byinoar bliuwe moatte, ferwachtsje dan dat gedrach en test it foardat jo in klant de skuld jouwe. Hâld de rûte, de skeakelynstelling en de roltawizing yn ien notysje, want se wurde tegearre lêzen as de folgjende ferbining mislearret.