VPS లో Tailscale subnet router ని సెటప్ చేయడం ఎలా

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

Tailscale subnet router అనేది ఒక యంత్రం, ఇది మీ tailnet కు ప్రైవేట్ IP అడ్రస్‌ల శ్రేణిని ప్రకటిస్తుంది, తద్వారా ఆ పరిధిలోని ఏ పరికరంలోనూ Tailscale లేకపోయినా tailnet లోని ప్రతి పరికరం వాటిని చేరుకోగలదు. మీ tailnet అనేది మీ ప్రైవేట్ Tailscale నెట్‌వర్క్: ఇది ఒకే ఖాతా లేదా సంస్థకు సైన్ ఇన్ చేసిన పరికరాల సమూహం. Exit node అనేది దీనితో ప్రజలు తరచుగా గందరగోళానికి గురయ్యే ఫీచర్, కానీ ఇది దీనికి విరుద్ధమైన పనిని చేస్తుంది. ఇది ఒక పరికరం యొక్క మొత్తం ట్రాఫిక్‌ను VPS ద్వారా పంపుతుంది, తద్వారా ఆ పరికరానికి VPS పబ్లిక్ ఇంటర్నెట్ మార్గంగా మారుతుంది.

ప్రతిదానికీ ఒక వాక్యం. Subnet router ఒక ప్రైవేట్ నెట్‌వర్క్‌ను tailnet నుండి చేరుకోగలిగేలా చేస్తుంది. Exit node మీ పబ్లిక్ ట్రాఫిక్ ఎక్కడి నుండి వెళ్లాలో మారుస్తుంది. మీకు కావలసింది రెండవది అయితే, VPS పై Tailscale exit node ను ఎలా రన్ చేయాలి అనే దానిని చదవండి. ఇవి వేర్వేరు flags, ఒకే VPS రెండింటినీ ఒకేసారి చేయగలదు, కానీ అవి వేర్వేరు సమస్యలను పరిష్కరిస్తాయి మరియు వేర్వేరు కారణాలతో విఫలమవుతాయి.

VPS కు subnet router ఎప్పుడు అవసరమవుతుంది

మీ సర్వీస్ ప్రొవైడర్ ఇప్పటికే మీకు అందించిన ప్రైవేట్ నెట్‌వర్క్ దీనికి సాధారణ ఉదాహరణ. మీ VPS కు ఒక పబ్లిక్ అడ్రస్ మరియు ప్రైవేట్ సెగ్మెంట్‌లో రెండవ ఇంటర్‌ఫేస్ ఉంటాయి. ఆ సెగ్మెంట్‌లోని ఇతర సర్వర్లకు పబ్లిక్ అడ్రస్ ఉండదు: ఉదాహరణకు 10.0.0.20 వద్ద ఉన్న డేటాబేస్, 10.0.0.30 వద్ద ఉన్న బ్యాకప్ టార్గెట్. ఒక VPS లో Tailscale ఇన్‌స్టాల్ చేసి, 10.0.0.0/24 ను advertise చేస్తే, మీ ల్యాప్‌టాప్ నేరుగా ఆ ప్రైవేట్ అడ్రస్‌లను చేరుకోగలదు. ఆ సెగ్మెంట్‌లో మరేమీ మారదు, డేటాబేస్‌కు ఇప్పటికీ పబ్లిక్ అడ్రస్ ఉండదు. ఆ సెగ్మెంట్ నుండి మీకు ఒకే ఒక పోర్ట్‌లోని వెబ్ యాప్ మాత్రమే అవసరమైతే, మొత్తం రేంజ్‌ను advertise చేయడం అనవసరం. అటువంటప్పుడు Tailscale serve ఆ ఒక్క పోర్ట్‌పై HTTPS ను ఉంచుతుంది. ఇదే తర్కం localhost కు మాత్రమే బైండ్ అయ్యే డెమన్‌లకు కూడా వర్తిస్తుంది. ఉదాహరణకు systemd కింద headless గా నడిచే dsh, దీని UI ని చేరుకోవడానికి మీరు ఉంచే SSH టన్నెల్‌కు బదులుగా ఆ VPS లోని tailnet అడ్రస్ ఉపయోగపడుతుంది.

మరొక సందర్భం VPS కు అవతలి వైపు ఉన్న నెట్‌వర్క్. సొంత రౌటర్ వెనుక ఉన్న హోమ్ లేదా ఆఫీస్ LAN (local area network), లేదా Tailscale రన్ చేయలేని పరికరాల రాక్ (ఉదాహరణకు managed switch లేదా పాత NAS). ఆ నెట్‌వర్క్‌లోని ఒక Linux బాక్స్ మిగిలిన అన్నింటికీ subnet router గా మారుతుంది. ఇంట్లో అయితే, ఆ బాక్స్ సాధారణంగా మీరు ఇప్పటికే రన్ చేస్తున్న హైపర్‌వైజర్‌పై ఉండే చిన్న VM అవుతుంది. మీ సర్వీసులు ఎక్కడ ఉండాలో నిర్ణయించుకునే ముందు ఇంట్లో Proxmox హోస్ట్ మరియు అద్దెకు తీసుకున్న VPS ఖర్చుల మధ్య వ్యత్యాసాన్ని సరిచూసుకోవాలి.

