VPN మరియు వెబ్ కోసం ఒకే పబ్లిక్ హోస్ట్: పాత్రలను ఎలా విభజించాలి

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

తర్వాత వచ్చేది నిర్ణయ ప్రక్రియ, నిర్మాణ షీట్ కాదు. ప్రతి అడుగు ఇప్పుడే జోడించిన పాత్ర నిజంగా వేరుచేయబడిందని నిరూపించే తనిఖీతో ముగుస్తుంది.

పోర్ట్లకు ముందు చిరునామా యజమానిని ఎంచుకోండి

టన్నెల్ ముగింపు బిందువు మరియు వెబ్ సర్వర్ ఒకే కెర్నల్ పంచుకోగలవు; ఒకే సమయంలో ఒక చిరునామా, పోర్ట్ మరియు ప్రోటోకాల్ పంచుకోవడమే విఫలమయ్యేది. WireGuard సాధారణంగా UDP 51820 తీసుకుంటుంది, OpenVPN UDP 1194 లేదా TCP 443 తీసుకుంటుంది, మరియు వెబ్ సర్వర్ TCP 443 తీసుకుంటుంది. నొప్పి కలిగించే జత HTTPS పక్కన TCP 443పై OpenVPN, ఎందుకంటే రెండూ ఒకే సాకెట్ కోరుకుంటాయి మరియు కెర్నల్ దానిని మొదట కట్టుకున్న వారికి ఇస్తుంది. ముందున్న డీమల్టిప్లెక్సర్ మాత్రమే, ఉదాహరణకు sslh లేదా TLS తెలిసిన ప్రాక్సీ, ఆ పోర్ట్ను పంచుకోనిస్తుంది, మరియు దాని వైఫల్యం ఫైర్వాల్ సమస్యలాగానే కనిపించే ఒక భాగాన్ని జోడిస్తుంది.

ఏదైనా మార్చే ముందు యజమానులను చూడండి: ss -lntup వినిపిస్తున్న ప్రతి సాకెట్ యొక్క స్థానిక చిరునామా, పోర్ట్ మరియు ప్రక్రియను ముద్రిస్తుంది. చూపించే రెండు వరుసలు 0.0.0.0:443 అంటే రెండవ సేవ ఎప్పుడూ కట్టుకోలేదు, దాని init స్క్రిప్ట్ ఎంత సంతోషంగా ఉన్నా. బ్రిడ్జింగ్ యజమానిని కూడా కదిలిస్తుంది. ఎప్పుడు eth0 తో కలుస్తుంది br0, IP br0 కు వెళ్తుంది మరియు eth0 అని పేర్కొనే ప్రతి ఫైర్వాల్ నియమం సరిపోలకుండా మారుతుంది, కాబట్టి సేవలను బ్రిడ్జ్పై కట్టి ip -br addr తో నిర్ధారించండి.

అదే యాజమాన్య నియమం వర్చువల్ యంత్రాలతో వచ్చే ఆశ్చర్యాన్ని వివరిస్తుంది. అదే LANలో అతిథి లోపల నడుస్తున్న టన్నెల్ సర్వర్ అతిథి చిరునామాను ఉంచుతుంది, కాబట్టి హోస్ట్ సొంత చిరునామా వైపు మళ్లిన కనెక్షన్లు హోస్ట్పైనే ఉంటాయి మరియు అతిథి టన్నెల్ వాటిని ఎప్పుడూ చూడదు, క్లయింట్ ప్రొఫైల్ ఏం చెప్పినా.

రెండు LANల మధ్య రూట్ చేయండి లేదా ఒక వైపు NAT చేయండి

ఒకరినొకరు చూడని రెండు LANలు ఒక్కొక్కటి పబ్లిక్ హోస్ట్ను కాల్ చేయగలవు, అది తర్వాత టన్నెళ్ల మధ్య ఫార్వార్డ్ చేస్తుంది. ఆ రూటెడ్ డిజైన్కు మూడు విషయాలు కావాలి: ఫార్వార్డింగ్ ఆన్, ప్రతి దూర ప్రిఫిక్స్కు మార్గం మరియు ట్రాన్జిట్ను దాటనిచ్చే ఫార్వార్డింగ్ విధానం. sysctl -w net.ipv4.ip_forward=1 మొదటిదాన్ని కవర్ చేస్తుంది, ip route add 10.20.0.0/24 dev wg1 రెండవదాన్ని, మరియు nftables పంక్తి nft add rule inet filter forward iifname "wg0" oifname "wg1" accept మూడవదాన్ని.

