Pi లోని హాట్స్పాట్ క్లయింట్లు TUN VPN ద్వారా ఇంటి LAN ను చేరుకోలేరు

స్థానిక Wi-Fi మరియు Ethernet క్లయింట్లు Pi యొక్క హాట్స్పాట్కు కనెక్ట్ అవుతాయి, దాని DHCP పరిధి నుండి చిరునామా తీసుకొని, ఫిర్యాదు లేకుండా ఇంటర్నెట్ పేజీలను లోడ్ చేస్తాయి. తర్వాత అదే క్లయింట్లు ఇంటి LAN లో ఫైల్ భాగస్వామ్యం లేదా వెబ్ ఇంటర్ఫేస్ తెరిచినప్పుడు సమయం ముగుస్తుంది, అయితే Pi స్వయంగా సొరంగం ద్వారా ఆ LAN ను చేరుకుంటుంది. వైర్లెస్ పొరలో ఏదీ పగలలేదు. లోపించినది రూట్ చేయబడిన ఒప్పందం: హాట్స్పాట్ ప్రిఫిక్స్ TUN ఇంటర్ఫేస్లోకి తీసుకెళ్లాలి, మరియు ఇంటి వైపు ఏదో ప్రతిస్పందనలను అక్కడికి ఎలా తిరిగి పంపాలో తెలిసి ఉండాలి. ఒక ప్యాకెట్ ప్రయాణాన్ని పూర్తి చేయడానికి ముందు రెండు భాగాలు ఉండాలి.

మూడు వేర్వేరు పనులతో మూడు కనెక్షన్లు

Linux Ethernet వంతెన గమ్యస్థాన MAC చిరునామా ప్రకారం ఫ్రేమ్లను పంపుతుంది. OpenVPN TUN మోడ్లో IP ప్యాకెట్లను మోసుకెళ్తుంది మరియు MAC పొర అసలే లేదు, కాబట్టి స్థానిక వంతెన జోడించడం సొరంగాన్ని ఎప్పుడూ పోర్టుగా నమోదు చేయదు. కర్నెల్ TUN/TAP పత్రాలు ఆ విభజనను వివరిస్తాయి: TAP పరికరం Ethernet ఇంటర్ఫేస్ లాగా కనిపిస్తుంది, TUN పరికరం అలా కనిపించదు. రెండు స్థానిక పోర్టులను వంతెన చేసి తర్వాత రూట్ చేసే నిర్మాణం, ఇంటర్ఫేస్ పేర్లు ఏమి చెప్పినా, రౌటర్.

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

మోడెమ్ను కూడా క్లయింట్ వంతెన వెలుపల ఉంచండి. PPP కనెక్షన్ వేరే లేబుల్ ఉన్న Ethernet పరికరం కాదు, మరియు pppd యొక్క డాక్యుమెంట్ చేయబడిన డిఫాల్ట్-రూట్ లాజిక్ IPCP చర్చల తర్వాత పనిచేసి, ఆ లింక్ పడిపోయినప్పుడు తన మార్గాన్ని ఉపసంహరించుకుంటుంది. DHCP టెంప్లేట్ను కాపీ చేసి ప్రతి usb0 ను ppp0 గా పేరు మార్చడం గేట్వే, మెట్రిక్ లేదా జీవిత చక్రం గురించి ఏమీ నిరూపించదు.

ఏ కాన్ఫిగ్ను సవరించే ముందు ప్రిఫిక్స్లను ఎంచుకోండి

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

మొదటి చెరువు ఆపరేటర్ మోడెమ్కు ఇచ్చిన underlay చిరునామా; అది క్లయింట్ల వైపు ఉన్న ఏ ప్రణాళికకూ బయట ఉండాలి. రెండవది సర్వర్ ఎంచుకున్న సొరంగ సబ్నెట్, తరచుగా దాని సొంత ప్రైవేట్ /24 నెట్వర్క్. మూడవది హాట్స్పాట్ వంతెన, నాల్గవది మీరు చేరుకోవాలనుకునే ఇంటి ప్రిఫిక్స్. ఈ ప్రయాణంలో హాట్స్పాట్కు 172.28.90.0/24 లభిస్తుంది, వంతెన 172.28.90.1 లో ఉంది, మరియు ఇంటి సేవా LAN 192.168.77.0/24 ను నిలుపుకుంటుంది, ఇది వినియోగదారు రౌటర్లతో వచ్చే 192.168.1.0/24 మరియు 10.0.0.0/24 డిఫాల్ట్లను మరియు 100.64.0.0/10 ఆపరేటర్ పరిధిని నివారిస్తుంది.

