VPSలో Tailscale subnet router ఎలా నడపాలి

Tailscale subnet router ఏం చేస్తుంది

Tailscale subnet router అనేది private IP addresses యొక్క పూర్తి పరిధిని మీ tailnet కు ప్రకటించే ఒక machine.
దాంతో tailnet లోని ప్రతి device ఆ పరిధిలోని addresses ను చేరుకోగలదు.
ఆ addresses ఉన్న ఇతర devices పై Tailscale నడవాల్సిన అవసరం లేదు.
మీ tailnet అనేది మీ private Tailscale network.
అంటే, ఒకే account లేదా organisation కు sign in చేసిన devices సమూహమే tailnet.
Exit node అనేది దీనితో తరచుగా గందరగోళం కలిగించే feature.
అది దీనికి విరుద్ధమైన పని చేస్తుంది.
అది ఒక device యొక్క మొత్తం traffic ను VPS ద్వారా బయటకు పంపుతుంది.
దాంతో public internet కు ఆ device ఉపయోగించే route గా VPS మారుతుంది.

ప్రతి అంశాన్ని ఒక్కో వాక్యంలో చెప్పాలంటే, subnet router ఒక private network ను tailnet నుంచి చేరుకోగలిగేలా చేస్తుంది.
Exit node మీ public traffic ఏ స్థానం నుంచి బయటకు వెళ్తుందో మార్చుతుంది.
మీకు రెండవ ఎంపిక కావాలంటే, దాని బదులు VPSలో Tailscale exit node ను ఎలా నడపాలి చదవండి.
ఇవి వేర్వేరు flags.
ఒకే VPS రెండింటినీ ఒకేసారి నిర్వహించగలదు.
కానీ ఇవి వేర్వేరు సమస్యలను పరిష్కరిస్తాయి.
ఇవి విఫలమయ్యే విధానాలు కూడా వేర్వేరుగా ఉంటాయి.

VPS కు subnet router అవసరమైనప్పుడు

సాధారణ సందర్భం provider ఇప్పటికే అందించిన private network. మీ VPS కు ఒక public address, అలాగే private segment పై రెండో interface ఉంటాయి. ఆ segment లోని ఇతర servers కు public address ఉండదు: 10.0.0.20 వద్ద database, 10.0.0.30 వద్ద backup target ఉంటాయి. ఒక VPS పై Tailscale అమర్చి 10.0.0.0/24 ను advertise చేస్తే, మీ laptop ఆ private addresses ను నేరుగా చేరుకోగలదు. ఆ segment లోని మరే ఇతర అంశంలోనూ మార్పు అవసరం ఉండదు. database కు ఇప్పటికీ public address ఉండదు.

మరో సందర్భంలో, VPS కు అవతల ఉన్న network ను చేరుకోవాలి. ఉదాహరణకు, స్వంత router వెనుక ఉన్న home లేదా office LAN (local area network), లేదా Tailscale ను అసలు నడపలేని appliances కలిగిన rack. managed switch లేదా locked firmware ఉన్న పాత NAS ఇందుకు ఉదాహరణలు. ఆ network లోని ఒక Linux box, దానిపై ఉన్న మిగతా అన్ని పరికరాల కోసం subnet router గా పనిచేస్తుంది.

రెండు సందర్భాల్లోనూ ఒకే అవసరం ఉంటుంది. subnet router advertise చేసే range ను, తన routing table మరియు తన firewall ఉపయోగించి, ముందుగానే చేరుకోగలగాలి. Tailscale ఆ connection ను నిర్మించదు. అది traffic ను router వరకు తీసుకెళ్లి, forward చేయడానికి kernel కు అప్పగిస్తుంది.

Tailscale ఇన్‌స్టాల్ చేసి ముందుగా స్థానిక route ను పరిశీలించండి

curl -fsSL https://tailscale.com/install.sh | sh

ఈ script distribution ను గుర్తించి, Tailscale package repository ను జోడించి, tailscale command మరియు tailscaled daemon ను ఇన్‌స్టాల్ చేసి, తరువాత service ను enable చేస్తుంది. systemctl is-active tailscaled తో దీన్ని నిర్ధారించండి. ఇది active ను చూపించాలి.

