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

రెండు సాకెట్లు, ఇద్దరు యజమానులు, ఒకటి పబ్లిక్

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

మెషీన్ నుండే పని చేయడం పబ్లిక్ మార్గం గురించి చాలా తక్కువ నిరూపిస్తుంది. అసలు పోర్టుకు నేరుగా కనెక్షన్ ర్యాపర్ను దాటవేస్తుంది, ర్యాపర్ LAN చిరునామాకు కనెక్షన్ అనువాదాన్ని దాటవేస్తుంది, బయటి వినియోగదారు చేసేది పూర్తి క్లయింట్ వైపు అమరిక మాత్రమే సాధన చేస్తుంది. పేర్లను కూడా జాగ్రత్తగా చదవాలి, ఎందుకంటే localhost ఆ నిర్దిష్ట భాగాన్ని నడిపే హోస్ట్ను సూచిస్తుంది, మీరు యాదృచ్ఛికంగా టైప్ చేస్తున్న హోస్ట్ను కాదు. ఆ భేదాన్ని మీ నోట్స్లో ఉంచండి, ఎందుకంటే తాను కవర్ చేసిన దూకుడును నమోదు చేయకుండా నమోదు చేసిన పరీక్ష రెండు వేర్వేరు విషయాలను పోల్చమని ఆహ్వానిస్తుంది.

ఫార్వర్డ్ నిజంగా ఎక్కడ దిగుతుంది

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

HopListens onMust reachSymptom when it points elsewhere
Client machineA local plaintext portThe wrapper's public TLS addressPlain text offered to a TLS endpoint
Router forwardPublic TCP 443The wrapper host on its translated portWrapper records no connection at all
Wrapper, server modeIts accepted port, 8443 hereThe native VPN socket on loopbackHandshake completes, then silence
Native VPN listenerLoopback TCP portIts peer, over TCP onlyA UDP socket behind a byte-stream relay

ర్యాపర్కు బదులుగా అసలు VPN పోర్ట్ను లక్ష్యంగా చేసుకునే నియమం TLS ముగింపును పూర్తిగా దాటవేస్తుంది, ఇదే ఈ పొరపాటు అత్యంత సాధారణ రూపం: క్లయింట్ OpenVPN ఫ్రేమింగ్ను ఆశించే శ్రోతతో హ్యాండ్షేక్ తెరుస్తుంది, కాబట్టి కనెక్షన్ తెరుచుకుని తర్వాత ఆగిపోవచ్చు. అనువదించిన పోర్ట్ను జ్ఞాపకానికి బదులుగా ర్యాపర్ కాన్ఫిగరేషన్ ఫైల్తో ధృవీకరించండి, ఎందుకంటే ఆ ఫైల్ను తదుపరిసారి సవరించే వ్యక్తి వేరే నంబర్ను ఎంచుకుని ఉండవచ్చు. క్రింది రెండు ఆదేశాలు ఆ ప్రశ్నకు రెండు వైపులా ఒకేసారి చూపుతాయి.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

మిమ్మల్ని తిరస్కరించే బైండ్ చిరునామా

127.0.0.1 కు బంధించబడిన accept వరుస హోస్ట్కు మాత్రమే సమాధానం ఇస్తుంది, కాబట్టి LAN చిరునామాకు వచ్చే ఫార్వర్డ్ కనెక్ట్ కాలేదు మరియు క్లయింట్కు ప్యాకెట్ ఫిల్టర్ సమస్యలా వినిపించే తిరస్కరణ కనిపిస్తుంది. ఫైర్వాల్ను తాకే ముందు సాకెట్ను చూడండి, ఎందుకంటే సాకెట్ చవకైన సమాధానం. ఒకటి, ఫార్వర్డ్ లక్ష్యంగా చేసుకునే ఇంటర్ఫేస్కు ర్యాపర్ను బంధించండి; లేదా దాన్ని loopbackలో ఉంచి, నిజంగా పనిచేసే దాని ద్వారా ఫార్వర్డ్ loopbackను చేరేలా చేయండి. ఇవి రెండు డిజైన్లు, ప్రతి దానికి సొంత నియమం కావాలి.

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

ss -lntp '( sport = :8443 )'

స్థానిక పరీక్ష నిజంగా ఏమి నిరూపించింది

