VPN పై IPv6 link-local పని చేయడం లేదు: fe80 లింక్ వద్ద ఎందుకు ఆగుతుంది
fe80:: చిరునామాకు ఒకే లింక్పై మాత్రమే అర్థం ఉంటుంది. రూటెడ్ VPN దాన్ని ఎందుకు మోయలేదు, వైఫల్యం ఎలా కనిపిస్తుంది, బదులుగా ఏ చిరునామా వాడాలో చూడండి.
మీరు టన్నెల్ పైకి లేపి, టన్నెల్ను మూల ఇంటర్ఫేస్గా ఉపయోగించి fe80::1కి ping చేస్తారు, ఏదీ తిరిగి రాదు. ఇది మీరు మరచిన firewall నియమం కాదు. Link-local చిరునామాకు అది ఏర్పడిన ఆ ఒకే లింక్పై మాత్రమే అర్థం ఉంటుంది, రూటెడ్ VPN ఆ లింక్ కాదు. దూరపు రౌటర్ fe80::1 దూరపు LAN విభాగంలో ఉంటుంది; మీరు మరో విభాగంలో ఒక హాప్ దూరంలో ఉన్నారు, IPv6లో రౌటర్ link-local ప్యాకెట్లను ముందుకు పంపే ఎటువంటి యంత్రాంగమూ లేదు.
fe80 ఉపసర్గ పరిధిని వివరిస్తుంది, శ్రేణిని కాదు
Link-local unicast అంటే fe80::/10, నిర్వచించే లక్షణం సంఖ్య కాదు, పరిధి. చిరునామా ఒక లింక్పై మాత్రమే చెల్లుతుంది, ప్రతి ఇంటర్ఫేస్ తన గుర్తింపు నుండి ఒకటి ఏర్పరుస్తుంది, అందుకే రెండు సంబంధం లేని నెట్వర్క్లలోని రెండు సంబంధం లేని మెషీన్లు ఎలాంటి ఘర్షణ లేకుండా రెండూ fe80::1కి సమాధానం చెప్పగలవు. ఉపసర్గ ప్రాథమికంగా “ఏదో ఒక లింక్పై” అని చెబుతుంది; లింక్ స్వయంగా సందర్భం నుండి వస్తుంది.
ఒక హోస్ట్పై ఆ సందర్భం శాతం గుర్తు తర్వాత జోడించే జోన్, అంటే scope ID: Linuxలో fe80::1%eth0, Windowsలో మరియు ఇంటర్ఫేస్ సూచికలను చూపే సాధనాలలో fe80::1%3 లేదా fe80::1%12. కెర్నల్ చిరునామాను ఇంటర్ఫేస్ సూచికతో పాటు పరిష్కరించి ఆపై పంపుతుంది. జోన్ తీసివేస్తే గమ్యం అస్పష్టమవుతుంది, కాబట్టి స్టాక్కు విభాగాన్ని ఎంచుకోవడానికి మార్గం లేదు.
రూటెడ్ టన్నెల్ దాన్ని ఎందుకు చేరవేయలేదు
రూటెడ్ VPN అనేది తన సొంత చిరునామాలను మోసే పాయింట్-టు-పాయింట్ ఇంటర్ఫేస్, సాధారణంగా టన్నెల్ లోపల unique-local లేదా ప్రైవేట్ IPv6 స్థలం /64. దూరపు LAN వేరే లింక్, టన్నెల్ చివర మీ తరఫున రూటింగ్ మరియు ఫార్వార్డింగ్ చేయడం ద్వారా దాన్ని చేరుతుంది. ఇవి రెండు వేర్వేరు విభాగాలు, కాబట్టి ఒకదాని చిరునామా మరొకదానిపై చెల్లుబాటు అయ్యే గమ్యం కాదు.
ఫార్వార్డింగ్ నియమం ప్రమాణంలో స్పష్టంగా ఉంది, ఇది మీ క్లయింట్ విచిత్రత కాదు: రౌటర్లు link-local మూలం లేదా గమ్యం ఉన్న ప్యాకెట్లను ముందుకు పంపవు. అందుకే రూట్ పట్టిక సరిగ్గా కనిపించినా ప్యాకెట్ చనిపోతుంది. fe80::/64 కోసం టన్నెల్ వైపు రూట్ జోడిస్తే, ప్రమాణాన్ని పాటించే స్టాక్ దాన్ని తిరస్కరిస్తుంది లేదా అంగీకరించి సరిపోలే ప్రతి ప్యాకెట్ను వదిలేస్తుంది: గమ్యం పరిధి “ఈ లింక్ మాత్రమే” అని చెబుతుంది, బయటకు వెళ్లే ఇంటర్ఫేస్ ఆ లింక్ కాదు.
పొరుగు అన్వేషణ అదే సరిహద్దును బలపరుస్తుంది. హోస్ట్లు link-local తదుపరి హాప్లను 255 హాప్ పరిమితితో లింక్ పరిధి multicastకి పంపే పొరుగు అభ్యర్థన ద్వారా పరిష్కరిస్తాయి, కాబట్టి రౌటర్లు ముందుకు పంపిన ఏదైనా తిరస్కరించగలవు. దీన్ని టన్నెల్ మీదుగా పని చేయించడం అంటే దూరపు విభాగానికి అన్వేషణను ప్రాక్సీ చేయడం, అది వేరే టోపీ పెట్టుకున్న Layer 2 వంతెన.
రెండవ, మరింత నిశ్శబ్ద వైఫల్యం ఉంది, అది రూట్ను బలవంతంగా విధించడానికి ప్రయత్నించేవారిని పట్టుకుంటుంది: జోన్. మీరు స్థానికంగా టైప్ చేసే ఏ జోన్ అయినా టన్నెల్ ఇంటర్ఫేస్కు పేరు పెడుతుంది, మీకు కావాల్సిన చిరునామా దూరపు LAN ఇంటర్ఫేస్కు కట్టుబడి ఉంటుంది. రెండూ ఎప్పుడూ సరిపోలవు, కాబట్టి ప్యాకెట్ను దూరపు చివరలో సరైన ఇంటర్ఫేస్కు మళ్లించలేము.
ఆచరణలో వైఫల్యం ఎలా కనిపిస్తుంది
పరిధి పొరపాటు కోసం సాధనం అవుట్పుట్ రూటింగ్ లేదా firewall లోపంగా చదవబడుతుంది, అందుకే ప్రజలు తప్పు పొరలో సగం రోజు గడుపుతారు.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
మూడవ వరుస ఎక్కువ సమయాన్ని వృథా చేస్తుంది, ఎందుకంటే అవుట్పుట్ లేని ssh క్లయింట్ వినిపిస్తున్న సేవ సమస్యలా కనిపిస్తుంది. లోపలికి వెళ్లే ఏదైనా మార్గం ఉంటే, దూరపు వైపు తనిఖీ చేసి sshd అన్ని చిరునామాలకు కట్టుబడి ఉందా లేక ఒకటికి మాత్రమేనా అని నిర్ధారించండి.
రూట్ కావడానికే తయారైన చిరునామాను ఉపయోగించండి
టన్నెల్ ద్వారా చేరుకోవాల్సిన ప్రతిదానికీ, సేవకు అదే ఉద్దేశ్యం కోసం ఇచ్చిన చిరునామాను ఉపయోగించండి: ప్రపంచ unicast చిరునామా, లేదా fc00::/7 నుండి unique-local చిరునామా, సరిగ్గా ఈ అంతర్గత సందర్భం కోసం కేటాయించిన శ్రేణి. వినేవాడు దాన్ని నిజంగా కట్టుబడి ఉన్నాడా అని నిర్ధారించి, తిరిగి వచ్చే మార్గం మరియు హోస్ట్లోని ఏదైనా firewall నియమాన్ని తనిఖీ చేయండి.
ఊహించడం బదులు దూరపు హోస్ట్ను చూడండి. ip -6 addr show ఉన్న చిరునామాలను జాబితా చేస్తుంది, ss -6 -ltn డెమన్ ఏది వినిపిస్తోందో జాబితా చేస్తుంది. fe80::కి మాత్రమే కట్టుబడిన సేవ తన విభాగం నుండి మాత్రమే చేరుకోగలదు, అది సాధారణంగా ఎవరూ ఉద్దేశపూర్వకంగా ఎంచుకోని డిఫాల్ట్ మరియు నిర్వాహకుడి అంగీకారంతో మార్చవచ్చు.
సేవను నిజంగా మళ్లీ కట్టలేకపోతే, వంతెనను నెట్వర్క్ పొరకు బదులు అప్లికేషన్ పొరకు పైకి ఎత్తండి. దూరపు హోస్ట్పై రూట్ చేయగల చిరునామాపై విని link-localకు కలిపే రిలే ఏ విభాగాన్ని విస్తరించకుండా సమస్యను పరిష్కరిస్తుంది:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80ఇక్కడ జోన్ సరైన వైపున ఉంది, ఆ లింక్పై నిజంగా eth0 ఉన్న హోస్ట్లో. మీ క్లయింట్ fd00:1:2::10తో మాట్లాడుతుంది, అది సాధారణంగా రూట్ అవుతుంది, రిలే link-local హాప్ను స్థానికంగా చేస్తుంది. అదే ఉపాయం ఒక పరికరం యొక్క వెబ్ UI లేదా link-local చిరునామాను మాత్రమే ప్రకటించే పాత BMCకి కూడా పని చేస్తుంది.
వంతెన నిజంగా సమాధానం అయినప్పుడు, మరియు ఏమి తనిఖీ చేయాలి
కొన్ని అమరికలకు నిజంగా ఒక భాగస్వామ్య విభాగం అవసరం: link-local అన్వేషణ మాత్రమే మాట్లాడే పరికరం, multicastపై ఆధారపడే పరికరం, చదునైన LANను పునఃసృష్టించే ప్రయోగశాల. ఇది Layer 2 సమస్య మరియు దానికి Layer 2 సమాధానం కావాలి, ఉదాహరణకు దూరపు ఇంటర్ఫేస్కు వంతెన చేసిన tap పరికరం లేదా స్పష్టమైన బ్రిడ్జ్ మోడ్ ఉన్న క్లయింట్ ఉత్పత్తి. దీనికి టన్నెల్ దాటే broadcast మరియు multicast ట్రాఫిక్ మరియు చివర నుండి చివర వరకు పని చేయాల్సిన పొరుగు అన్వేషణ ఖర్చవుతుంది.
రూటెడ్ ప్రొఫైల్కు fe80::/64 జోడించి దీన్ని సమీపించవద్దు. అది చెత్త స్థితిని సృష్టిస్తుంది: కాన్ఫిగరేషన్ పూర్తయినట్టు కనిపిస్తుంది, రూట్ పట్టిక ఒక ఎంట్రీని చూపుతుంది, ప్రతి ప్యాకెట్ ఇప్పటికీ రెండూ సరిగ్గా ప్రవర్తిస్తున్న రెండు స్టాక్ల మధ్య ఎక్కడో విసిరివేయబడుతుంది.
ping బదులు ఇంటర్ఫేస్తో నిర్ధారించండి. ip -6 addr show tun0 టన్నెల్ లింక్ తన సొంత link-local చిరునామాను ఏర్పరిచిందా అని చెబుతుంది, ip -6 route get fe80::1%tun0 పరిధి ఉన్న గమ్యంతో కెర్నల్ నిజంగా ఏమి చేస్తుందో చెబుతుంది. ఆ ఇంటర్ఫేస్పై గమ్యాన్ని చేరుకోలేమని కెర్నల్ చెబితే, ఏ టన్నెల్ సెట్టింగ్ దాన్ని మార్చదు, ప్రొఫైల్ సవరణ ఆపే సమయం వచ్చింది.
ప్రశ్నను తీర్చే చిన్న క్రమం:
- దూరపు హోస్ట్పై చిరునామాను చదివి అది fe80:: కాదా లేక రూట్ చేయగల ఉపసర్గా గమనించండి.
- అది fe80:: అయితే, సేవను మళ్లీ కట్టండి, ఆ హోస్ట్పై రిలే చేయండి, లేదా విభాగాన్ని వంతెన చేయండి; రూట్ చేయగలది అయితే, రూట్, firewall లేదా బైండ్ చిరునామాను సరిచేయండి.
- మళ్లీ పరీక్షించిన ప్రతిసారీ జోన్ను మళ్లీ తనిఖీ చేయండి, ఎందుకంటే కాపీ చేసిన ఆదేశం సాధారణంగా తప్పు ఇంటర్ఫేస్ను ఉంచుతుంది.
మూలాలు: RFC 4291, IPv6 చిరునామా నిర్మాణం.