మరేదైనా చేయడానికి ముందు, మీరు advertise చేయాలనుకునే network ను VPS చేరుకోగలదని నిర్ధారించండి.

ip route show
ping -c3 10.0.0.20

ip route show నిజమైన interface పై private range ను చూపించాలి. ఉదాహరణకు 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. ఇక్కడ, అంటే router పైనే, ping విఫలమైతే ఏ Tailscale flag కూడా దాన్ని సరిచేయదు. సమస్య VPS network configuration లో లేదా target host పై ఉన్న firewall లో ఉంటుంది. ముందుగా దాన్ని సరిచేయండి, ఎందుకంటే తరువాతి ప్రతి test దానిపై ఆధారపడి ఉంటుంది.

IP forwarding ను ప్రారంభించి, reboot తర్వాత కూడా అమలులో ఉండేలా చేయండి

Forwarding ప్రారంభించకపోతే, తనకే ఉద్దేశించని ప్రతి packet ను Linux machine discard చేస్తుంది. ఇతర machines యొక్క packets ను forward చేయడం subnet router యొక్క ప్రధాన పని. అందువల్ల ఈ దశను వదిలివేయకూడదు.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

దీనిని sysctl net.ipv4.ip_forward తో తనిఖీ చేయండి. ఇది net.ipv4.ip_forward = 1 ను print చేయాలి.

ఈ దశను చాలామంది పూర్తిగా సరిగ్గా అమలు చేయరు. sudo sysctl -w net.ipv4.ip_forward=1 వెంటనే పనిచేస్తుంది, కానీ తదుపరి boot సమయంలో మాయమవుతుంది. అందువల్ల subnet router వారాలపాటు పనిచేసి, kernel upgrade తర్వాత జరిగిన reboot కు మరుసటి ఉదయం ఆగిపోవచ్చు. గందరగోళానికి కారణం ఏమిటంటే, ఏదీ విరిగినట్లు కనిపించదు. tailscale status ఇప్పటికీ node online గా ఉందని చూపిస్తుంది, admin console ఇప్పటికీ route approved అని చూపిస్తుంది, అలాగే clients వద్ద route ఇంకా installed గానే ఉంటుంది. Packets VPS కు చేరుతాయి, కానీ kernel వాటిని ఎలాంటి log లేకుండా discard చేస్తుంది. విలువలను /etc/sysctl.d/99-tailscale.conf లో రాయడం వల్ల reboot తర్వాత అవి మళ్లీ అమలులోకి వస్తాయి.

Forwarding ఇంకా off లో ఉన్నప్పుడే routes ను advertise చేస్తే, tailscale up ఆ సమయంలోనే హెచ్చరిస్తుంది. అందులోని ఒక line Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. కు దగ్గరగా ఉంటుంది. ఆ command యొక్క output ను చదవండి; దాన్ని scroll చేసి దాటిపోవద్దు.

రూట్లను ప్రకటించండి

sudo tailscale up --advertise-routes=10.0.0.0/24

ఇప్పటికే మీ tailnet లో sign in అయి ఉన్న VPSలో సెట్టింగ్‌ను అక్కడికక్కడే మార్చండి:

sudo tailscale set --advertise-routes=10.0.0.0/24

తర్వాత చేసే ప్రతి మార్పుకు tailscale set ఉపయోగించండి. ఒకే flagతో tailscale up ను మళ్లీ అమలు చేస్తే, మీరు మళ్లీ పేర్కొనని flags reset అవుతాయి. అన్ని non-default flags ను పేర్కొనాల్సి ఉంటుందని CLI error చూపించి ఆపుతుంది. tailscale set ఒక సెట్టింగ్‌ను మాత్రమే మారుస్తుంది. మిగిలిన సెట్టింగ్‌లు అలాగే ఉంటాయి.