ఈ రెండు సందర్భాలకు ఒకే అవసరం ఉంది. సబ్నెట్ రౌటర్ తన సొంత రౌటింగ్ టేబుల్ మరియు ఫైర్‌వాల్ ఉపయోగించి తాను advertise చేసే రేంజ్‌ను చేరుకోగలగాలి. Tailscale ఆ కనెక్షన్‌ను నిర్మించదు. ఇది ట్రాఫిక్‌ను రౌటర్‌కు చేరవేసి, ఫార్వర్డ్ చేయడానికి కెర్నల్‌కు అందిస్తుంది.

Tailscale ను ఇన్‌స్టాల్ చేసి, మొదట లోకల్ రూట్‌ను తనిఖీ చేయండి

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

ఈ స్క్రిప్ట్ మీ డిస్ట్రిబ్యూషన్‌ను గుర్తిస్తుంది, Tailscale ప్యాకేజీ రిపోజిటరీని జోడిస్తుంది, tailscale కమాండ్‌ను మరియు tailscaled డెమన్‌ను ఇన్‌స్టాల్ చేస్తుంది, ఆపై సేవను ఎనేబుల్ చేస్తుంది. దీనిని systemctl is-active tailscaled తో నిర్ధారించుకోండి, ఇది active అని చూపించాలి.

మరేదైనా చేసే ముందు, మీరు అడ్వర్టైజ్ చేయాలనుకుంటున్న నెట్‌వర్క్‌ను VPS చేరుకోగలదని నిర్ధారించుకోండి.

ip route show
ping -c3 10.0.0.20

ip route show కమాండ్ ఏదైనా ఒక రియల్ ఇంటర్‌ఫేస్‌పై ప్రైవేట్ రేంజ్‌ను చూపాలి, ఉదాహరణకు 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5 లాగా ఉండాలి. ఒకవేళ ఇక్కడ, అంటే రూటర్ వద్దే పింగ్ విఫలమైతే, ఏ Tailscale ఫ్లాగ్ కూడా దీనిని సరిచేయలేదు. సమస్య VPS నెట్‌వర్క్ కాన్ఫిగరేషన్‌లో లేదా టార్గెట్ హోస్ట్‌లోని ఫైర్‌వాల్‌లో ఉంది. ముందుగా దానిని సరిచేయండి, ఎందుకంటే తర్వాతి పరీక్షలన్నీ దీనిపైనే ఆధారపడి ఉంటాయి.

IP forwarding ను ఆన్ చేయడం మరియు reboot తర్వాత కూడా అది కొనసాగేలా చేయడం

Linux మెషీన్ తనకు ఉద్దేశించని ప్యాకెట్లను forwarding ఆన్ చేయకపోతే తిరస్కరిస్తుంది. ఇతర మెషీన్ల ప్యాకెట్లను 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 ను ప్రింట్ చేయాలి.

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

forwarding ఆఫ్‌లో ఉన్నప్పుడు మీరు routes ను advertise చేస్తే, tailscale up ఆ సమయంలో మిమ్మల్ని హెచ్చరిస్తుంది, ఇది Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. కి దగ్గరగా ఉండే లైన్‌ను చూపిస్తుంది. ఆ కమాండ్ అవుట్‌పుట్‌ను దాటవేయకుండా చదవండి.

రూట్‌లను (routes) ప్రకటించడం

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

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

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

తర్వాతి మార్పులన్నింటికీ tailscale set ఉపయోగించండి. కేవలం ఒకే ఒక ఫ్లాగ్‌తో tailscale up ని మళ్ళీ రన్ చేస్తే, మీరు పేర్కొనని ఇతర ఫ్లాగ్‌లు రీసెట్ అవుతాయి. అప్పుడు, సెట్టింగ్‌లను ఈ పద్ధతిలో మార్చాలంటే డిఫాల్ట్ కాని ఫ్లాగ్‌లన్నింటినీ పేర్కొనాలని CLI ఒక ఎర్రర్‌ను చూపిస్తుంది. tailscale set ఒక సెట్టింగ్‌ను మాత్రమే మారుస్తుంది, మిగిలిన వాటిని అలాగే ఉంచుతుంది.

అనేక రేంజ్‌లను ఖాళీలు లేకుండా కామాతో వేరు చేసిన జాబితాగా ఇవ్వాలి: --advertise-routes=10.0.0.0/24,192.168.50.0/24. ప్రతి ఎంట్రీ CIDR నోటేషన్‌లో (classless inter-domain routing, 10.0.0.0/24 ఫార్మాట్) నెట్‌వర్క్ అడ్రస్‌గా ఉండాలి. పొరపాటున మీ స్వంత హోస్ట్ అడ్రస్‌ను, అంటే 10.0.0.5/24 ని రాస్తే, అది తిరస్కరించబడుతుంది. ఎందుకంటే ప్రిఫిక్స్ తర్వాత ఉన్న బిట్స్ సున్నాగా లేవు, మరియు ఆ ఎర్రర్ మీరు ఉద్దేశించిన ప్రిఫిక్స్‌ను సూచిస్తుంది. రూట్‌లను ప్రకటించడం ఆపివేయడానికి, sudo tailscale set --advertise-routes= తో ఖాళీ జాబితాను సెట్ చేయండి.

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