సోర్స్ NAT జోడించడం సులభం, డీబగ్ చేయడం కష్టం. మాస్కరేడింగ్ క్లయింట్ చిరునామాను తిరిగి రాస్తుంది, కాబట్టి దూర వైపు నిజమైన హోస్ట్ కాకుండా హబ్ను చూస్తుంది, మరియు దాని యాక్సెస్ నియమాలు మరియు లాగ్లు ఆపాదనకు ఉపయోగపడవు. రెండు నెట్వర్క్లు మీవి అయితే రూట్ చేయండి. ఒక వైపు తిరిగి మార్గాన్ని జోడించని మూడవ పక్షానికి చెందినది అయితే, NAT ఈ వారం బయటకు వెళ్లే ఎంపిక. ఏదేమైనా చిరునామా ప్రణాళికను రాయండి, ఎందుకంటే రెండు అతివ్యాప్తి చెందే /24లను ఏ కాన్ఫిగరేషన్ రూట్ చేయలేదు.

ల్యాప్టాప్కు ఇంటర్నెట్ నిష్క్రమణగా పనిచేయడం అదే బాక్స్ లోపలికి వచ్చే టన్నెళ్లను ముగించడాన్ని ఆపదు. అతివ్యాప్తి చెందే చిరునామాలు మాత్రమే ఆపుతాయి, అందుకే చిరునామా ప్రణాళిక ముఖ్యమైన పత్రం.

రెండు పాత్రలు ఆగి ఉన్నప్పుడు విభజనను పరీక్షించండి

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

మూడు ఆదేశాలు ఆ పరీక్షను నిర్దిష్టం చేస్తాయి. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ బాహ్య DNS లేకుండా స్థానిక శ్రోత సమాధానం ఇస్తుందని నిరూపిస్తుంది, wg show క్లయింట్పై హ్యాండ్షేక్ పూర్తైందని నిరూపిస్తుంది, మరియు tcpdump -ni any port 51820 హబ్పై రూటింగ్ సమస్యను కీ సమస్య నుండి వేరు చేస్తుంది. క్యాప్చర్లో ఎప్పుడూ కనిపించని హ్యాండ్షేక్ హోస్ట్కు ముందే మరణించింది: ప్రదాత ఫైర్వాల్, తప్పు పబ్లిక్ చిరునామా లేదా మార్గంలో NAT నియమం.

ఫార్వార్డ్ అయ్యే LANలకు వ్యవకలనాన్ని పునరావృతం చేయండి. ఒక పీర్ డిస్కనెక్ట్ అయినప్పుడు హబ్ ద్వారా పింగ్ విఫలం కావాలి; తిరిగి కనెక్ట్ అయినప్పుడు ఏ నియమాన్ని తాకకుండా పింగ్ కోలుకోవాలి. టన్నెల్ పునఃప్రారంభించిన తర్వాత మాత్రమే కోలుకునే పింగ్ చేరుకోగల సామర్థ్యాన్ని కాదు, విధానాన్ని సూచిస్తుంది, అది మరో సవరణ.

పాత్రలను తగ్గించేటప్పుడు నియమ సమూహాన్ని చదవగలిగేలా ఉంచండి. nft list ruleset నిజంగా అవసరమైన ప్రతి దిశకు ఒక అంగీకార నియమాన్ని చూపాలి, మరియు అన్నింటినీ అంగీకరించే ఫార్వార్డ్ గొలుసు విభజన కాదు, అది పనిచేసే ప్రదర్శన.

IPv6 మాత్రమే యాక్సెస్ లైన్లు మరియు IPv4 సేవలు

కొన్ని యాక్సెస్ లైన్లు IPv6 చేరుకోగల సామర్థ్యాన్ని మాత్రమే ఇస్తాయి, సేవలు ఇప్పటికీ IPv4 ద్వారా ప్రచురించాలి. టన్నెల్ స్వయంగా ఇంకా ట్రాఫిక్ దాటనిచ్చే కుటుంబం ద్వారా ప్రయాణిస్తుంది, ప్రచురిత సేవ టన్నెల్ లోపలి చిరునామాపై కూర్చుంటుంది. ఇది సాధారణ ఊహను తలకిందులు చేసి పర్యవేక్షణను నిశ్శబ్దంగా విచ్ఛిన్నం చేస్తుంది: IPv4 మార్గం కోసం రాసిన ఫైర్వాల్ నియమం లేదా అప్టైమ్ తనిఖీ ఇప్పుడు ఏమీ మోయని ఇంటర్ఫేస్ను గమనిస్తుంది.

ప్రతి కుటుంబాన్ని విడివిడిగా పరీక్షించండి curl -4 మరియు curl -6 తో, ఎందుకంటే ఒక విజయవంతమైన అభ్యర్థన మీరు ప్రయత్నించని మార్గం గురించి ఏమీ చెప్పదు. పోర్ట్ యాజమాన్యం కుటుంబాల మధ్య మారదు, కానీ శ్రోత మారుతుంది: ss -lntup IPv4 మరియు IPv6 సాకెట్లను వేర్వేరు వరుసలలో జాబితా చేస్తుంది, మరియు 0.0.0.0:443 కవర్ చేయదు [::]:443 ప్రక్రియ dual-stack సాకెట్ అడగకపోతే.

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