VPS-ல் Tailscale Subnet Router அமைப்பது எப்படி?

Tailscale subnet router-ன் செயல்பாடு

Tailscale subnet router என்பது உங்கள் tailnet-க்கு ஒரு குறிப்பிட்ட private IP முகவரி வரம்பை அறிவிக்கும் ஒரு கருவியாகும். இதனால், Tailscale இயங்காத சாதனங்களைக்கூட tailnet-ல் உள்ள பிற சாதனங்களால் அணுக முடியும். Tailnet என்பது ஒரே கணக்கு அல்லது நிறுவனத்தின் கீழ் இணைக்கப்பட்டுள்ள சாதனங்களைக் கொண்ட உங்கள் தனிப்பட்ட Tailscale பிணையமாகும். மக்கள் பெரும்பாலும் குழப்பமடையும் exit node அம்சம் இதற்கு நேர்மாறான வேலையைச் செய்கிறது. இது ஒரு சாதனத்தின் அனைத்து traffic-ஐயும் VPS வழியாக அனுப்புகிறது, இதனால் அந்தச் சாதனத்தின் பொது இணைய அணுகலுக்கு VPS ஒரு பாதையாக மாறுகிறது.

ஒவ்வொரு வாக்கியமும் ஒரு கருத்தை விளக்குகிறது. ஒரு subnet router, ஒரு private பிணையத்தை tailnet மூலம் அணுகக்கூடியதாக மாற்றுகிறது. ஒரு exit node, உங்கள் பொது இணைய traffic வெளியேறும் இடத்தையே மாற்றுகிறது. உங்களுக்கு exit node தேவைப்பட்டால், how to run a Tailscale exit node on a VPS என்பதைப் படிக்கவும். இவை இரண்டும் தனித்தனி flags ஆகும்; ஒரே VPS-ல் இரண்டையும் ஒரே நேரத்தில் இயக்க முடியும் என்றாலும், அவை வெவ்வேறு சிக்கல்களைத் தீர்க்கின்றன மற்றும் வெவ்வேறு காரணங்களால் செயலிழக்கின்றன.

VPS-க்கு ஒரு subnet router எப்போது தேவைப்படுகிறது

வழக்கமான சூழல் என்பது உங்கள் சேவை வழங்குநர் ஏற்கனவே உங்களுக்கு வழங்கிய ஒரு private network ஆகும். உங்கள் VPS ஒரு public address-ஐயும், private segment-ல் இரண்டாவது interface-ஐயும் கொண்டிருக்கும். அந்த segment-ல் உள்ள பிற server-களுக்கு public address இருக்காது: உதாரணமாக 10.0.0.20-ல் ஒரு database, 10.0.0.30-ல் ஒரு backup target. ஒரு VPS-ல் Tailscale-ஐ நிறுவி, 10.0.0.0/24-ஐ advertise செய்தால், உங்கள் laptop அந்த private address-களை நேரடியாக அணுக முடியும். அந்த segment-ல் வேறு எதுவும் மாறாது, database-க்கு public address இருக்காது.

மற்றொரு சூழல், VPS-க்கு அப்பால் உள்ள ஒரு network ஆகும். ஒரு router-க்கு பின்னால் இருக்கும் home அல்லது office LAN (local area network), அல்லது Tailscale-ஐ இயக்க முடியாத சாதனங்கள் கொண்ட rack (உதாரணமாக, managed switch அல்லது firmware மாற்ற முடியாத பழைய NAS). அந்த network-ல் உள்ள ஒரு Linux கணினி, மற்ற அனைத்து சாதனங்களுக்கும் subnet router-ஆக செயல்படும்.

இரண்டு சூழல்களுக்கும் ஒரு பொதுவான தேவை உள்ளது. Subnet router, தான் advertise செய்யும் range-ஐ தனது சொந்த routing table மற்றும் firewall மூலம் ஏற்கனவே அணுகக்கூடிய நிலையில் இருக்க வேண்டும். Tailscale அந்த இணைப்பை உருவாக்குவதில்லை. அது traffic-ஐ router-க்கு கொண்டு சென்று, அதை forward செய்வதற்கு kernel-இடம் ஒப்படைக்கிறது.