రూట్‌ను అడ్వర్టైజ్ చేయడం అనేది ఒక అభ్యర్థన మాత్రమే, మార్పు కాదు. అడ్మిన్ దానిని ఆమోదించే వరకు, ఏ క్లయింట్ ఆ రూట్‌ను స్వీకరించదు మరియు ఆ పరిధిలోని ఏదీ అందుబాటులో ఉండదు. ఇది ఉద్దేశపూర్వకంగానే చేయబడింది, ఎందుకంటే ఏదైనా మెషిన్ తనను తాను అందరి రూటింగ్ టేబుల్‌లోకి చేర్చుకోగలిగితే, అది తనకు నచ్చిన ఏ పరిధికి సంబంధించిన ట్రాఫిక్‌నైనా దొంగిలించగలదు.

అడ్మిన్ కన్సోల్‌లోని Machines పేజీలో దీనిని ఆమోదించండి. VPS ఒక subnet బ్యాడ్జ్‌తో కనిపిస్తుంది. దాని వరుసను తెరిచి, subnets విభాగాన్ని కనుగొని, రూట్ సెట్టింగ్‌లను ఎడిట్ చేసి, రూట్‌ను టిక్ చేసి, సేవ్ చేయండి.

ఆమోదం అనేది ప్రతి ప్రిఫిక్స్‌కు విడివిడిగా ఉంటుంది. ఈరోజు 10.0.0.0/24 ను అడ్వర్టైజ్ చేసి, వచ్చే నెలలో 192.168.50.0/24 ను అడ్వర్టైజ్ చేస్తే, పాతది పనిచేస్తూనే ఉంటుంది కానీ కొత్త ప్రిఫిక్స్ ఆమోదం లేకుండానే వస్తుంది. ఆమోదించబడిన రూట్ మరియు విస్మరించబడిన రూట్, VPS నుండి చూసినప్పుడు ఒకేలా కనిపిస్తాయి, కాబట్టి మీరు వేరే దేనినైనా డీబగ్ చేసే ముందు కన్సోల్‌ను తనిఖీ చేయండి.

మీరు tailnet పాలసీ ఫైల్‌లో autoApprovers బ్లాక్‌ను ఉపయోగించి మాన్యువల్ దశను దాటవేయవచ్చు:

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

ఆ తర్వాత ఆ ట్యాగ్‌తో నోడ్‌ను ప్రారంభించండి, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, అప్పుడు రూట్ అడ్వర్టైజ్ అయిన వెంటనే ఆమోదించబడుతుంది. ఆ ట్యాగ్ ముందుగా అదే పాలసీ ఫైల్‌లోని tagOwners విభాగంలో ఉండాలి. మీరు స్క్రిప్ట్ ద్వారా VPSని మళ్లీ నిర్మిస్తున్నట్లయితే ఇది సెటప్ చేసుకోవడం మంచిది, ఎందుకంటే మళ్లీ నిర్మించిన నోడ్ ఒక కొత్త నోడ్‌గా పరిగణించబడుతుంది మరియు దాని రూట్లు మళ్లీ ఆమోదం పొందాల్సి ఉంటుంది.

Linux క్లయింట్లు --accept-routes లేకుండా రూట్‌ను ఎందుకు విస్మరిస్తాయి

రూట్ ఇప్పుడు అడ్వర్టైజ్ చేయబడింది మరియు ఆమోదించబడింది. మీ ఫోన్ మరియు మీ Mac 10.0.0.20 ని చేరుకోగలవు. మీ Linux ల్యాప్‌టాప్ చేరుకోలేదు, మరియు అడ్మిన్ కన్సోల్‌లో ఎటువంటి సమస్య కనిపించడం లేదు.

సబ్‌నెట్ రూట్‌ను అంగీకరించడం అంటే క్లయింట్ యొక్క రూటింగ్ టేబుల్‌లోకి ఎంట్రీలను రాయడం. Android, iOS, macOS, tvOS మరియు Windows లలో, Tailscale క్లయింట్ మీ కోసం ఆ పని చేస్తుంది. Linux లో అది అలా చేయదు, ఎందుకంటే Linux మెషీన్ తరచుగా ఒక సర్వర్ లేదా రూటర్ అయి ఉంటుంది, దీని రూటింగ్ టేబుల్‌ను ఎవరైనా ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేసి ఉంటారు. నెట్‌వర్క్ నుండి నేర్చుకున్న /24 ని నిశ్శబ్దంగా చేర్చడం వల్ల ఆ మెషీన్ ఇప్పటికే హ్యాండిల్ చేస్తున్న ట్రాఫిక్ దెబ్బతినవచ్చు. కాబట్టి Linux లో, ప్రతి క్లయింట్‌పై మీరు దీన్ని మాన్యువల్‌గా ఎంచుకోవాలి:

sudo tailscale set --accept-routes

ఆ తర్వాత రూట్ ఎక్కడ చేరిందో తనిఖీ చేయండి:

ip route show table 52
ip route get 10.0.0.20

Linux లో Tailscale ఆమోదించబడిన రూట్‌లను మెయిన్ రూటింగ్ టేబుల్‌లో ఉంచదు. ఇది వాటిని రూటింగ్ టేబుల్ 52 లో ఉంచి, పాలసీ రూల్స్‌ను ఇన్‌స్టాల్ చేస్తుంది. ఇవి ip rule show తో 5210 నుండి 5270 ప్రాధాన్యత పరిధిలో కనిపిస్తాయి, ఇవి సరిపోలని ప్యాకెట్లను ఆ టేబుల్‌కు పంపుతాయి. కాబట్టి ip route show మాత్రమే ఎప్పటికీ 10.0.0.0/24 ని చూపదు, మరియు ఆ కమాండ్‌ను మాత్రమే చూసే వ్యక్తి --accept-routes ఏమీ చేయలేదని భావిస్తారు. ip route show table 52 అనేది వాస్తవాన్ని చూపే కమాండ్, మరియు ఇది అడ్వర్టైజ్ చేయబడిన పరిధిని tailscale0 పై చూపాలి.

ఒక మినహాయింపు గురించి తెలుసుకోవడం ముఖ్యం. ఈ Linux నోడ్ స్వయంగా దాని స్థానిక నెట్‌వర్క్ కోసం రెండవ సబ్‌నెట్ రూటర్ అయితే, --accept-routes దాని స్వంత ఇంటర్‌ఫేస్ ద్వారా కాకుండా మరొక రూటర్ ద్వారా దాని స్వంత డైరెక్ట్ కనెక్ట్ చేయబడిన సబ్‌నెట్ కోసం ట్రాఫిక్‌ను పంపేలా చేస్తుంది. హై అవైలబిలిటీ జంటలో స్టాండ్‌బై రూటర్‌పై, --accept-routes ని ఆఫ్ చేసి ఉంచి, కేవలం అడ్వర్టైజ్ మాత్రమే చేయండి.

వైఫల్య విధానం: రెండు రౌటర్లు ఒకే పరిధిని ప్రకటిస్తున్నప్పుడు

రెండు సబ్‌నెట్ రౌటర్లు ఒకే విధమైన పరిధులను ప్రకటించకూడదు. వేర్వేరు ప్రిఫిక్స్ పొడవులతో అతివ్యాప్తి చెందే (overlapping) పరిధులను అనుమతిస్తారు, అప్పుడు Tailscale అత్యంత ఖచ్చితమైన మ్యాచ్‌ను ఎంచుకుంటుంది. రౌటర్ A 10.0.0.0/24 ని మరియు రౌటర్ B 10.0.0.0/16 ని ప్రకటిస్తున్నప్పుడు, 10.0.0.20 కి వెళ్లే ట్రాఫిక్ A కి చేరుతుంది.

A ఆఫ్‌లైన్‌లోకి వెళ్ళినప్పుడు జరిగే ప్రవర్తన వినియోగదారులను ఆశ్చర్యపరుస్తుంది. Tailscale తక్కువ ఖచ్చితత్వం కలిగిన మార్గానికి (less specific route) మారదు. 10.0.0.20 కి వెళ్లే ట్రాఫిక్ ఆగిపోతుంది, అదే సమయంలో 10.1.0.20 కి వెళ్లే ట్రాఫిక్ B ద్వారా పనిచేస్తూనే ఉంటుంది. ప్రైవేట్ నెట్‌వర్క్‌లో సగం భాగం పనిచేయడం లేదని దీని లక్షణం కనిపిస్తుంది, దీనికి కారణం ఆఫ్‌లైన్‌లో ఉన్న నోడ్ మరింత ఖచ్చితమైన ప్రిఫిక్స్‌ను కలిగి ఉండటమే. మీకు ఫెయిలోవర్ (failover) కావాలంటే, విస్తృతమైన రౌటర్ కూడా తక్కువ పరిధి గల ప్రిఫిక్స్‌లను ప్రకటించేలా చూడండి, తద్వారా రెండూ ఒకే చిరునామాలను కవర్ చేస్తాయి.

