మీ /64ను విభజించడం IPv6ను VPN క్లయింట్లకు రూట్ చేయదు

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

అపోహ: మీ /64లో కొంత భాగం ఇప్పటికే చేరుకోగలిగినది

కథ ఆకర్షణీయంగా ఉంది: సర్వర్కు పబ్లిక్ /64 ఉంది, దానిని సగానికి కత్తిరించండి, మిగిలిన సగం VPN పూల్కు ఇవ్వండి, ఆ క్లయింట్లు ఇప్పుడు ఇంటర్నెట్లో ఉన్నాయి. ప్రిఫిక్స్ను విభజించడం ఘర్షణలు లేకుండా చిరునామాలను కేటాయిస్తుంది. కానీ ఆ చిరునామాలలో ఒకదానికి ప్యాకెట్ ఎక్కడికి వెళ్లాలో upstream నెట్వర్క్ ఎలా నిర్ణయిస్తుందో అది మార్చదు.

IPv6కు ఆధారపడగల డిఫాల్ట్ అనువాద పొర లేదు, కాబట్టి తిరిగి వెళ్లే మార్గం రూటింగ్గా లేదా లింక్-స్థాయి డెలివరీగా ఉండాలి. క్లయింట్ సొరంగ చిరునామాకు ఉద్దేశించిన ప్యాకెట్ upstream రౌటర్కు చేరుతుంది, ఆ రౌటర్ తన స్వంత పట్టిక నుండి ఫార్వార్డింగ్ నిర్ణయం తీసుకుంటుంది. పట్టిక భౌతిక లింక్కు సూచిస్తే, మీ VPN సర్వర్ ఏమనుకున్నా ప్యాకెట్ అక్కడికే వెళ్తుంది.

ఇదే మొత్తం వైఫల్యం: ముందు దిశ పనిచేస్తుంది ఎందుకంటే మీ సర్వర్ దానిని పంపుతుంది, మరియు తిరుగు దిశ ఒక హాప్ దూరంలో మరణిస్తుంది ఎందుకంటే క్లయింట్ ఉన్నట్లు upstream ఎప్పుడూ తెలుసుకోలేదు.

లింక్పై డెలివరీ నిజంగా ఏమి కోరుతుంది

upstream మొత్తం /64ను భౌతిక లింక్పై ఉన్నట్లు భావించినప్పుడు, ప్రతి గమ్య చిరునామాన్ని పొరుగు ఆవిష్కరణ ద్వారా పరిష్కరిస్తుంది. ఆ లింక్పై అభ్యర్థన పంపి చిరునామా యజమాని సమాధానం ఇస్తారని ఆశిస్తుంది. సొరంగం వెనుక ఉన్న VPN క్లయింట్ ఆ లింక్పై లేదు, సమాధానం ఇవ్వలేడు, కాబట్టి అభ్యర్థన ప్రత్యుత్తరం లేకుండా ఉంటుంది, ప్యాకెట్ పడవేయబడుతుంది.

/65 కత్తిరించడం ఆ ఆశను మార్చదు. క్లయింట్ తరఫున సమాధానం ఇచ్చే మార్గం లేదా ప్రాక్సీ మాత్రమే upstream మనసును మార్చగలదు కాబట్టి, అది ఇప్పటికీ ఆ పరిధిని లింక్పై ఉన్నట్లే భావిస్తుంది. మీరు VPN కాన్ఫిగరేషన్ను సవరించినందున రెండూ కనిపించవు. ఈ అంతరమే పూల్ తన క్లయింట్ల మధ్య పరిపూర్ణంగా పనిచేసి కూడా మరెక్కడి నుండైనా చేరుకోలేకపోవడానికి కారణం.

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

రూట్ చేసిన డెలివరీ ఏమి కోరుతుంది

స్వచ్ఛమైన రూపకల్పన అనేది upstream నిజంగా మీ గేట్వేకు రూట్ చేసే కేటాయింపు. అది అప్పగించిన ప్రిఫిక్స్ లేదా చిన్న బ్లాక్కు స్థిర మార్గం కావచ్చు, మరియు రెండు సందర్భాలలోనూ అవసరం ఒకటే: upstream పట్టిక క్లయింట్ పరిధి కోసం మీ సర్వర్ను సూచించాలి. అప్పుడు తిరుగు ట్రాఫిక్ గేట్వేకు చేరుతుంది, గేట్వే దానిని సొరంగంలోకి పంపుతుంది.