అనేక ranges ను spaces లేకుండా, commaతో వేరు చేసిన ఒకే listలో ఇవ్వండి: --advertise-routes=10.0.0.0/24,192.168.50.0/24. ప్రతి entry CIDR notation (classless inter-domain routing, అంటే 10.0.0.0/24 రూపం)లోని network address అయి ఉండాలి. పొరపాటున మీ host address 10.0.0.5/24 ను రాస్తే అది తిరస్కరించబడుతుంది. Prefix తర్వాతి bits సున్నాలు కాకపోవడమే కారణం. Errorలో మీరు ఉద్దేశించి ఉండే prefix కూడా చూపిస్తుంది. routes ప్రకటించడం ఆపాలంటే sudo tailscale set --advertise-routes= తో ఖాళీ listను set చేయండి.

అడ్మిన్ కన్సోల్‌లో route ను ఆమోదించండి

route ను advertise చేయడం ఒక అభ్యర్థన మాత్రమే; అది మార్పును వెంటనే అమలు చేయదు. అడ్మిన్ దాన్ని ఆమోదించే వరకు ఏ client కూడా ఆ route ను స్వీకరించదు, అలాగే ఆ range లోని ఏదీ చేరుకోలేరు. ఇది ఉద్దేశపూర్వక విధానం. ఎందుకంటే ప్రతి ఒక్కరి routing table లోకి తనను తాను చేర్చుకోగల machine, తనకు నచ్చిన ఏ range కు సంబంధించిన traffic ను అయినా capture చేయగలదు.

అడ్మిన్ కన్సోల్‌లోని Machines పేజీలో route ను ఆమోదించండి. VPS subnet badge తో కనిపిస్తుంది. దాని row ను తెరిచి, subnets విభాగాన్ని కనుగొని, route settings ను edit చేసి, route ను tick చేసి, save చేయండి.

Approval ప్రతి prefix కు విడిగా వర్తిస్తుంది. ఈరోజు 10.0.0.0/24 ను, వచ్చే నెల 192.168.50.0/24 ను advertise చేస్తే, కొత్త prefix approval లేకుండా వస్తుంది; పాతది మాత్రం పనిచేస్తూనే ఉంటుంది. VPS వైపు నుంచి approved route మరియు ignored route ఒకేలా కనిపిస్తాయి. కాబట్టి మరేదైనా debug చేయడానికి ముందు console ను తనిఖీ చేయండి.

Tailnet policy file లో autoApprovers block ఉపయోగిస్తే ఈ manual step ను దాటవేయవచ్చు:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

తర్వాత ఆ tag తో node ను, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, up చేయండి. అప్పుడు route advertise చేసిన వెంటనే అది approved అవుతుంది. అదే policy file లోని tagOwners section లో ఆ tag ముందుగా ఉండాలి. మీరు script తో VPS ను rebuild చేస్తే దీన్ని ముందుగా అమర్చడం ఉపయోగకరం. ఎందుకంటే rebuild చేసిన node కొత్త node అవుతుంది, దాని routes మళ్లీ approval లేకుండానే ప్రారంభమవుతాయి.

--accept-routes లేకపోతే Linux clients route ను ఎందుకు పరిగణించవు

Route ఇప్పుడు advertise చేసి approve చేయబడింది. మీ phone మరియు Mac, 10.0.0.20 ను చేరుకోగలవు. మీ Linux laptop మాత్రం చేరుకోలేకపోతోంది. Admin console లో కూడా సమస్య కనిపించదు.

Subnet route ను accept చేయడం అంటే client యొక్క routing table లో entries రాయడం. Android, iOS, macOS, tvOS మరియు Windows లో Tailscale client ఈ పని స్వయంగా చేస్తుంది. Linux లో అలా చేయదు. Linux machine తరచుగా server లేదా router గా ఉంటుంది. దాని routing table ను ఎవరైనా ఉద్దేశపూర్వకంగా configure చేసి ఉండవచ్చు. Network నుంచి నేర్చుకున్న /24 ను మౌనంగా చేరిస్తే, ఆ machine ఇప్పటికే నిర్వహిస్తున్న traffic కు అంతరాయం కలగవచ్చు. అందుకే Linux లో ప్రతి client పై మీరు స్వయంగా opt in చేయాలి:

sudo tailscale set --accept-routes

తర్వాత route ఎక్కడ చేరిందో పరిశీలించండి:

ip route show table 52
ip route get 10.0.0.20

Linux లో Tailscale accepted routes ను main routing table లో ఉంచదు. వాటిని routing table 52 లో ఉంచి, policy rules ను install చేస్తుంది. ఈ rules priority range 5210 నుంచి 5270 లో ip rule show తో కనిపిస్తాయి. ఇవి సరిపోలని packets ను ఆ table కు పంపుతాయి. అందువల్ల ip route show మాత్రమే అమలు చేస్తే 10.0.0.0/24 ఎప్పటికీ కనిపించదు. ఆ command ను మాత్రమే పరిశీలించిన reader, --accept-routes ఏమీ చేయలేదని నిర్ధారించవచ్చు. వాస్తవాన్ని చూపించే command ip route show table 52. అందులో advertise చేసిన range tailscale0 పై కనిపించాలి.

తెలుసుకోవాల్సిన ఒక మినహాయింపు ఉంది. ఈ Linux node తన local network కోసం రెండవ subnet router గా పనిచేస్తుంటే, --accept-routes వల్ల దాని స్వంత directly connected subnet కు సంబంధించిన traffic తన interface ద్వారా కాకుండా మరొక router ద్వారా వెళ్తుంది. High availability pair లోని standby router పై --accept-routes ను off లో ఉంచి, advertise మాత్రమే చేయండి.

విఫలత పరిస్థితి: రెండు routerలు ఒకదానిపై మరొకటి మిళితమయ్యే rangeలను ప్రకటించడం

రెండు subnet routerలు ఒకే rangeలను ప్రకటించకూడదు. వేర్వేరు prefix lengthలతో మిళితమయ్యే rangeలు అనుమతించబడతాయి. Tailscale అత్యంత నిర్దిష్టమైన matchను ఎంచుకుంటుంది. Router A 10.0.0.0/24ను, router B 10.0.0.0/16ను ప్రకటిస్తే, 10.0.0.20కు వెళ్లే traffic A ద్వారా వెళ్తుంది.

A offline అయినప్పుడు జరిగే విషయం చాలామందిని ఆశ్చర్యపరుస్తుంది. Tailscale తక్కువ నిర్దిష్టమైన routeకు fallback చేయదు. 10.0.0.20కు వెళ్లే traffic ఆగిపోతుంది. 10.1.0.20కు వెళ్లే traffic మాత్రం B ద్వారా కొనసాగుతుంది. Private networkలో సగం పనిచేయడం లేదన్నట్లు ఈ లక్షణం కనిపిస్తుంది. దీనికి కారణం, మరింత నిర్దిష్టమైన prefixను కలిగి ఉన్న ఒక offline node. Failover కావాలంటే, విస్తృత rangeను ప్రకటించే router కూడా సంకుచిత prefixలను ప్రకటించేలా చూడండి. అప్పుడు రెండూ ఒకే addressesను cover చేస్తాయి.

మరొక overlap clientకు సమీపంలో జరుగుతుంది. 192.168.1.0/24లోని hotel networkలో ఉన్నప్పుడు, మీ subnet router 192.168.1.0/24ను ప్రకటిస్తే, ఒకే destinations కోసం రెండూ పోటీ పడతాయి. ఏది గెలుస్తుందో platformపై ఆధారపడి ఉంటుంది. Linuxలో Tailscale స్వంత ruleకు ముందు ఒక ruleను install చేయండి. అప్పుడు local addresses main tableను ఉపయోగిస్తాయి:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

ఈ rule persistent కాదు. తదుపరి boot సమయంలో ఇది తొలగిపోతుంది. నిజమైన పరిష్కారం ఏమిటంటే, బయట ఇతర networkలలో ఎదురుకాని private rangeను ఎంచుకోవడం. చాలా home routerలలో 192.168.0.0/24 మరియు 192.168.1.0/24 defaultలుగా ఉంటాయి. అందువల్ల మీరు ఉద్దేశపూర్వకంగా ఎంచుకున్న 10.0.0.0/8లోని rangeను ఉపయోగించండి. ఇదే collision మీరు చేతితో configure చేసే సాధారణ WireGuard VPNను కూడా పనిచేయకుండా చేస్తుంది. కారణం అదే: మరింత నిర్దిష్టమైన local route గెలుస్తుంది. అందువల్ల traffic tunnelలోకి ప్రవేశించదు.