హాట్స్పాట్ యొక్క DHCP పరిధిలో వంతెన చిరునామాను మాత్రమే గేట్వేగా ప్రకటించండి, మరేదీ కాదు. హాట్స్పాట్ క్లయింట్లకు ఎప్పుడూ గేట్వేగా ఇంటి చిరునామా ఇవ్వవద్దు; ఆ విభాగానికి వారికి లింక్-పొర మార్గం లేదు.

ప్రతి దిశను దానిని కలిగిన వైపే రూట్ చేయండి

Pi కు సొరంగం ద్వారా ఇంటి ప్రిఫిక్స్కు మార్గం అవసరం. సర్వర్ మోడ్లోని సర్వర్లు సాధారణంగా ఆ మార్గాన్ని నెట్టుతాయి, కాబట్టి మొదట ఫార్వర్డింగ్ ఆన్లో ఉందని మరియు కర్నెల్ tun0 నుండి ఇంటి చిరునామాను పరిష్కరిస్తుందని నిర్ధారించండి.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get ఇంకా underlay ఇంటర్ఫేస్ను నివేదిస్తే, అక్కడే ఆపండి; మార్గంలో ముందు ఏదీ తప్పు శోధనను సరిచేయలేదు.

ఇంటి పరికరాలకు 172.28.90.0/24 కు మార్గం లేదు, కాబట్టి వాటి ప్రతిస్పందనలు డిఫాల్ట్ గేట్వేను అనుసరించి రౌటర్ వద్ద మరణిస్తాయి. రెండు మద్దతు ఉన్న మరమ్మతులు ఉన్నాయి. ఒకటి, ఇంటి రౌటర్లో హాట్స్పాట్ ప్రిఫిక్స్ను VPN సర్వర్ యొక్క LAN చిరునామా వైపు చూపే స్థిర మార్గాన్ని జోడించండి; లేదా సర్వర్ స్వయంగా గేట్వే అయినప్పుడు క్లయింట్ ప్రిఫిక్స్ను సర్వర్ యొక్క సొంత రూటింగ్ పట్టికలో నమోదు చేయండి. OpenVPN యొక్క బహు-క్లయింట్ మోడ్లో క్లయింట్-నిర్దిష్ట డైరెక్టరీ ఆ సంబంధాన్ని మోస్తుంది: క్లయింట్ సర్టిఫికేట్ యొక్క సాధారణ పేరుతో పేరు పెట్టిన ఫైల్, అందులో iroute 172.28.90.0 255.255.255.0 మరియు దాన్ని సర్వర్ కర్నెల్లో ఇన్స్టాల్ చేసే సరిపోలే route పంక్తి ఉంటాయి. సర్వర్పై ఊహించిన కర్నెల్ మార్గం ఏ క్లయింట్ ప్రిఫిక్స్ను కలిగి ఉందో సర్వర్కు చెప్పడంతో సమానమైన ప్రకటన కాదు.

ఇది పనిచేయడానికి ఇంటి నెట్వర్క్ యొక్క DHCP సేవను VPN సర్వర్కు తరలించవద్దు. మొత్తం ఇంటికి డిఫాల్ట్ గేట్వేను మార్చడం ఒక ప్రైవేట్ తిరిగి వెళ్లే మార్గాన్ని జోడించడం కంటే చాలా పెద్ద మార్పు, మరియు అది DNS, చిరునామా రిజర్వేషన్లు మరియు కొత్త లీజును పట్టించుకోని ప్రతి పరికరాన్ని వైఫల్యంలోకి లాగుతుంది.

ఫైర్వాల్ గురించి ఊహించకుండా ఫార్వర్డింగ్ను తెరవండి

