అడ్మిన్ కన్సోల్‌లో ఆమోదం చివరి దశలా కనిపిస్తుంది, కానీ అలా కాదు. మొదట అప్లికేషన్ సమయం మించిపోతుంది, ఆ తర్వాతే రౌటర్ ఆన్‌లైన్‌లో ఉందని, మార్గం ఆమోదించబడిందని తెలుస్తుంది. ఆమోదం పంపిణీ దశ, అనుమతి కాదు మరియు ఫార్వార్డింగ్ హామీ కూడా కాదు. ప్యాకెట్ సబ్‌నెట్ రౌటర్ వెనుక ఉన్న హోస్ట్‌ను చేరుకోవడానికి ముందు నాలుగు దశలు సరిపోలాలి, తదుపరిది విఫలమైనప్పుడు కూడా ప్రతిదీ విజయవంతం కావచ్చు. వాటిని క్రమంగా చేయండి మరియు నిలబడని మొదటి దశలో ఆపండి.

నాలుగు దశలు, ఒక వైఫల్యం

రౌటర్ ప్రిఫిక్స్‌ను ప్రకటిస్తుంది, tailnet ఆ ప్రకటనను ఆమోదిస్తుంది, క్లయింట్ పొందిన మార్గాన్ని అంగీకరిస్తుంది, మరియు యాక్సెస్ విధానం నిర్దిష్ట కనెక్షన్‌ను అనుమతిస్తుంది. ఇవి మూడు వేర్వేరు భాగాలు తీసుకునే నాలుగు ప్రత్యేక నిర్ణయాలు. కాబట్టి ఆమోదించిన మార్గం నెట్‌వర్క్ ఇప్పుడు tailnet రౌటింగ్ పట్టికలో భాగమని మాత్రమే చెబుతుంది.

నాలుగో దశను ఎక్కువగా దాటవేస్తారు, ఎందుకంటే మొదటి మూడు కనిపించే స్థితిని ఉత్పత్తి చేస్తాయి. రౌటర్ స్వంత tailnet చిరునామాను కవర్ చేసే అనుమతి దాని వెనుక ఉన్న ప్రైవేట్ సబ్‌నెట్‌ను స్వయంచాలకంగా కవర్ చేయదు. ఇవి వేర్వేరు గమ్యస్థానాలు, విధానం ప్రతి గమ్యస్థానానికి విడిగా మూల్యాంకనం చేయబడుతుంది.

Linuxలో మూడో దశకు ప్రజలను ఆశ్చర్యపరిచే డిఫాల్ట్ కూడా ఉంది: సబ్‌నెట్ మార్గాలను అంగీకరించడం ఐచ్ఛికం. అనేక GUI క్లయింట్లు ప్రకటించిన మార్గాలను డిఫాల్ట్‌గా అంగీకరిస్తాయి, కాబట్టి మిశ్రమ సమూహంలో ఒక యంత్రం విఫలమైనట్లు కనిపించవచ్చు, మిగిలినవి పనిచేస్తుండగా.

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

క్లయింట్ నడిచే చోటే మార్గాన్ని తనిఖీ చేయండి

రౌటర్‌లో కాదు, విఫలమవుతున్న క్లయింట్ నుండి ప్రారంభించండి. మార్గం ఉందని, క్లయింట్ సెట్టింగ్ మార్గాలను అంగీకరించడానికి అనుమతిస్తుందని నిర్ధారించండి.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linuxలో మార్గాలను అంగీకరించడానికి, ఫ్లాగ్ సెట్ అయిందని ఊహించే బదులు దానితో మళ్లీ కనెక్ట్ అవ్వండి: tailscale up --accept-routes. వేరే ఫ్లాగ్‌లతో చేరిన క్లయింట్ అవి మారే వరకు వాటిని ఉంచుకుంటుంది, కాబట్టి మరొకటి జోడించే ముందు ప్రస్తుత సెట్టింగ్‌ను తనిఖీ చేయండి. మార్పు తర్వాత మొదటి ఆదేశాన్ని మళ్లీ అమలు చేస్తే మార్గం పట్టికలో కనిపించాలి.

ఫార్వార్డింగ్ మరియు తిరిగి వచ్చే మార్గాన్ని నిరూపించండి