విఫలత విధానం: DNS పరిష్కరించే చిరునామాకు ఏ route కూడా వర్తించదు

ఏదీ error ను నివేదించదు కాబట్టి దీన్ని debug చేయడం కష్టం. పేరు resolve అవుతుంది. Connection timeout అవుతుంది.

మీ private nameserver ద్వారా db.internal.example.com, 10.0.5.20 కు resolve అవుతుందని, మీరు 10.0.0.0/24 ను advertise చేశారని అనుకుందాం. Lookup విజయవంతమవుతుంది, ఎందుకంటే DNS (domain name system) resolution మరియు IP routing వేర్వేరు దశలు. వాటిలో ఏదీ మరొకదాన్ని తనిఖీ చేయదు. తరువాత 10.0.5.20 కు వెళ్లే packet కు tailnet పై సరిపోలే route కనిపించదు. అందువల్ల అది client యొక్క default gateway ద్వారా బయటకు వెళ్లి కనుమరుగవుతుంది.

ఈ రెండు భాగాలను వేరు చేయడానికి రెండు commands ఉపయోగించండి:

nslookup db.internal.example.com
ip route get 10.0.5.20

Lookup ఒక address ను తిరిగి ఇస్తే, కానీ ip route get, dev tailscale0 తో సమాధానం ఇవ్వకపోతే, పేరు సరిగానే ఉంది; route మాత్రం లేదు. ఆ address ను కవర్ చేసే range ను advertise చేయండి. అది 10.0.0.0/16 కావచ్చు లేదా రెండవ explicit prefix కావచ్చు. తరువాత console లో కొత్త prefix ను approve చేయండి.

Nameserver పైనే ఇలాంటి మరో సమస్య ఉండవచ్చు. మీరు admin console లో 10.0.0.53 వంటి private address వద్ద global nameserver ను సెట్ చేస్తే, ఆ address approved route లో ఉండాలి. లేకపోతే మీ devices resolver ను అసలు చేరుకోలేవు. చేరుకోలేని resolver వైపు చూపిస్తూ local DNS servers ను override చేసే option ను enable చేస్తే, tailnet లోని ప్రతి device name resolution ను ఒకేసారి కోల్పోతుంది. ఒక క్షణం ముందు పనిచేసిన devices కూడా దీనికి మినహాయింపు కావు. ముందుగా resolver కు సంబంధించిన route ను advertise చేసి approve చేయండి. తరువాత DNS setting ను మార్చండి. Tunnel లోని DNS సమస్యను మీరు పదేపదే పరిష్కరించాల్సి వస్తుంటే, coordination layer లేకుండా ఇదే mechanism ను వివరించే WireGuard tunnel లో DNS ఎలా విఫలమవుతుంది చూడండి.

Source NAT మరియు site to site links

డిఫాల్ట్‌గా subnet router ప్రతి forwarded packet యొక్క source address ను తన private address కు మార్చుతుంది. దీనిని SNAT (source network address translation) అంటారు. Private network లో ఎలాంటి మార్పులు చేయకుండానే replies పనిచేయడానికి ఇది అవసరం. 10.0.0.20 వద్ద ఉన్న database కి VPS ను ఎలా చేరుకోవాలో ఇప్పటికే తెలుసు కాబట్టి, అది VPS కు సమాధానం పంపుతుంది. అయితే దీని వల్ల database కు వచ్చే ప్రతి tailnet connection VPS నుంచే వచ్చినట్లుగా కనిపిస్తుంది. అందువల్ల source ఆధారిత firewall rules మరియు access logs ఉపయోగకరమైన సమాచారాన్ని ఇవ్వవు.

Client యొక్క అసలు tailnet address అలాగే ఉండాలి అనుకుంటే Linux లో దీన్ని ఆపండి:

sudo tailscale set --snat-subnet-routes=false