మరొక అతివ్యాప్తి క్లయింట్‌కు దగ్గరగా ఉంటుంది. మీరు 192.168.1.0/24 వద్ద ఉన్న హోటల్ నెట్‌వర్క్‌లో ఉన్నప్పుడు, మీ సబ్‌నెట్ రౌటర్ 192.168.1.0/24 ని ప్రకటిస్తే, ఆ రెండు ఒకే గమ్యస్థానాల కోసం పోటీపడతాయి; ఏది గెలుస్తుందనేది ప్లాట్‌ఫారమ్‌పై ఆధారపడి ఉంటుంది. Linux లో, Tailscale సొంత రూల్ కంటే ముందు ఒక రూల్‌ను ఇన్‌స్టాల్ చేయండి, తద్వారా లోకల్ చిరునామాలు మెయిన్ టేబుల్‌ను ఉపయోగిస్తాయి:

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

ఆ రూల్ శాశ్వతం కాదు మరియు తదుపరి బూట్ వద్ద తొలగించబడుతుంది. నిజమైన పరిష్కారం ఏమిటంటే, బయట నెట్‌వర్క్‌లలో మీకు ఎదురుపడని ప్రైవేట్ పరిధిని ఎంచుకోవడం. 192.168.0.0/24 మరియు 192.168.1.0/24 అనేవి చాలా హోమ్ రౌటర్లలో డిఫాల్ట్‌గా ఉంటాయి, కాబట్టి మీరు ఉద్దేశపూర్వకంగా ఎంచుకున్న 10.0.0.0/8 లోపల ఏదైనా ఒక దానిని ఎంచుకోండి. ఇదే విధమైన ఘర్షణ మీరు స్వయంగా కాన్ఫిగర్ చేసుకునే సాధారణ WireGuard VPN ని కూడా దెబ్బతీస్తుంది, అదే కారణంతో: మరింత ఖచ్చితమైన లోకల్ రూట్ గెలుస్తుంది, కాబట్టి ట్రాఫిక్ ఎప్పటికీ టన్నెల్‌లోకి ప్రవేశించదు.

వైఫల్య విధానం: DNS ఒక అడ్రస్‌కు రిజాల్వ్ అవుతుంది, కానీ దానికి ఎటువంటి రూట్ లేదు

దీనిని డీబగ్ చేయడం కష్టం, ఎందుకంటే ఎక్కడా ఎటువంటి ఎర్రర్ కనిపించదు. పేరు రిజాల్వ్ అవుతుంది, కానీ కనెక్షన్ టైమ్ అవుట్ అవుతుంది.

ఉదాహరణకు db.internal.example.com అనేది మీ ప్రైవేట్ నేమ్‌సర్వర్ ద్వారా 10.0.5.20 కి రిజాల్వ్ అవుతుందని మరియు మీరు 10.0.0.0/24 ని అడ్వర్టైజ్ చేశారని అనుకుందాం. DNS (domain name system) రిజల్యూషన్ మరియు IP రూటింగ్ వేర్వేరు దశలు, వీటిలో ఏదీ ఒకదానిని ఒకటి తనిఖీ చేయవు కాబట్టి, లుకప్ విజయవంతమవుతుంది. ఆ తర్వాత 10.0.5.20 కి పంపిన ప్యాకెట్ tailnet లో ఎటువంటి మ్యాచింగ్ రూట్‌ను కనుగొనలేదు, కాబట్టి అది క్లయింట్ యొక్క డిఫాల్ట్ గేట్‌వే ద్వారా బయటకు వెళ్లి మాయమవుతుంది.

రెండు కమాండ్‌లు ఈ రెండు భాగాలను వేరు చేస్తాయి:

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

ఒకవేళ లుకప్ ఒక అడ్రస్‌ను తిరిగి ఇస్తే, కానీ ip route get అనేది dev tailscale0 తో సమాధానం ఇవ్వకపోతే, పేరు సరిగ్గానే ఉంది కానీ రూట్ లేదు అని అర్థం. ఆ అడ్రస్‌ను కవర్ చేసే ఒక రేంజ్‌ను, అంటే 10.0.0.0/16 ని లేదా రెండవ స్పష్టమైన ప్రిఫిక్స్‌ను అడ్వర్టైజ్ చేయండి, ఆపై కన్సోల్‌లో కొత్త ప్రిఫిక్స్‌ను ఆమోదించండి.

నేమ్‌సర్వర్‌లోనే ఒక మ్యాచింగ్ ట్రాప్ ఉంది. మీరు అడ్మిన్ కన్సోల్‌లో 10.0.0.53 వంటి ప్రైవేట్ అడ్రస్‌ను గ్లోబల్ నేమ్‌సర్వర్‌గా సెట్ చేస్తే, ఆ అడ్రస్ తప్పనిసరిగా ఆమోదించబడిన రూట్ లోపలే ఉండాలి, లేకపోతే మీ పరికరాలు రిజాల్వర్‌ను అస్సలు చేరుకోలేవు. ఎవరూ చేరుకోలేని రిజాల్వర్‌ను పాయింట్ చేస్తూ లోకల్ DNS సర్వర్లను ఓవర్‌రైడ్ చేసే ఆప్షన్‌ను ఆన్ చేస్తే, tailnet లోని ప్రతి పరికరం వెంటనే నేమ్ రిజల్యూషన్‌ను కోల్పోతుంది, అంతకుముందు పనిచేసిన పరికరాలు కూడా ఇందులో ఉంటాయి. ముందుగా రిజాల్వర్‌కు రూట్‌ను అడ్వర్టైజ్ చేసి ఆమోదించండి, ఆ తర్వాత DNS సెట్టింగ్‌ను మార్చండి. టన్నెల్ లోపల DNS సమస్యలు మీకు నిరంతరం ఎదురవుతుంటే, WireGuard టన్నెల్ ద్వారా DNS ఎలా విఫలమవుతుందో వివరించే అంశం, పైన ఉన్న కోఆర్డినేషన్ లేయర్ లేకుండా అదే మెకానిజం గురించి వివరిస్తుంది.