Tailscale-ஐ நிறுவி local route-ஐ முதலில் சரிபார்க்கவும்

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

இந்த script இயங்குதளத்தைக் கண்டறிந்து, Tailscale-ன் package repository-ஐச் சேர்த்து, tailscale command மற்றும் tailscaled daemon-ஐ நிறுவி, பின் அந்தச் சேவையை (service) செயல்படுத்துகிறது. இதை 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 அல்லது இலக்கு host-ல் உள்ள firewall-ல் தான் பிரச்சினை உள்ளது. ஒவ்வொரு அடுத்தகட்ட சோதனையும் இதைச் சார்ந்தே இருப்பதால், முதலில் அதைச் சரிசெய்யவும்.

IP forwarding-ஐ இயக்குதல் மற்றும் reboot-க்கு பிறகும் அதைத் தக்கவைத்தல்

ஒரு Linux machine தனக்கு அனுப்பப்படாத packet-களை forwarding வசதி இயக்கப்பட்டிருந்தால் ஒழிய நிராகரித்துவிடும். பிற machine-களின் packet-களை 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 உடனடியாகச் செயல்படும், ஆனால் அடுத்த boot-ன் போது நீங்கிவிடும். இதனால் subnet router சில வாரங்கள் இயங்கிவிட்டு, kernel upgrade-க்கு பின் நடக்கும் reboot-க்கு மறுநாள் காலையில் நின்றுவிடும். குழப்பமான விஷயம் என்னவென்றால், எதிலும் பிழை இருப்பது போலத் தெரியாது. tailscale status அந்த node online-ல் இருப்பதை இன்னும் காட்டும், admin console-ல் route அங்கீகரிக்கப்பட்டிருப்பதாகத் தெரியும், client-களிலும் route நிறுவப்பட்டிருக்கும். Packet-கள் VPS-க்கு வந்து சேரும், ஆனால் kernel எவ்வித log-உம் இன்றி அவற்றை நிராகரிக்கும். /etc/sysctl.d/99-tailscale.conf-ல் மதிப்புகளை எழுதுவது மட்டுமே reboot-க்கு பிறகு அவற்றை மீண்டும் செயல்பட வைக்கும்.

Forwarding வசதி ஆஃப் செய்யப்பட்டிருக்கும்போது நீங்கள் route-களை advertise செய்தால், tailscale up அந்த நேரத்தில் எச்சரிக்கும். Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.-க்கு நெருக்கமான ஒரு வரியை அது காட்டும். அந்த command-ன் output-ஐத் தாண்டிச் செல்லாமல் கவனமாகப் படிக்கவும்.

Routes-ஐ விளம்பரப்படுத்துதல் (Advertise)

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

ஏற்கனவே உங்கள் tailnet-ல் இணைக்கப்பட்டுள்ள VPS-ல், அமைப்புகளை நேரடியாக மாற்றவும்:

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

பிற்காலத்தில் செய்யும் ஒவ்வொரு மாற்றத்திற்கும் tailscale set-ஐப் பயன்படுத்தவும். ஒரு flag-ஐ மட்டும் வைத்துக்கொண்டு tailscale up-ஐ மீண்டும் இயக்கினால், நீங்கள் குறிப்பிடாத பிற flag-கள் reset ஆகிவிடும். எனவே, default அல்லாத அனைத்து flag-களையும் குறிப்பிட வேண்டும் என்று CLI பிழையைக் காட்டும். tailscale set ஒரு அமைப்பை மட்டும் மாற்றும், மற்றவற்றை அப்படியே விட்டுவிடும்.

பல range-களை இடைவெளி இல்லாமல் கமாவால் பிரித்து ஒரே பட்டியலில் கொடுக்கலாம்: --advertise-routes=10.0.0.0/24,192.168.50.0/24. ஒவ்வொரு பதிவும் CIDR குறியீட்டில் (classless inter-domain routing, 10.0.0.0/24 வடிவம்) ஒரு network address-ஆக இருக்க வேண்டும். தவறுதலாக உங்கள் சொந்த host address-ஐ, அதாவது 10.0.0.5/24 என்று உள்ளிட்டால், prefix-க்கு பின்னால் உள்ள bits பூஜ்ஜியமாக இல்லாததால் அது நிராகரிக்கப்படும்; மேலும், நீங்கள் குறிப்பிட்டிருக்க வேண்டிய சரியான prefix-ஐ அந்தப் பிழைச் செய்தி காட்டும். விளம்பரப்படுத்துவதை நிறுத்த, sudo tailscale set --advertise-routes= மூலம் காலியான பட்டியலை அமைக்கவும்.

