Tailscale subnet router-ஐ VPS-ல் அமைப்பது எப்படி?

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

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

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

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

பொதுவாக, உங்கள் service provider ஏற்கனவே வழங்கிய 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-ம் தேவையில்லை. அந்த segment-லிருந்து ஒரு குறிப்பிட்ட port-ல் உள்ள ஒரு web app மட்டும் தேவைப்பட்டால், முழு range-ஐயும் advertise செய்வது அவசியமற்றது; அதற்கு Tailscale serve அந்த ஒரு port-ல் மட்டும் HTTPS-ஐ அமைக்கும். இதே தர்க்கம் localhost-ல் மட்டும் இயங்கும் daemon-களுக்கும் பொருந்தும், உதாரணமாக systemd-ன் கீழ் இயங்கும் dsh; இதில் அந்த VPS-ன் tailnet address, நீங்கள் UI-ஐ அணுக பயன்படுத்தும் SSH tunnel-க்கு மாற்றாக அமையும்.

மற்றொரு சூழல், VPS-க்கு அப்பால் உள்ள network ஆகும். ஒரு router-க்கு பின்னால் உள்ள வீடு அல்லது அலுவலக LAN (local area network), அல்லது Tailscale-ஐ இயக்க முடியாத managed switch அல்லது firmware பூட்டப்பட்ட பழைய NAS போன்ற சாதனங்கள் இதில் அடங்கும். அந்த network-ல் உள்ள ஒரு Linux கணினி, மற்ற அனைத்து சாதனங்களுக்கும் subnet router-ஆக செயல்படும். வீட்டில், அந்த கணினி பெரும்பாலும் நீங்கள் ஏற்கனவே இயக்கும் hypervisor-ல் உள்ள ஒரு சிறிய VM-ஆக இருக்கும். வீட்டில் உள்ள Proxmox host-ன் செலவு மற்றும் வாடகைக்கு எடுக்கப்பட்ட VPS-ன் செலவு ஆகியவற்றை ஒப்பிட்டு, உங்கள் services-ஐ எங்கு வைக்க வேண்டும் என்பதை முடிவு செய்ய வேண்டும்.

இரண்டு சூழல்களுக்கும் ஒரு பொதுவான தேவை உள்ளது. 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 கட்டளையையும் tailscaled daemon-ஐயும் நிறுவி, அந்தச் சேவையைச் செயல்படுத்துகிறது. இதை systemctl is-active tailscaled மூலம் உறுதிப்படுத்தவும்; இது active என்று காட்ட வேண்டும்.

வேறெதையும் செய்வதற்கு முன், நீங்கள் advertise செய்யத் திட்டமிட்டுள்ள network-ஐ அந்த 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 போன்ற ஏதேனும் ஒரு real interface-ல் private range-ஐப் பட்டியலிட வேண்டும். இந்த 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) விளம்பரப்படுத்துதல்

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-ஐ மீண்டும் இயக்கினால், நீங்கள் குறிப்பிடாத பிற flags அனைத்தும் reset ஆகிவிடும். எனவே, அனைத்து non-default flags-களையும் குறிப்பிட வேண்டும் என்று CLI பிழையைத் தெரிவிக்கும். tailscale set ஒரு அமைப்பை மட்டும் மாற்றிவிட்டு, மற்றவற்றை அப்படியே வைத்திருக்கும்.

பல IP ranges-களை இடைவெளி இல்லாமல் கமாவால் பிரித்து ஒரே பட்டியலில் வழங்கலாம்: --advertise-routes=10.0.0.0/24,192.168.50.0/24. ஒவ்வொரு பதிவும் CIDR குறியீட்டில் (classless inter-domain routing, அதாவது 10.0.0.0/24 வடிவம்) ஒரு network முகவரியாக இருக்க வேண்டும். தவறுதலாக உங்கள் சொந்த host முகவரியை 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-ஐத் தேர்வு செய்து (tick), சேமிக்கவும்.

ஒவ்வொரு prefix-க்கும் தனித்தனியாக அங்கீகாரம் தேவை. இன்று 10.0.0.0/24-ஐ advertise செய்து, அடுத்த மாதம் 192.168.50.0/24-ஐ advertise செய்தால், புதிய prefix அங்கீகரிக்கப்படாமல் இருக்கும், அதே சமயம் பழையது தொடர்ந்து செயல்படும். அங்கீகரிக்கப்பட்ட route மற்றும் புறக்கணிக்கப்பட்ட route ஆகிய இரண்டும் VPS-லிருந்து பார்க்கும்போது ஒரே மாதிரியாகவே இருக்கும், எனவே வேறு எதையும் 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 இப்போது விளம்பரப்படுத்தப்பட்டு அங்கீகரிக்கப்பட்டுள்ளது. உங்கள் போன் மற்றும் 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 விதிகளை நிறுவுகிறது. இவை 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-ல் விளம்பரப்படுத்தப்பட்ட வரம்பைக் காட்ட வேண்டும்.