Source NAT మరియు సైట్-టు-సైట్ లింకులు

డిఫాల్ట్‌గా, సబ్‌నెట్ రూటర్ ఫార్వర్డ్ చేయబడిన ప్రతి ప్యాకెట్ యొక్క సోర్స్ అడ్రస్‌ను తన సొంత ప్రైవేట్ అడ్రస్‌కు మారుస్తుంది. దీనినే SNAT (source network address translation) అంటారు. ప్రైవేట్ నెట్‌వర్క్‌లో ఎటువంటి మార్పులు చేయకుండానే రిప్లైలు అందేలా చూడటానికి ఇది ఉపయోగపడుతుంది: 10.0.0.20 వద్ద ఉన్న డేటాబేస్, VPS కు రిప్లై ఇస్తుంది, ఎందుకంటే ఆ డేటాబేస్‌కు VPS ను ఎలా చేరుకోవాలో ఇప్పటికే తెలుసు. దీనివల్ల కలిగే నష్టం ఏమిటంటే, ప్రతి tailnet కనెక్షన్ VPS నుంచే వస్తున్నట్లు డేటాబేస్ భావిస్తుంది, కాబట్టి సోర్స్ ఆధారిత ఫైర్‌వాల్ నియమాలు మరియు యాక్సెస్ లాగ్‌లు ఎటువంటి సమాచారాన్ని అందించవు.

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

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

అప్పుడు ప్రైవేట్ నెట్‌వర్క్‌లోని హోస్ట్‌లకు 100.64.0.0/10 (Tailscale పరికరాలకు కేటాయించే రేంజ్) కి తిరిగి వెళ్లే రూట్ అవసరం, ఇది సబ్‌నెట్ రూటర్‌ను సూచించాలి. ఈ రిటర్న్ రూట్ లేకపోతే, వాటి రిప్లైలు డిఫాల్ట్ గేట్‌వేకి వెళ్లి ఎప్పటికీ చేరవు, దీనివల్ల మొదటి ప్యాకెట్ తర్వాత కనెక్షన్‌లు నిలిచిపోతాయి (hang అవుతాయి). ప్రైవేట్ నెట్‌వర్క్ గేట్‌వేలో స్టాటిక్ రూట్‌ను జోడించండి, లేదా SNAT ను ఆన్‌లోనే ఉంచండి.

సైట్-టు-సైట్ లింక్ అంటే రెండు సబ్‌నెట్ రూటర్లు ఒకేసారి ఇలా చేయడం, ప్రతి ఒక్కటి తన సొంత నెట్‌వర్క్‌ను అడ్వర్టైజ్ చేస్తూ మరొక దానిని అంగీకరిస్తాయి:

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

మరొక రూటర్‌లో దాని సొంత రేంజ్‌తో సరిపోలే కమాండ్‌ను రన్ చేయండి. ఈ రెండు రేంజ్‌లు వేర్వేరుగా ఉండాలి. ssh మరియు ping బాగున్నప్పటికీ పెద్ద ఫైల్ బదిలీలు నిలిచిపోతుంటే, దానికి కారణం MSS (maximum segment size), ఇది TCP ప్యాకెట్ మోసుకెళ్లగల అతిపెద్ద డేటా భాగం. టన్నెల్ యొక్క ఓవర్‌హెడ్ వల్ల ఫార్వర్డ్ చేయబడిన ప్యాకెట్లు మధ్యలో ఉన్న ఏదైనా లింక్ కోసం చాలా పెద్దవిగా మారుతాయి, దీనిని క్లాంపింగ్ (clamping) ద్వారా సరిచేయవచ్చు:

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

ఆ రూల్‌ను iptables-persistent తో సేవ్ చేయండి, లేకపోతే తదుపరి బూట్ సమయంలో అది తొలగిపోతుంది.

నిరంతర నిర్వహణ

ఆగస్టు 2026 నాటికి, Node keys డిఫాల్ట్‌గా 180 రోజుల తర్వాత ఎక్స్‌పైర్ అవుతాయి. సబ్‌నెట్ రౌటర్‌లోని కీ ఎక్స్‌పైర్ అయినప్పుడు, ఆ నోడ్ సైన్ అవుట్ అవుతుంది మరియు అడ్వర్టైజ్ చేసిన మొత్తం నెట్‌వర్క్ పరిధి అందుబాటులోకి రాదు; దీనికి కారణం కాన్ఫిగరేషన్‌లో ఎటువంటి మార్పు ఉండదు. అడ్మిన్ కన్సోల్‌లోని Machines పేజీలో ఈ మెషీన్ కోసం key expiry ని డిసేబుల్ చేయండి, ఆపై మీరు అలా చేసినట్లు ఎక్కడైనా రాసి ఉంచుకోండి.