Admin console-ல் route-ஐ அங்கீகரித்தல்

ஒரு route-ஐ advertise செய்வது என்பது ஒரு கோரிக்கை மட்டுமே, அது மாற்றமல்ல. ஒரு admin அதை அங்கீகரிக்கும் வரை, எந்த client-க்கும் அந்த route கிடைக்காது, அந்த range-ல் உள்ள எதையும் அணுக முடியாது. இது திட்டமிட்டே செய்யப்பட்டுள்ளது, ஏனெனில் எந்தவொரு machine-ம் தன்னை மற்ற அனைவரின் routing table-லும் சேர்த்துக்கொண்டால், அது தனக்கு விருப்பமான எந்த range-ன் traffic-ஐயும் கைப்பற்ற முடியும்.

Admin console-ன் Machines பக்கத்தில் அதை அங்கீகரிக்கவும். அந்த VPS ஒரு subnet badge-உடன் பட்டியலிடப்பட்டிருக்கும். அதன் row-ஐத் திறந்து, subnets பகுதியைத் தேடி, route settings-ஐ edit செய்து, அந்த route-ஐத் தேர்வு செய்து, save செய்யவும்.

ஒவ்வொரு prefix-க்கும் தனித்தனியாக அங்கீகாரம் தேவை. இன்று 10.0.0.0/24-ஐ advertise செய்து, அடுத்த மாதம் 192.168.50.0/24-ஐச் சேர்த்தால், பழையது தொடர்ந்து செயல்படும், ஆனால் புதிய prefix அங்கீகரிக்கப்படாமல் இருக்கும். VPS-ன் பார்வையில் அங்கீகரிக்கப்பட்ட route-க்கும், புறக்கணிக்கப்பட்ட route-க்கும் எந்த வித்தியாசமும் இருக்காது, எனவே வேறு எதையும் debug செய்வதற்கு முன் console-ஐச் சரிபார்க்கவும்.

Tailnet policy file-ல் autoApprovers block-ஐப் பயன்படுத்தி இந்த manual படியைத் தவிர்க்கலாம்:

{
  "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, இப்போது அந்த route advertise செய்யப்பட்ட உடனேயே அங்கீகரிக்கப்படும். அந்த tag முதலில் அதே policy file-ன் tagOwners பகுதியில் இருக்க வேண்டும். நீங்கள் script மூலம் VPS-ஐ மீண்டும் உருவாக்கினால் (rebuild) இதை அமைப்பது பயனுள்ளது, ஏனெனில் மீண்டும் உருவாக்கப்பட்ட node ஒரு புதிய node-ஆகக் கருதப்படும், அதன் routes மீண்டும் அங்கீகரிக்கப்படாத நிலையிலேயே தொடங்கும்.

Linux clients ஏன் --accept-routes இல்லாமல் route-ஐ புறக்கணிக்கின்றன

Route இப்போது விளம்பரப்படுத்தப்பட்டு (advertised) அங்கீகரிக்கப்பட்டுள்ளது. உங்கள் phone மற்றும் Mac ஆகியவற்றால் 10.0.0.20-ஐ அடைய முடிகிறது. உங்கள் Linux laptop-ஆல் அதை அடைய முடியவில்லை, மேலும் admin console-ல் எந்தப் பிரச்சினையும் இருப்பதாகத் தெரியவில்லை.

Subnet route-ஐ ஏற்றுக்கொள்வது என்பது client-ன் routing table-ல் உள்ளீடுகளை எழுதுவதாகும். Android, iOS, macOS, tvOS மற்றும் Windows ஆகியவற்றில், Tailscale client இதை உங்களுக்காகச் செய்கிறது. Linux-ல் இது அவ்வாறு செய்வதில்லை, ஏனெனில் Linux machine பெரும்பாலும் ஒரு server அல்லது router ஆக இருக்கும். அதன் routing table ஏற்கனவே திட்டமிட்டு கட்டமைக்கப்பட்டிருக்கும். நெட்வொர்க்கிலிருந்து பெறப்பட்ட /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, ஏற்றுக்கொள்ளப்பட்ட route-களை main routing table-ல் சேர்ப்பதில்லை. அது அவற்றை routing table 52-ல் வைத்து, policy rules-ஐ நிறுவுகிறது. இவற்றை ip rule show மூலம் 5210 முதல் 5270 வரையிலான priority range-ல் காணலாம்; இவை பொருந்தாத packets-ஐ அந்த table-க்கு அனுப்புகின்றன. எனவே, ip route show மட்டும் 10.0.0.0/24-ஐ ஒருபோதும் காட்டாது, அந்த command-ஐ மட்டும் சரிபார்க்கும் ஒருவர் --accept-routes எதையும் செய்யவில்லை என்று முடிவெடுப்பார். ip route show table 52 என்பது உண்மையை வெளிப்படுத்தும் command ஆகும், இது tailscale0-ல் விளம்பரப்படுத்தப்பட்ட range-ஐக் காட்ட வேண்டும்.

ஒரு விதிவிலக்கை அறிந்துகொள்வது அவசியம். இந்த Linux node-ஆனது அதன் சொந்த local network-க்கு இரண்டாவது subnet router-ஆக இருந்தால், --accept-routes ஆனது அதன் சொந்த நேரடியாக இணைக்கப்பட்ட subnet-க்கான traffic-ஐ, அதன் சொந்த interface வழியாக அனுப்பாமல் மற்ற router வழியாக அனுப்பச் செய்யும். High availability ஜோடியில் உள்ள standby router-ல், --accept-routes-ஐ off நிலையில் வைத்து, விளம்பரப்படுத்துவதை (advertise) மட்டும் செய்யவும்.

தோல்வி முறை: இரண்டு routers ஒரே மாதிரியான வரம்புகளை விளம்பரப்படுத்துதல்

இரண்டு subnet routers ஒரே மாதிரியான வரம்புகளை விளம்பரப்படுத்தக்கூடாது. வெவ்வேறு prefix நீளங்களைக் கொண்ட மேலெழும் (overlapping) வரம்புகள் அனுமதிக்கப்படும், மேலும் Tailscale மிகவும் துல்லியமான பொருத்தத்தைத் தேர்வு செய்யும். router A ஆனது 10.0.0.0/24-ஐயும், router B ஆனது 10.0.0.0/16-ஐயும் விளம்பரப்படுத்தினால், 10.0.0.20-க்கான traffic A-க்குச் செல்லும்.

A offline நிலைக்குச் செல்லும்போது ஏற்படும் விளைவுதான் பயனர்களை ஆச்சரியப்படுத்துகிறது. Tailscale குறைந்த துல்லியமான route-க்கு மாறாது (fall back). 10.0.0.20-க்கான traffic நின்றுவிடும், அதே சமயம் 10.1.0.20-க்கான traffic B வழியாகத் தொடர்ந்து இயங்கும். இது private network-ன் பாதி பகுதி செயலிழந்தது போன்ற அறிகுறிகளைக் காட்டும், மேலும் ஒரு offline node அதிக துல்லியமான prefix-ஐ வைத்திருப்பதே இதற்குக் காரணம். உங்களுக்கு failover தேவைப்பட்டால், அகலமான router-ஐயும் குறுகிய prefix-களை விளம்பரப்படுத்தச் செய்யுங்கள், அப்போதுதான் இரண்டுமே ஒரே முகவரிகளை உள்ளடக்கும்.

மற்றொரு மேலெழும் சிக்கல் client-க்கு அருகில் நிகழ்கிறது. நீங்கள் 192.168.1.0/24-ல் உள்ள ஒரு hotel network-ல் இருக்கும்போது, உங்கள் subnet router 192.168.1.0/24-ஐ விளம்பரப்படுத்தினால், அந்த இரண்டுமே ஒரே இலக்குகளுக்காகப் போட்டியிடும், இதில் எது வெற்றி பெறும் என்பது அந்த platform-ஐப் பொறுத்தது. Linux-ல், Tailscale-ன் சொந்த rule-க்கு முன்னால் ஒரு rule-ஐ நிறுவவும், இதனால் local முகவரிகள் main table-ஐப் பயன்படுத்தும்:

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

அந்த rule நிலையானது அல்ல, அடுத்த boot-ல் அது நீக்கப்படும். இதற்கான உண்மையான தீர்வு, வெளியில் நீங்கள் சந்திக்க வாய்ப்பில்லாத ஒரு private வரம்பைத் தேர்ந்தெடுப்பதே ஆகும். 192.168.0.0/24 மற்றும் 192.168.1.0/24 ஆகியவை பெரும்பாலான home routers-ல் default-ஆக இருக்கும், எனவே நீங்கள் கவனமாகத் தேர்ந்தெடுத்த 10.0.0.0/8-க்குள் ஏதேனும் ஒன்றைப் பயன்படுத்தவும். இதே மோதல் நீங்கள் கையால் கட்டமைக்கும் ஒரு சாதாரண WireGuard VPN-ஐயும் பாதிக்கிறது, அதே காரணத்திற்காக: அதிக துல்லியமான local route வெற்றி பெறுவதால், traffic tunnel-க்குள் நுழையாது.

தோல்வி முறை: DNS ஒரு முகவரிக்குத் தீர்க்கப்படுகிறது, ஆனால் அதற்கு எந்த வழியும் (route) இல்லை

இதைக் கண்டறிவது கடினம், ஏனெனில் எந்தவொரு கருவியும் பிழையைப் புகாரளிக்காது. பெயர் தீர்க்கப்படுகிறது (resolve), ஆனால் இணைப்பு காலாவதியாகிறது (timeout).

உங்கள் தனிப்பட்ட nameserver மூலம் db.internal.example.com என்பது 10.0.5.20 எனத் தீர்க்கப்படுகிறது என்றும், நீங்கள் 10.0.0.0/24-ஐ விளம்பரப்படுத்தியுள்ளீர்கள் (advertise) என்றும் வைத்துக்கொள்வோம். DNS (domain name system) தீர்மானமும் IP ரூட்டிங்கும் தனித்தனி நிலைகள் என்பதால், ஒன்றையொன்று சரிபார்க்காது; எனவே தேடல் வெற்றி பெறுகிறது. ஆனால் 10.0.5.20-க்கு அனுப்பப்படும் பாக்கெட் tailnet-ல் எந்தப் பொருத்தமான வழியையும் காணவில்லை. எனவே, அது client-ன் default gateway வழியாக வெளியேறி மறைந்துவிடுகிறது.

இரண்டு கட்டளைகள் இந்த இரண்டு பகுதிகளையும் பிரிக்கின்றன:

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

தேடல் ஒரு முகவரியைத் தருகிறது, ஆனால் ip route get ஆனது dev tailscale0 மூலம் பதிலளிக்கவில்லை என்றால், பெயர் சரியாக உள்ளது, ஆனால் வழி (route) விடுபட்டுள்ளது. அந்த முகவரியை உள்ளடக்கிய ஒரு வரம்பை, அதாவது 10.0.0.0/16 அல்லது இரண்டாவது தெளிவான prefix-ஐ விளம்பரப்படுத்துங்கள், பின்னர் console-ல் அந்தப் புதிய prefix-க்கு ஒப்புதல் அளியுங்கள்.

Nameserver-லேயே ஒரு சிக்கல் உள்ளது. நீங்கள் admin console-ல் 10.0.0.53 போன்ற ஒரு தனிப்பட்ட முகவரியை global nameserver-ஆக அமைத்தால், அந்த முகவரி அங்கீகரிக்கப்பட்ட வழித்தடத்திற்குள் இருக்க வேண்டும்; இல்லையெனில் உங்கள் சாதனங்களால் resolver-ஐ அணுக முடியாது. யாரும் அணுக முடியாத ஒரு resolver-ஐக் குறிப்பிட்டுவிட்டு, local DNS servers-ஐ மீறும் (override) விருப்பத்தை இயக்கினால், ஒரு நொடிக்கு முன்பு வேலை செய்த சாதனங்கள் உட்பட, tailnet-ல் உள்ள அனைத்து சாதனங்களும் உடனடியாக பெயர் தீர்மானிக்கும் திறனை இழக்கும். முதலில் resolver-க்கான வழியை விளம்பரப்படுத்தி ஒப்புதல் அளியுங்கள், அதன் பிறகு DNS அமைப்பை மாற்றவும். ஒரு tunnel-க்குள் DNS வேலை செய்வதில் நீங்கள் தொடர்ந்து சிக்கல்களைச் சந்தித்தால், WireGuard tunnel-ல் DNS எவ்வாறு செயலிழக்கிறது என்ற பகுதி, மேலடுக்கில் ஒருங்கிணைப்பு அடுக்கு (coordination layer) இல்லாமலேயே அதே நுட்பத்தை விளக்குகிறது.

Source NAT மற்றும் site-to-site இணைப்புகள்

இயல்பாக, subnet router தான் அனுப்பும் ஒவ்வொரு packet-ன் source address-ஐயும் தனது சொந்த private address-ஆக மாற்றுகிறது. இதுவே SNAT (source network address translation) ஆகும். private network-ல் எந்த மாற்றமும் செய்யாமலேயே பதில்கள் சரியாகக் கிடைப்பதற்காக இது பயன்படுத்தப்படுகிறது: 10.0.0.20-ல் உள்ள database, தனக்கு ஏற்கனவே தெரிந்த VPS-க்கு பதிலளிக்கிறது. இதன் குறைபாடு என்னவென்றால், அனைத்து tailnet இணைப்புகளும் VPS-லிருந்து வருவதாகவே database-க்குத் தெரியும். எனவே, source அடிப்படையிலான firewall விதிகள் மற்றும் access logs மூலம் எந்தத் தகவலையும் அறிய முடியாது.

client-ன் உண்மையான tailnet address மாறாமல் இருக்க, Linux-ல் இதை முடக்கலாம்:

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

இப்போது, private network-ல் உள்ள hosts-க்கு 100.64.0.0/10-க்குத் திரும்பும் வழி (route) தேவை. இது Tailscale சாதனங்களுக்கு ஒதுக்கும் range ஆகும்; இது subnet router-ஐச் சுட்டிக்காட்ட வேண்டும். இந்த return route இல்லையென்றால், பதில்கள் default gateway-க்குச் சென்றுவிடும், இலக்கை அடையாது. இதனால் முதல் packet-க்குப் பிறகு இணைப்புகள் துண்டிக்கப்படும். private network-ன் gateway-ல் static route-ஐச் சேர்க்கவும், அல்லது SNAT-ஐ அப்படியே வைத்திருக்கவும்.

site-to-site இணைப்பு என்பது இரண்டு subnet routers ஒரே நேரத்தில் இதைச் செய்வதாகும். ஒவ்வொன்றும் தனது சொந்த network-ஐ விளம்பரப்படுத்தி (advertise), மற்றொன்றின் network-ஐ ஏற்றுக்கொள்கிறது:

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

மற்றொரு router-ல் அதன் சொந்த range-ஐக் கொண்டு பொருத்தமான கட்டளையை இயக்கவும். இரண்டு range-களும் வெவ்வேறாக இருக்க வேண்டும். ssh மற்றும் ping சரியாக இருந்து, பெரிய கோப்புகளைப் பரிமாறும்போது வேகம் குறைந்தால், அதற்கு MSS (maximum segment size) காரணமாக இருக்கலாம். இது ஒரு TCP packet சுமந்து செல்லும் அதிகபட்ச தரவு அளவு ஆகும். tunnel-ன் overhead காரணமாக, அனுப்பப்படும் packets இடையில் உள்ள ஏதேனும் ஒரு இணைப்பிற்கு மிகப் பெரியதாக இருக்கலாம். இதைச் சரிசெய்ய 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 மூலம் சேமிக்கவும், இல்லையெனில் அடுத்த முறை reboot செய்யும்போது இது நீங்கிவிடும்.

தொடர்ந்து இயங்குவதற்கான பராமரிப்புப் பணிகள்

ஆகஸ்ட் 2026 நிலவரப்படி, Node keys இயல்பாகவே 180 நாட்களுக்குப் பிறகு காலாவதியாகிவிடும். ஒரு subnet router-ல் உள்ள key காலாவதியாகும் போது, அந்த node தானாகவே வெளியேறிவிடும் (sign out). இதனால், எந்தவிதமான configuration மாற்றமும் செய்யப்படாத நிலையிலும், அந்த முழு range-ம் அணுக முடியாததாகிவிடும். Admin console-ல் உள்ள Machines பக்கத்திற்குச் சென்று, இந்த machine-க்கான key expiry-ஐ முடக்கவும் (disable). இதைச் செய்ததை ஒரு குறிப்பேட்டில் குறித்து வைத்துக்கொள்ளவும்.

Tailscale, peers-களுக்கு இடையே நேரடி இணைப்பையே விரும்புகிறது. நேரடி இணைப்பு சாத்தியமில்லாத போது மட்டுமே relay servers-ஐப் பயன்படுத்துகிறது. Relay-கள் வேலை செய்யும், ஆனால் அவை latency-ஐ அதிகரிக்கும். Public address கொண்ட ஒரு VPS எளிதானது: inbound UDP 41641-ஐ அனுமதித்தால், பெரும்பாலான peers நேரடியாக இணைந்துவிடும். ufw மூலம் firewall-ஐ நிர்வகித்தால், ஒரு VPS-க்குத் தேவையான ufw விதிகள் பகுதியில் அதற்கான syntax கொடுக்கப்பட்டுள்ளது.

Access rules என்பது மற்றொரு முக்கிய அம்சம். இயல்பான tailnet-ல், உங்கள் ஒவ்வொரு சாதனமும் மற்றொன்றை அணுக முடியும், எனவே அங்கீகரிக்கப்பட்ட route தானாகவே வேலை செய்யும். நீங்கள் ஒரு ACL policy-ஐ எழுதினால், விதியின் இலக்கு பகுதியில் (destination side) private range-ஐக் குறிப்பிட வேண்டும். ஏனெனில் 10.0.0.20 என்பது tailnet address அல்ல; அது tailnet IP-கள் அல்லது tags-க்கு எதிராக எழுதப்பட்ட விதிகளின் கீழ் வராது.

இறுதியாக, நீங்கள் இயக்காத ஒரு coordination server-ஐப் பயன்படுத்த வேண்டுமா என்பதை முடிவு செய்யுங்கள். Tailscale-ன் control plane ஒரு hosted service ஆகும். உங்கள் keys உங்கள் machine-களிலேயே இருக்கும், ஆனால் account மற்றும் policy file அங்குதான் இருக்கும். Headscale, the self hosted Tailscale control server-ஐ இயக்குவதன் மூலம், அதை உங்கள் சொந்த VPS-லேயே வைத்திருக்கலாம், ஆனால் அதை நீங்களே பராமரிக்க வேண்டும். இதே கவலைக்கு மற்றொரு தீர்வு, Tailscale clients-ஐத் தவிர்த்துவிட்டு, NetBird VPN server-ஐ self-hosting செய்தல் ஆகும். இது coordination layer மற்றும் அதன் சொந்த mesh clients-ஐ நீங்கள் கட்டுப்படுத்தும் ஒரே machine-ல் வைக்கும். இந்த முறைக்கும், நீங்களே கையால் config எழுதும் முறைக்கும் இடையே இன்னும் குழப்பம் இருந்தால், WireGuard மற்றும் Tailscale ஒப்பீடு பகுதி, coordination layer உங்களுக்கு என்ன தருகிறது மற்றும் அதன் விலை என்ன என்பதை விளக்கும்.

FAQ

Subnet router மற்றும் exit node ஆகியவற்றிற்கு இடையே உள்ள வேறுபாடு என்ன?

Subnet router என்பது ஒரு குறிப்பிட்ட private address வரம்பை விளம்பரப்படுத்துகிறது (advertise), இதன் மூலம் Tailscale இயங்காத கணினிகளையும் tailnet சாதனங்களால் அணுக முடியும். Exit node என்பது தன்னை முழு இணையத்திற்கான வழியாக விளம்பரப்படுத்துகிறது; எனவே, ஒரு சாதனம் தனது அனைத்து traffic-ஐயும் அந்த node-ன் public address வழியாக அனுப்புகிறது. ஒரே VPS இரண்டாகவும் செயல்பட முடியும். இவை --advertise-routes மற்றும் --advertise-exit-node என தனித்தனி flags ஆகும், மேலும் ஒவ்வொன்றிற்கும் admin console-ல் தனித்தனியாக அனுமதி வழங்கப்பட வேண்டும்.

எனது Linux client ஏன் விளம்பரப்படுத்தப்பட்ட subnet route-ஐப் புறக்கணிக்கிறது?

நீங்கள் அனுமதிக்கும் வரை Linux clients subnet routes-ஐ ஏற்றுக்கொள்வதில்லை. Client-ல் sudo tailscale set --accept-routes கட்டளையை இயக்கவும். பின்னர் ip route show-க்கு பதிலாக ip route show table 52 மூலம் சரிபார்க்கவும். Tailscale ஏற்றுக்கொள்ளப்பட்ட routes-ஐ routing table 52-ல் நிறுவி, policy rules மூலம் அவற்றை அணுகுகிறது. எனவே, main table-ல் அவை பட்டியலிடப்படாது, சரியான route இருந்தாலும் அது இல்லாதது போலத் தோன்றும்.

Reboot செய்த பிறகு எனது subnet வேலை செய்யவில்லை. என்ன பிரச்சினை?

பெரும்பாலும் IP forwarding காரணமாக இருக்கலாம். sysctl -w மூலம் அமைக்கப்படும் மதிப்பு reboot-க்குப் பிறகு நீடிக்காது. எனவே, அதை /etc/sysctl.d/99-tailscale.conf கோப்பில் எழுதி, sysctl net.ipv4.ip_forward மூலம் உறுதிப்படுத்தவும். Forwarding இயக்கப்பட்டிருந்தும் அந்த வரம்பை அணுக முடியவில்லை என்றால், admin console-ல் அந்த node-ஐப் பார்க்கவும். Node keys இயல்பாக 180 நாட்களுக்குப் பிறகு காலாவதியாகிவிடும்; காலாவதியான subnet router, கணக்குச் சிக்கலாகத் தெரியாமல் network கோளாறாகத் தோன்றும்.

இரண்டு subnet routers ஒரே வரம்பை விளம்பரப்படுத்த முடியுமா?

ஒரே மாதிரியான வரம்புகளை விளம்பரப்படுத்த முடியாது. வெவ்வேறு prefix நீளம் கொண்ட ஒன்றுடன் ஒன்று இணையும் (overlapping) வரம்புகள் அனுமதிக்கப்படும், இதில் மிகவும் துல்லியமான (specific) வரம்பே முன்னுரிமை பெறும். Failover-க்கு கூடுதல் கவனம் தேவை: அதிக துல்லியமான prefix கொண்ட router offline-க்குச் சென்றால், Tailscale தானாகவே அகலமான (wider) route-க்கு மாறாது, இதனால் traffic நின்றுவிடும். உண்மையான standby ஜோடிக்கு, இரண்டு routers-ம் ஒரே துல்லியமான prefix-களை விளம்பரப்படுத்துவதை உறுதி செய்யவும்.

Hostname சரியாகத் தெரிகிறது, ஆனால் connection time out ஆகிறது. ஏன்?

DNS resolution மற்றும் routing ஆகிய இரண்டும் தனித்தனி நிலைகள். ஒரு பெயர், அங்கீகரிக்கப்பட்ட எந்த route-லும் இல்லாத ஒரு address-க்கு resolve ஆகலாம்; அப்போது அந்த packet client-ன் default gateway வழியாக வெளியேறிவிடும். Client-ல் ip route get <address> கட்டளையை இயக்கவும். பதில் dev tailscale0-ஐ உள்ளடக்கவில்லை என்றால், அந்த address-ஐ உள்ளடக்கிய ஒரு வரம்பை விளம்பரப்படுத்தி, admin console-ல் புதிய prefix-க்கு அனுமதி வழங்கவும்.