తాను కవర్ చేసిన దూకుడును నమోదు చేయకుండా నమోదు చేసిన విజయం మిగతా దూకుడ్ల గురించి సాక్ష్యం కాదు. పరీక్ష ఏ చిరునామాను ఉపయోగించింది, ఏ ప్రక్రియ సమాధానం ఇచ్చింది అని రాసుకోండి. తర్వాత అదే Wi-Fiలోని ఫోన్ నుండి కాదు, నెట్వర్క్ బయటి నుండి పునరావృతం చేయండి, ఎందుకంటే హెయిర్పిన్ ప్రవర్తన రౌటర్ల మధ్య మారుతుంది మరియు LAN నుండి ఎప్పుడూ బయటకు వెళ్లని కనెక్షన్ కూడా ఫార్వర్డ్ అసలు పాల్గొనకుండానే క్లయింట్ను సంతృప్తపరచగలదు. ఆ రెండవ ప్రయత్నం మాత్రమే బయటి వ్యక్తి నడిచే మార్గాన్ని సాధన చేస్తుంది.

ప్రయత్నం విఫలమైతే, ఒకే కనెక్షన్ను రెండు లాగ్లలో అనుసరించండి: ర్యాపర్ యొక్క అంగీకరించిన మరియు కనెక్ట్ అయిన వరుసలు, తర్వాత VPN డీమన్ సొంత సెషన్ లాగ్. ఏమీ నమోదు చేయని మొదటి సరిహద్దే తదుపరి మార్పు స్థానం. OpenVPN భాగస్వామి ఎంపికలను పోల్చడం ప్రారంభించాక, ఆ సందేశాలను ఆ అమలు నియమాలతో అంచనా వేయండి. link-mtu అసంగతి హెచ్చరిక దానంతట అదే ప్రాణాంతకం కాదు, link-mtuను 1500కు పిన్ చేయడం విభజన ఆగిందని నిరూపించదు, మరియు సైఫర్ చర్చలు రౌటర్ ఫార్వర్డ్కు కాదు, OpenVPN అంతర్గత కాన్ఫిగరేషన్కు చెందుతాయి.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

ఆ పరీక్షలు బ్యాకెండ్ సాకెట్ మరియు ర్యాపర్ లాగ్ను కవర్ చేస్తాయి, ఇది తిరస్కరించబడిన బ్యాకెండ్ను తిరస్కరించబడిన హ్యాండ్షేక్ నుండి వేరు చేస్తుంది. ఒక ప్రయత్నం జరుగుతున్నప్పుడే వాటిని అమలు చేయండి, తర్వాత కాదు. ఒకే ప్రయత్నం యొక్క సమయ ముద్రలే పోలికను విశ్వసనీయం చేస్తాయి.

రెండు గుర్తింపులు, రెండు వైఫల్య క్రమాలు

బయటి ధృవపత్రం ర్యాపర్కు చెందుతుంది, లోపలి గుర్తింపు OpenVPNకు చెందుతుంది, అవి వేర్వేరు అధికారుల నుండి రావచ్చు. మార్గం ఆరోగ్యంగా కనిపించడానికి రెండు తనిఖీలలో ఏదైనా నిలిపివేయడం నిజమైన రక్షణను కనిపించే ఫలితంతో మారుస్తుంది. రెండు ధృవీకరణలను ఉంచి క్రమంగా డీబగ్ చేయండి, ఎందుకంటే సందేశాల క్రమం పొరను పేర్కొంటుంది: ర్యాపర్ ధృవపత్ర సమస్య ఏదైనా VPN ఎంపిక చర్చకు ముందే కనిపిస్తుంది, లోపలి గుర్తింపు వైఫల్యం స్ట్రీమ్ స్థాపించిన తర్వాత మాత్రమే కనిపిస్తుంది.

stunnel మాన్యువల్ accept, connect మరియు క్లయింట్ మోడ్ను ఖచ్చితంగా నిర్వచిస్తుంది, ఆ విభాగాలు ఊహ కంటే వేగంగా సాకెట్ ప్రశ్నకు సమాధానం ఇస్తాయి. ఏ పొర సమాధానం ఇచ్చిందో ఇంకా చెప్పలేకపోతే, క్రింది ఆదేశంతో పబ్లిక్ పోర్ట్ అందించే ధృవపత్రాన్ని చదవండి. అవుట్పుట్లో ర్యాపర్ ధృవపత్రం ఉంటే ఫార్వర్డ్ ర్యాపర్ను చేరింది, నిశ్శబ్దం లేదా ప్రోటోకాల్ లోపం అంటే చేరలేదు. ఆ ఒక్క భేదం ఇక్కడ మరే ఇతర తనిఖీ కంటే ఎక్కువ సమయాన్ని ఆదా చేస్తుంది.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

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