Tailscale పీర్ల మధ్య నేరుగా కనెక్షన్‌ను ఇష్టపడుతుంది, ఒకవేళ అది సాధ్యం కాకపోతే relay servers ద్వారా కనెక్ట్ అవుతుంది. రిలేలు పనిచేస్తాయి, కానీ అవి latency ని పెంచుతాయి. పబ్లిక్ అడ్రస్ ఉన్న VPS సులభమైన సందర్భం: ఇన్‌బౌండ్ UDP 41641 ను అనుమతించండి, అప్పుడు చాలా పీర్లు నేరుగా కనెక్ట్ అవుతాయి. ఒకవేళ ufw ఫైర్‌వాల్‌ను నిర్వహిస్తుంటే, VPS కు అవసరమైన ufw నియమాలు సింటాక్స్‌ను వివరిస్తాయి.

Access rules మరొక ముఖ్యమైన భాగం. డిఫాల్ట్ tailnet లో మీ ప్రతి పరికరం మరొక పరికరాన్ని చేరుకోగలదు, కాబట్టి ఆమోదించబడిన రూట్ వెంటనే పనిచేస్తుంది. మీరు ఒక ACL పాలసీని రాసిన తర్వాత, రూల్ యొక్క డెస్టినేషన్ వైపు ప్రైవేట్ పరిధిని పేర్కొనాలి, ఎందుకంటే 10.0.0.20 అనేది tailnet అడ్రస్ కాదు మరియు tailnet IPలు లేదా ట్యాగ్‌ల ఆధారంగా రాసిన నియమాలు దీనికి వర్తించవు.

చివరగా, మీరు రన్ చేయని కోఆర్డినేషన్ సర్వర్‌ను ఉపయోగించాలా వద్దా అని నిర్ణయించుకోండి. Tailscale యొక్క కంట్రోల్ ప్లేన్ ఒక హోస్టెడ్ సర్వీస్. మీ కీలు మీ మెషీన్లలోనే ఉంటాయి, కానీ అకౌంట్ మరియు పాలసీ ఫైల్ అక్కడ ఉంటాయి. కంట్రోల్ ప్లేన్ breached అయినప్పుడు లేదా లాగిన్ వివరాలు దొంగిలించబడినప్పుడు ఎవరైనా ఏమి చేయగలరో, మీ ప్రైవేట్ నెట్‌వర్క్‌కు రూట్‌ను అందించే ముందే ఆలోచించాలి. Tailscale యొక్క ట్రస్ట్ మోడల్ ఆ పరిమితి ఎక్కడ ఉందో తెలియజేస్తుంది. ఖర్చు అనేది సాధారణంగా దీనిని వాడకుండా ఆపే కారణం కాదు, ఎందుకంటే ఉచిత ప్లాన్ ఆరుగురు వినియోగదారులకు, వారి స్వంత అపరిమిత పరికరాలకు మద్దతు ఇస్తుంది, అయితే ట్యాగ్ కింద మీరు సెటప్ చేసిన సబ్‌నెట్ రౌటర్, మీ పేరుతో సైన్ ఇన్ అయిన దానికంటే భిన్నంగా లెక్కించబడుతుంది. ఆ పరిమితి దాటిన తర్వాత, బిల్లు మెషీన్ల ఆధారంగా కాకుండా వ్యక్తుల ఆధారంగా ఉంటుంది, కాబట్టి ఉచిత ప్లాన్ ముగిసిన తర్వాత ఒక కుటుంబం లేదా ఐదుగురు సభ్యుల బృందం చెల్లించాల్సిన మొత్తం గురించి మీరు అదనపు అకౌంట్‌ను జోడించే ముందే లెక్కించుకోవడం మంచిది. Headscale, the self hosted Tailscale control server ను రన్ చేయడం ద్వారా దానిని మీ స్వంత VPS లోనే ఉంచుకోవచ్చు, కానీ దీనికి నిర్వహణ బాధ్యత మీదే. ఇదే ఆందోళనకు మరొక పరిష్కారం Tailscale క్లయింట్లను వదిలేయడం, self-hosting the NetBird VPN server ద్వారా కోఆర్డినేషన్ లేయర్ మరియు దాని మెష్ క్లయింట్లను మీరు నియంత్రించే ఒకే మెషీన్‌పై ఉంచుకోవచ్చు. మీరు ఈ మోడల్‌కు మరియు మాన్యువల్ కాన్ఫిగరేషన్‌కు మధ్య ఇంకా నిర్ణయం తీసుకోలేకపోతే, WireGuard మరియు Tailscale మధ్య పోలిక కోఆర్డినేషన్ లేయర్ మీకు ఏమి ఇస్తుంది మరియు దాని ఖర్చు ఏమిటో వివరిస్తుంది.