తర్వాత private network లోని hosts కు 100.64.0.0/10 కు తిరిగి వెళ్లే route అవసరం. ఇది Tailscale devices కు కేటాయించే range. ఆ route subnet router ను సూచించాలి. ఈ return route లేకపోతే replies default gateway కు వెళ్తాయి. అవి తిరిగి చేరవు. దాంతో మొదటి packet తర్వాత connections నిలిచిపోతాయి. Private network gateway పై static route జోడించండి. లేదంటే SNAT ను కొనసాగించండి.

Site to site link లో రెండు subnet routers ఇదే పనిని పరస్పరం చేస్తాయి. ప్రతి router తన network ను advertise చేసి, మరొక router యొక్క network ను అంగీకరిస్తుంది:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

మరొక router పై దానికి సరిపోయే command ను దాని స్వంత range తో అమలు చేయండి. రెండు ranges వేర్వేరుగా ఉండాలి. ssh మరియు ping సరిగ్గా పనిచేస్తున్నప్పటికీ పెద్ద transfers నిలిచిపోతే, కారణం MSS (maximum segment size). TCP packet మోసే data యొక్క గరిష్ఠ పరిమాణమే MSS. Tunnel overhead వల్ల మధ్యలోని ఏదైనా link కు forwarded packets చాలా పెద్దవిగా మారవచ్చు. MSS clamping దీనిని సరిచేస్తుంది:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ఆ rule ను iptables-persistent తో save చేయండి. లేకపోతే తదుపరి boot సమయంలో అది తొలగిపోతుంది.

ఇది సక్రమంగా పనిచేయడానికి అవసరమైన నిర్వహణ

August 2026 నాటికి, Node keys డిఫాల్ట్‌గా 180 days తర్వాత గడువు ముగుస్తుంది. Subnet router పై ఉన్న key గడువు ముగిసినప్పుడు, node sign out అవుతుంది. దాంతో ప్రచారం చేసిన మొత్తం range అందుబాటులో ఉండదు. దీనికి కారణం చూపించే configuration change ఎక్కడా ఉండకపోవచ్చు. Admin console లోని Machines page నుంచి ఈ machine కోసం key expiry ను disable చేయండి. తరువాత ఆ పని చేసినట్లు నమోదు చేసుకోండి.

Tailscale peers మధ్య direct connection ను ప్రాధాన్యంగా ఉపయోగిస్తుంది. Direct connection ఏర్పరచలేకపోతే relay servers కు fallback అవుతుంది. Relay servers పనిచేస్తాయి. అయితే అవి latency ను పెంచుతాయి. Public address ఉన్న VPS సులభమైన సందర్భం. Inbound UDP 41641 ను అనుమతిస్తే, చాలా మంది peers direct గా connect అవుతారు. Firewall ను ufw నిర్వహిస్తుంటే, VPS కు వాస్తవంగా అవసరమైన ufw rules లో syntax ఇవ్వబడింది.

Access rules కూడా అంతే ముఖ్యమైనవి. Default tailnet లో మీ ప్రతి device, మీ ఇతర ప్రతి device ను reach చేయగలదు. అందువల్ల approved route వెంటనే పనిచేస్తుంది. మీరు ACL policy రాసిన తర్వాత, rule యొక్క destination side లో private range ను పేర్కొనాలి. ఎందుకంటే 10.0.0.20 tailnet address కాదు. Tailnet IPs లేదా tags ఆధారంగా రాసిన rules దీనిని cover చేయవు.

చివరగా, మీరు స్వయంగా నడపని coordination server ను ఉపయోగించాలా వద్దా నిర్ణయించండి. Tailscale యొక్క control plane hosted service. మీ keys మీ machines పైనే ఉంటాయి. కానీ account మరియు policy file అక్కడే ఉంటాయి. మీ స్వంత VPS పై నడిపే Headscale self-hosted Tailscale control server ఉపయోగిస్తే, coordination server మీ నియంత్రణలో ఉంటుంది. అయితే దాన్ని మీరు నిర్వహించాలి. ఇదే ఆందోళనకు మరో పరిష్కారం Tailscale clients ను కూడా వదిలేయడం. NetBird VPN server ను self-host చేయడం ద్వారా coordination layer మరియు దాని mesh clients ను మీరు నియంత్రించే ఒకే machine పై నడపవచ్చు. ఈ model మరియు చేతితో రాసిన config మధ్య ఇంకా నిర్ణయించుకుంటుంటే, WireGuard మరియు Tailscale పోలిక coordination layer అందించే ప్రయోజనాలు, దాని నిర్వహణ ఖర్చు ఏమిటో వివరిస్తుంది.