ఆమోదం రౌటర్‌ను ప్యాకెట్లను ఫార్వార్డ్ చేయడానికి సెట్ చేయదు, జవాబును ఏర్పాటు చేయదు. రెండూ రౌటర్ LAN వైపు హోస్ట్ స్థాయి విషయాలు. వాటిని క్లయింట్‌లో కాదు, రౌటర్‌లో పరీక్షించండి.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

మాస్కరేడింగ్ నిలిపివేయబడితే, గమ్య నెట్‌వర్క్‌కు tailnet చిరునామాలకు తిరిగి వెళ్లే మార్గం అవసరం, మధ్యలో ఉన్న ప్రతి హాప్ దాన్ని తెలుసుకోవాలి. ఒక సేవ కోసం మాస్కరేడింగ్‌ను తిరిగి ఆన్ చేయడం వేగవంతమైన పరిష్కారం, కానీ గమ్యం నుండి అసలు క్లయింట్ చిరునామా దాచబడే ఖర్చుతో. గమ్యం ఆడిట్ కోసం మూల చిరునామాలను లాగ్ చేసినప్పుడు ఈ మార్పిడి ముఖ్యం, కాబట్టి సంఘటన సమయంలో ఫ్లాగ్ తిప్పడం బదులు ఉద్దేశపూర్వకంగా నిర్ణయించుకోండి. మీరు ఏ ఎంపిక చేసుకున్నారో డాక్యుమెంట్ చేయండి, ఎందుకంటే తదుపరి వ్యక్తి రెండు ప్రవర్తనలలో ఒకటి మాత్రమే చూస్తారు.

వనరు కోసం యాక్సెస్ నియమాన్ని చదవండి

మార్గం ఉన్నప్పుడు మరియు ఫార్వార్డింగ్ నిరూపించబడినప్పుడు, మిగిలిన అనుమానితుడు విధానం. కనెక్షన్‌ను అనుమతించాల్సిన అనుమతిని చదివి దాని గమ్యాన్ని తనిఖీ చేయండి, మూలాన్ని మాత్రమే కాదు. క్లయింట్ స్వంత గుర్తింపు కూడా విధాన ఎంపికదారుతో సరిపోలాలి, కాబట్టి విఫలమవుతున్న అదే యంత్రం నుండి దాన్ని సేకరించండి.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

స్థితి అవుట్‌పుట్ క్లయింట్ స్వంత చిరునామాలను మరియు అది చూసే పీర్‌లను గుర్తిస్తుంది, విధానం మూల-ఎంపికదారు వాటితో సరిపోలాలి. tailscale ping సబ్‌నెట్ రౌటర్ వరకు tailnet మార్గాన్ని నిరూపిస్తుంది; ఇది పీర్ పేర్లు మరియు tailnet చిరునామాలను పరిష్కరిస్తుంది, ప్రకటించిన సబ్‌నెట్ లోపలి హోస్ట్‌లను కాదు. మూడో ఆదేశం సబ్‌నెట్ మార్గం ద్వారా సాధారణ ICMP ప్రతిధ్వనిని పంపుతుంది, కాబట్టి దాని ఫలితం రౌటర్‌ను కాదు, గమ్యాన్ని వివరిస్తుంది. tailnet స్థాయి నిరాకరణ సాధారణంగా నిరాకరణగా తిరిగి వస్తుంది, బయటకు వెళ్లి ఎప్పుడూ తిరిగి రాని ప్యాకెట్ సమయం మించిపోతుంది.

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

లక్ష్యం ప్రైవేట్ సబ్‌నెట్ కాదు, ఇంటర్నెట్ ఎగ్రెస్ అయితే, సరైన భాగం నిష్క్రమణ నోడ్, సబ్‌నెట్ రౌటర్ కాదు, విధానం మరియు రౌటింగ్ తదనుగుణంగా భిన్నంగా ఉంటాయి. అనుమతిని విస్తరించే ముందు ఆ నిర్ణయాన్ని తనిఖీ చేయండి. నిష్క్రమణ నోడ్ డిఫాల్ట్ మార్గాన్ని మారుస్తుంది; సబ్‌నెట్ రౌటర్ ప్రిఫిక్స్‌ను మాత్రమే ప్రకటిస్తుంది.

సంబంధిత వ్యాసాలు