FAQ

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

Subnet router ప్రైవేట్ అడ్రస్‌ల శ్రేణిని ప్రకటిస్తుంది (advertise చేస్తుంది), దీనివల్ల Tailscale రన్ అవ్వని మెషీన్‌లను కూడా tailnet పరికరాలు చేరుకోగలవు. Exit node తనను తాను మొత్తం ఇంటర్నెట్‌కు మార్గంగా ప్రకటిస్తుంది, కాబట్టి ఒక పరికరం తన ట్రాఫిక్ మొత్తాన్ని ఆ నోడ్ యొక్క పబ్లిక్ అడ్రస్ ద్వారా పంపుతుంది. ఒకే VPS ఈ రెండింటిగా పనిచేయగలదు. ఇవి వేర్వేరు ఫ్లాగ్‌లు, --advertise-routes మరియు --advertise-exit-node, మరియు ప్రతి దానికీ అడ్మిన్ కన్సోల్‌లో ప్రత్యేక అనుమతి అవసరం.

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

మీరు అనుమతిస్తే తప్ప Linux క్లయింట్లు subnet routeలను స్వీకరించవు. క్లయింట్‌పై sudo tailscale set --accept-routes రన్ చేయండి. ఆ తర్వాత ip route show తో కాకుండా, ip route show table 52 తో తనిఖీ చేయండి. Tailscale స్వీకరించిన రూట్‌లను routing table 52 లో ఇన్‌స్టాల్ చేసి, పాలసీ రూల్స్ ద్వారా వాటిని చేరుకుంటుంది, కాబట్టి మెయిన్ టేబుల్‌లో అవి కనిపించవు మరియు పనిచేస్తున్న రూట్ కూడా లేనట్లు అనిపించవచ్చు.

రీబూట్ తర్వాత నా subnet పనిచేయడం ఆగిపోయింది. సమస్య ఏమిటి?

చాలావరకు IP forwarding సమస్య అయి ఉండవచ్చు. sysctl -w తో సెట్ చేసిన విలువ రీబూట్ తర్వాత ఉండదు, కాబట్టి దానిని /etc/sysctl.d/99-tailscale.conf లో రాయండి మరియు sysctl net.ipv4.ip_forward తో నిర్ధారించుకోండి. Forwarding ఆన్‌లో ఉండి, ఆ శ్రేణి ఇంకా అందకపోతే, అడ్మిన్ కన్సోల్‌లో ఆ నోడ్‌ను చూడండి. నోడ్ కీలు డిఫాల్ట్‌గా 180 రోజుల తర్వాత ఎక్స్‌పైర్ అవుతాయి, మరియు ఎక్స్‌పైర్ అయిన subnet router అకౌంట్ సమస్యలా కాకుండా నెట్‌వర్క్ లోపంలా కనిపిస్తుంది.

ఇద్దరు subnet routerలు ఒకే శ్రేణిని ప్రకటించవచ్చా?

ఒకే రకమైన శ్రేణులను ప్రకటించలేరు. వేర్వేరు ప్రిఫిక్స్ పొడవులతో ఉన్న శ్రేణులు ఒకదానిపై ఒకటి ఉన్నా పర్వాలేదు, అప్పుడు అత్యంత నిర్దిష్టమైన (most specific) రూట్ పనిచేస్తుంది. Failover విషయంలో జాగ్రత్త అవసరం: మరింత నిర్దిష్టమైన ప్రిఫిక్స్ ఉన్న రూటర్ ఆఫ్‌లైన్‌లోకి వెళ్ళినప్పుడు, Tailscale విస్తృతమైన రూట్‌కు మారదు, కాబట్టి ఆ ట్రాఫిక్ ఆగిపోతుంది. నిజమైన స్టాండ్‌బై జత కోసం, రెండు రూటర్లు ఒకే నిర్దిష్ట ప్రిఫిక్స్‌లను ప్రకటించేలా చూడండి.

హోస్ట్‌నేమ్ రిజాల్వ్ అవుతోంది కానీ కనెక్షన్ టైమ్ అవుట్ అవుతోంది. ఎందుకు?

DNS రిజల్యూషన్ మరియు రూటింగ్ అనేవి వేర్వేరు దశలు. ఒక పేరు రిజాల్వ్ అయిన అడ్రస్‌కు ఎటువంటి ఆమోదించబడిన రూట్ లేకపోతే, ప్యాకెట్ క్లయింట్ యొక్క డిఫాల్ట్ గేట్‌వే ద్వారా బయటకు వెళ్తుంది. క్లయింట్‌పై ip route get <address> రన్ చేయండి. సమాధానంలో dev tailscale0 లేకపోతే, ఆ అడ్రస్‌ను కవర్ చేసే శ్రేణిని ప్రకటించండి మరియు అడ్మిన్ కన్సోల్‌లో ఆ కొత్త ప్రిఫిక్స్‌ను ఆమోదించండి.