FAQ

subnet router మరియు exit node మధ్య తేడా ఏమిటి?

subnet router private addresses పరిధిని ప్రకటిస్తుంది. అందువల్ల Tailscale అమలు చేయని యంత్రాలను tailnet పరికరాలు చేరుకోగలవు. exit node మొత్తం internet కు route గా తనను తాను ప్రకటిస్తుంది. అందువల్ల పరికరం తన network traffic మొత్తాన్ని ఆ node యొక్క public address ద్వారా పంపుతుంది. ఒక VPS రెండింటిగానూ పనిచేయవచ్చు. ఇవి వేర్వేరు flags, --advertise-routes మరియు --advertise-exit-node. ప్రతి flag కు admin console లో ప్రత్యేక అనుమతి అవసరం.

నా Linux client ప్రకటించిన subnet route ను ఎందుకు ఉపయోగించడం లేదు?

Linux clients subnet routes ను స్వయంచాలకంగా అంగీకరించవు. Client పై sudo tailscale set --accept-routes అమలు చేయండి. తరువాత ip route show table 52 తో తనిఖీ చేయండి; ip route show తో కాదు. Tailscale అంగీకరించిన routes ను routing table 52 లో install చేసి, policy rules ద్వారా వాటిని చేరుకుంటుంది. అందువల్ల main table వాటిని ఎప్పుడూ చూపించదు. పనిచేస్తున్న route కనిపించనట్టుగా అనిపించవచ్చు.

Reboot తర్వాత నా subnet పనిచేయడం ఆగిపోయింది. ఏమి విఫలమైంది?

అత్యంత సాధ్యమైన కారణం IP forwarding. sysctl -w తో సెట్ చేసిన విలువ reboot తర్వాత నిలిచి ఉండదు. అందువల్ల దాన్ని /etc/sysctl.d/99-tailscale.conf లో వ్రాసి, sysctl net.ipv4.ip_forward తో నిర్ధారించండి. Forwarding ప్రారంభంలో ఉన్నా range ఇంకా చేరుకోలేకపోతే, admin console లో node ను పరిశీలించండి. Node keys కు default గా 180 days తర్వాత గడువు ముగుస్తుంది. గడువు ముగిసిన subnet router account సమస్యగా కాకుండా network fault గా కనిపిస్తుంది.

రెండు subnet routers ఒకే range ను ప్రకటించగలవా?

ఒకే విధమైన ranges ను ప్రకటించలేవు. వేర్వేరు prefix lengths కలిగిన overlapping ranges అనుమతించబడతాయి. వాటిలో అత్యంత specific route గెలుస్తుంది. Failover కు జాగ్రత్త అవసరం. మరింత specific prefix ను కలిగి ఉన్న router offline అయితే, Tailscale విస్తృత route కు fallback చేయదు. అందువల్ల ఆ traffic ఆగిపోతుంది. నిజమైన standby pair కోసం, రెండు routers ఒకే specific prefixes ను ప్రకటించేలా చేయండి.

Hostname resolve అవుతోంది, కానీ connection timeout అవుతోంది. ఎందుకు?

DNS resolution మరియు routing వేర్వేరు దశలు. ఒక పేరు ఏ approved route పరిధిలోనూ లేని address కు resolve కావచ్చు. అప్పుడు packet client యొక్క default gateway ద్వారా బయటకు వెళ్తుంది. Client పై ip route get <address> అమలు చేయండి. సమాధానంలో dev tailscale0 లేకపోతే, ఆ address ను కవర్ చేసే range ను ప్రకటించి, admin console లో కొత్త prefix కు అనుమతి ఇవ్వండి.