రూట్ చేసిన డెలివరీ పొరుగు ఆవిష్కరణ ప్రశ్నను పూర్తిగా తొలగిస్తుంది, అందుకే ఏదైనా తెలివైనది నిర్మించే ముందు సేవా ప్రదాతను అడగడం విలువైనది. మార్గాన్ని లిఖితపూర్వకంగా అడగండి, తదుపరి హాప్ upstream నిజంగా చేరుకోగల చిరునామా అని నిర్ధారించండి.

రెండు రూపకల్పనలకూ ఇంకా గేట్వేపై IPv6 ఫార్వార్డింగ్ ప్రారంభించబడి ఉండాలి మరియు రెండు దిశలలో ఫార్వార్డ్ అయిన ప్రవాహాన్ని అనుమతించే ఫైర్వాల్ నియమాలు అవసరం. మిగిలిన మార్గానికి డెలివరీ ఒక పూర్వషరతు, ప్రత్యామ్నాయం కాదు. ఫార్వార్డింగ్ ఆఫ్ చేసి ఉన్న పనిచేసే మార్గం, మార్గం లేనట్లే అదే నిశ్శబ్దాన్ని ఉత్పత్తి చేస్తుంది, కాబట్టి ఏదైనా పునఃరూపకల్పన చేయడానికి ముందు రెండింటినీ తనిఖీ చేయండి.

సరిచేయవలసిన రెండు స్వతంత్ర మార్గాలు

పూల్ ప్రిఫిక్స్ మరియు క్లయింట్ స్వంత డిఫాల్ట్ మార్గం వేర్వేరు సెట్టింగ్లు, వాటిని కలిపేయడం విరిగిన సొరంగంలా కనిపించే పాక్షిక కనెక్టివిటీని ఉత్పత్తి చేస్తుంది. పూల్ సర్వర్కు ఏ చిరునామాలు ఇవ్వాలో చెబుతుంది. క్లయింట్ మార్గాలు క్లయింట్ ఏ గమ్యాలకు ట్రాఫిక్ను సొరంగంలోకి పంపుతుందో నిర్ణయిస్తాయి.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

పైన ఉన్న ప్రిఫిక్స్ డాక్యుమెంటేషన్ స్థలం, మరియు రీడైరెక్ట్ IPv6కు మాత్రమే వర్తిస్తుంది, IPv6 డెలివరీ ఇంకా సరిచేయబడుతున్నప్పుడు డ్యూయల్-స్టాక్ విస్తరణ తరచుగా కోరుకునేది అదే. IPv4 రీడైరెక్ట్ IPv6 కవరేజీని స్థాపించదు, ఏ సెట్టింగ్ మరొకదాన్ని సూచించదు.

మీరు వర్తించే ఏ విధానం కిందైనా IPv6 ఆధారపడే నియంత్రణ ట్రాఫిక్ను నడుస్తూ ఉంచండి. Packet Too Big సందేశాలు TCP మరియు UDP మాత్రమే అనుమతించే ఫైర్వాల్కు సాంప్రదాయ బలి, వాటిని పడవేయడం స్థాపించబడి తర్వాత పెద్ద బదిలీలలో నిలిచిపోయే కనెక్షన్లను ఉత్పత్తి చేస్తుంది.

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

పునర్నిర్మాణం దానిని పునరుత్పత్తి చేసేలా రూపకల్పనను నమోదు చేయండి

మూడు వస్తువులను విడివిడిగా రాయండి: క్లయింట్ కేటాయింపు, క్లయింట్ గమ్య మార్గం, మరియు కేటాయింపు కోసం upstream డెలివరీ పద్ధతి. మూడూ ఉన్న పాఠకుడు విస్తరణను తిరిగి నిర్మించగలడు; పూల్ సెట్టింగ్ మాత్రమే ఉన్న పాఠకుడు అసలు బగ్ను పునరుత్పత్తి చేస్తాడు.

తర్వాత తిరుగు దిశను స్పష్టంగా పరీక్షించండి, బయటి నుండి తిరిగి రావలసిన ప్యాకెట్తో. openvpn(8) మాన్యువల్ server-ipv6 మరియు redirect ఎంపికలను కవర్ చేస్తుంది, మరియు మీ సేవా ప్రదాత రూటింగ్ నిర్ధారణ మాన్యువల్ కవర్ చేయలేని సగాన్ని కవర్ చేస్తుంది.