ஒரு விதிவிலக்கை அறிந்துகொள்வது அவசியம். இந்த 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-க்கு மாறாது. 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-ன் சொந்த விதிக்கு முன்னால் ஒரு விதியை நிறுவுவதன் மூலம் local முகவரிகள் main table-ஐப் பயன்படுத்தும்:

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

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

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

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

உங்கள் தனிப்பட்ட nameserver மூலம் db.internal.example.com என்பது 10.0.5.20 எனத் தீர்க்கப்படுகிறது என்றும், நீங்கள் 10.0.0.0/24-ஐ விளம்பரப்படுத்தியுள்ளீர்கள் (advertised) என்றும் வைத்துக்கொள்வோம். 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-ஐக் கொண்டு பதிலளிக்கவில்லை என்றால், பெயர் சரியாக உள்ளது, ஆனால் வழித்தடம் விடுபட்டுள்ளது என்று அர்த்தம். அந்த முகவரியை உள்ளடக்கிய ஒரு வரம்பை (range), அதாவது 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, Tailscale சாதனங்களுக்கு ஒதுக்கும் 100.64.0.0/10 என்ற range-க்குத் திரும்பும் வழியை (route) 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-ஐ முடக்கவும், பின்னர் அதைச் செய்ததை குறித்து வைத்துக்கொள்ளவும்.

Tailscale, peers-களுக்கு இடையே நேரடி இணைப்பையே விரும்புகிறது; நேரடி இணைப்பு கிடைக்காதபோது மட்டுமே அதன் relay servers-ஐப் பயன்படுத்துகிறது. Relays சிறப்பாகச் செயல்படும், ஆனால் அவை 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 முகவரி அல்ல, அது tailnet IP-கள் அல்லது tags-க்கு எதிராக எழுதப்பட்ட விதிகளால் பாதுகாக்கப்படாது.

இறுதியாக, நீங்கள் இயக்காத ஒரு coordination server-ஐப் பயன்படுத்த வேண்டுமா என்பதை முடிவு செய்யுங்கள். Tailscale-ன் control plane ஒரு hosted service ஆகும். உங்கள் keys உங்கள் machine-களிலேயே இருக்கும், ஆனால் account மற்றும் policy file அங்குதான் இருக்கும். ஒரு compromised control plane அல்லது திருடப்பட்ட identity login மூலம் ஒருவர் என்ன செய்ய முடியும் என்பது, உங்கள் private network-க்குள் ஒரு route-ஐ அனுமதிக்கும் முன்பே நீங்கள் தெளிவுபடுத்த வேண்டிய விஷயம். Tailscale-ன் நம்பிக்கை மாதிரி (trust model) அந்த எல்லை எங்குள்ளது என்பதை வரையறுக்கிறது. இலவசத் திட்டம் ஆறு பயனர்கள் வரை, அவர்கள் சொந்தமாக வைத்திருக்கும் வரம்பற்ற சாதனங்களை அனுமதிக்கிறது என்பதால், செலவு காரணமாக மக்கள் இதிலிருந்து வெளியேறுவது அரிது. இருப்பினும், ஒரு tag-ன் கீழ் நீங்கள் கொண்டுவரும் subnet router, நீங்கள் sign in செய்த கணக்கிலிருந்து மாறுபட்டதாகக் கருதப்படும். அந்த நிலையைத் தாண்டிய பிறகு, கட்டணம் machine-களை விட நபர்களை அடிப்படையாகக் கொண்டே கணக்கிடப்படும். எனவே, இலவசத் திட்டம் முடிந்த பிறகு ஒரு குடும்பம் அல்லது ஐந்து பேர் கொண்ட குழு உண்மையில் எவ்வளவு செலுத்த வேண்டும் என்பதை, நீங்கள் கூடுதல் account-ஐச் சேர்ப்பதற்கு முன்பே கணக்கிடுவது நல்லது. Headscale, the self hosted Tailscale control server-ஐ இயக்குவது, அதை உங்கள் சொந்த VPS-லேயே வைத்திருக்க உதவும், ஆனால் அதை நீங்களே பராமரிக்க வேண்டும். இதே கவலைக்கு மற்றொரு தீர்வு, Tailscale clients-ஐத் தவிர்த்துவிட்டு, NetBird VPN server-ஐ நீங்களே host செய்வது ஆகும்; இது coordination layer மற்றும் அதன் mesh clients-ஐ நீங்கள் கட்டுப்படுத்தும் ஒரு machine-ல் வைக்கிறது. இந்த மாதிரிக்கும், கையால் எழுதப்பட்ட configuration-க்கும் இடையே நீங்கள் இன்னும் முடிவெடுக்கவில்லை என்றால், 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 தானாகவே அகலமான 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-க்கு அனுமதி வழங்கவும்.