ఫార్వర్డింగ్ ఆన్లో ఉండటం ప్యాకెట్ దాటడానికి అనుమతి ఉందని కాదు. వంతెన నుండి సొరంగానికి ట్రాఫిక్ ఇంకా ఫిల్టర్ నియమాలను ఢీకొంటుంది, మరియు డిఫాల్ట్-డ్రాప్ ఫార్వర్డ్ విధానం హాట్స్పాట్ ట్రాఫిక్ను విసిరేస్తుంది, అయితే Pi యొక్క సొంత ట్రాఫిక్ పనిచేస్తూనే ఉంటుంది, ఇది పైన చెప్పిన చీలిక లక్షణాన్ని సరిగ్గా ఉత్పత్తి చేస్తుంది.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 నుండి tun0 వరకు అంగీకార నియమాన్ని మరియు సరిపోలే ప్రతిస్పందన దిశను, మూలాన్ని తిరిగి రాయగల postrouting నియమాన్ని వెతకండి. చైన్ విధానం drop అయి ఏ నియమం సరిపోలకపోతే, విధానాన్ని accept గా తిప్పడం బదులు సన్నని అంగీకారాలను జోడించి మళ్లీ పరీక్షించండి.

అనువాదం అవసరం కాదు, విధాన ఎంపిక. ఇంటి LAN వైపు మూల NAT ప్రతి హాట్స్పాట్ క్లయింట్ను Pi యొక్క సొరంగ చిరునామా లాగా కనిపించేలా చేస్తుంది, ఇది ఇంటి లాగ్లలో ప్రతి క్లయింట్ ఆపాదింపును కోల్పోతుంది మరియు అసలు మూలాన్ని ఆశించే సేవలను పగులగొడుతుంది. NAT లేని రూటింగ్ క్లయింట్ చిరునామాలను కనిపించేలా ఉంచుతుంది కానీ పైన ఉన్న తిరిగి వెళ్లే మార్గంపై ఆధారపడుతుంది. ఒకదాన్ని ఎంచుకొని DNS మరియు IPv6 లను అదే విధంగా నిర్వహించండి, ఎందుకంటే పగిలిన IPv6 మార్గం పక్కన పనిచేసే IPv4 మార్గం బ్రౌజర్లో ఇప్పటికీ సగం పగిలినట్లుగానే చదవబడుతుంది.

ప్రయాణాన్ని ధృవీకరించి, తర్వాత ఉద్దేశపూర్వకంగా పగలగొట్టండి

హాట్స్పాట్ క్లయింట్ నుండి పరీక్షించండి, ఎప్పుడూ Pi నుండి కాదు, ఎందుకంటే Pi యొక్క సొంత ట్రాఫిక్ ముందు మరియు తిరిగి వెళ్లే రెండు మార్గాలను దాటవేస్తుంది. ఒక క్లయింట్ ఇంటి సేవను చేరుకోవడానికి ప్రయత్నిస్తున్నప్పుడు రెండు ఇంటర్ఫేస్లను గమనించండి.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

రెండు క్యాప్చర్లను కలిసి చదవండి. br0 లో కనిపించి tun0 లో ఎప్పుడూ కనిపించని అభ్యర్థనలు Pi ఫార్వర్డ్ చేయడం లేదు లేదా మార్గం వేరే చోటుకు చూపుతోంది అని అర్థం. tun0 లో ప్రతిస్పందన లేని అభ్యర్థనలు ఇంటి వైపు తిరిగి వెళ్లే మార్గం లేదు లేదా సర్వర్ ప్యాకెట్ను ఫిల్టర్ చేసింది అని అర్థం. tun0 లో కనిపించి br0 లో మళ్లీ కనిపించని ప్రతిస్పందనలు తిరగండి ఫిల్టర్ నియమం లేదు అని అర్థం; అక్కడ సొరంగం పరిపూర్ణంగా కనిపిస్తుంది, క్లయింట్ ఇంకా ఏమీ చూడలేదు.

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

హాట్స్పాట్ క్లయింట్ ఇంటి పేరును పరిష్కరించగలిగి, TCP సేవను తెరవగలిగి, ఒక మోడెమ్ పునఃకనెక్షన్ అంతటా సెషన్ను సజీవంగా ఉంచగలిగినప్పుడే నిర్మాణాన్ని అంగీకరించండి. ఒక అప్లికేషన్ ఇంటి విభాగంలో నిజంగా Ethernet స్థాయి కనుగొనడం కోరితే, స్థానిక వంతెనను వంతెన చేయబడినదిగా వివరించి ప్రసారం వచ్చే వరకు వేచి ఉండకుండా మద్దతు ఉన్న Layer 2 నిర్మాణాన్ని ఎంచుకోండి.