OpenVPN మరియు HTTPS పోర్ట్ 443లో: వినేవాడు ఎవరిది?
TCP మరియు UDP 443 వేర్వేరు సాకెట్లు. ఒక TCP వినేవాడిని పంచుకోవడానికి యజమాని అవసరం, మరియు OpenVPN పోర్ట్ పంచుకోవడం ఒక సన్నిహిత ఒప్పందం, ప్రాక్సీ ఉపాయం కాదు.
రెండు సేవలు ఎప్పుడూ పోటీపడకుండా రెండూ పోర్ట్ 443లో సమాధానం ఇవ్వగలవు, ఎందుకంటే వినేవాడు సంఖ్యతో మాత్రమే కాదు, రవాణా, చిరునామా మరియు పోర్ట్ కలిసి నిర్ణయించబడతాయి. ఒకే యంత్రంలో వెబ్ సర్వర్ మరియు OpenVPN ఉంచండి, మొదట సమాధానం ఇవ్వదగిన ఏకైక ప్రశ్న ప్రతి ప్రక్రియ కెర్నల్ నుండి ఏ సాకెట్ అడుగుతుంది అనేది. కాన్ఫిగరేషన్ సవరించే ముందు ఆ జాబితా రాయండి, «చిరునామా ఇప్పటికే వాడుకలో ఉంది» లోపాలలో చాలావరకు తమంతట తాము వివరించబడతాయి. జాబితా తర్వాత అంతా UDP వినేవాడు, పంచుకున్న TCP సాకెట్ లేదా ప్రోటోకాల్ ప్రకారం మార్గనిర్దేశం చేసే ముందుభాగం మధ్య ఎంపిక.
ప్రతి ప్రక్రియ అడిగే సాకెట్ నుండి ప్రారంభించండి
bind ఆ త్రికంపై విజయం లేదా వైఫల్యం పొందుతుంది, కాబట్టి మూడు భాగాలు కలిసినప్పుడే రెండు డీమన్లు ఢీకొంటాయి. అందుకే TCP 443లో వెబ్సైట్ UDP 443లో OpenVPN వినేవాడితో అపరిమితంగా సహజీవనం చేస్తుంది, అందుకే వాటిలో ఒకదాన్ని అదే హోస్ట్లోని రెండవ స్థానిక చిరునామాకు తరలించడం కూడా చర్చను ముగిస్తుంది. సజీవంగా ఉన్న వినేవారిని చదవండి, వాటిని సృష్టించాల్సిన ఫైళ్లను కాదు, ఎందుకంటే పాత include లేదా మరచిపోయిన unit ఫైల్ మీకు గుర్తున్న సవరణ కంటే ఎక్కువ కాలం నిలిచి ఉంటుంది.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
rootగా ss -lntup నడపండి మరియు 443 ప్రస్తావించే ప్రతి పంక్తిని, IPv6 నమోదులతో సహా చదవండి. సాధారణంగా వైల్డ్కార్డ్ v6 వినేవాడు v4 ట్రాఫిక్ను కూడా అంగీకరిస్తాడు, అలాగే మరచిపోయిన వినేవాడు మీరు బాధ్యుడని భావించిన ఫైల్ను మార్చిన తర్వాత కూడా పోర్ట్ను ఆక్రమించి ఉంచుతాడు. ప్రక్రియ పేరు మీకు ఆశ్చర్యం కలిగిస్తే, ఏదైనా తాకే ముందు ss -lntup 'sport = :443' తో అవుట్పుట్ను కుదించండి.
నెట్వర్క్ అనుమతించినప్పుడు సొరంగాన్ని UDPకి మార్చండి
UDP వినేవాడు ఢీకొనడాన్ని పూర్తిగా దాటవేస్తాడు మరియు సాధారణంగా అతి చిన్న మరమ్మతు, ఎందుకంటే ఏ సాకెట్ పంచుకోబడదు మరియు మార్గంలో అదనపు ఉత్పత్తి ప్రవేశించదు. కానీ ఇది ఉచితం కాదు. కొన్ని క్లయింట్ నెట్వర్క్లు reset పంపకుండా UDP 443ను వదిలేస్తాయి, కాబట్టి సొరంగం bindలో విఫలమవడం బదులు స్థాపించడం ఆగిపోతుంది, మరియు వినియోగదారు చదవడానికి ఏ లోపం లేకుండా VPN ఆగిపోయిందని నివేదిస్తాడు. UDP వినేవాడు వెబ్ పొర పునఃప్రారంభాన్ని కూడా తట్టుకుంటాడు, ఇది సైట్ తరచుగా మళ్లీ అమలు చేయబడే యంత్రంలో ముఖ్యం. వినియోగదారులు కూర్చున్న నెట్వర్క్ నుండి పరీక్షించండి, ఎందుకంటే సర్వర్లోని shell సర్వర్ తనను తాను చేరుకోగలదని మాత్రమే నిరూపిస్తుంది.
సర్వర్ కాన్ఫిగరేషన్లో మరియు క్లయింట్ ప్రొఫైల్లో రవాణాను కలిసి మార్చండి. ఇంకా TCP అడిగే ప్రొఫైల్ UDP మాత్రమే ఉన్న వినేవాడి ఎదుట పునఃకనెక్షన్ చక్రాల్లో తిరుగుతుంది, మరియు రెండు ఫైళ్లను పోల్చే వరకు అది నెట్వర్క్ వైఫల్యంలా కనిపిస్తుంది.
VPN ప్రక్రియకు TCP 443 యాజమాన్యం ఇవ్వండి మరియు మిగిలినది ముందుకు పంపండి
TCP సర్వర్ మోడ్లో Community OpenVPN వచ్చే కనెక్షన్ మొదటి బైట్లను చదివి తన ప్రోటోకాల్ కానిదంతా HTTPS బ్యాకెండ్కు పంపుతుంది, port-share సూచన అందుకే. బ్యాకెండ్ TLS ప్రారంభించిన సాధారణ వెబ్ సర్వర్, ఆ సూచనలో దాన్ని URLతో కాదు, హోస్ట్ మరియు పోర్ట్తో పేరు పెడతారు.
port-share 10.0.0.5 8080
సైట్కు రెండవ ప్రైవేట్ చిరునామా ఉన్న యంత్రంలో ఆ పంక్తి VPN కాని ట్రాఫిక్ను 10.0.0.5:8080కు పంపుతుంది, కాబట్టి HTTPS వర్చువల్ హోస్ట్ అక్కడ బైండ్ అయి ఉండాలి మరియు ఫైర్వాల్ స్థానిక దూకుడును అనుమతించాలి. వెబ్ సర్వర్ TLSను తానే ముగించాలి, ఎందుకంటే వచ్చే బైట్లు బ్రౌజర్ అసలు హ్యాండ్షేక్ మరియు మధ్యలో ఏదీ వాటిని డీక్రిప్ట్ చేయలేదు. సూచనను సాధారణ HTTP వినేవాడి వైపు తిప్పండి, బ్రౌజర్కు చెల్లని పద్ధతి లోపం వస్తుంది, అది బ్యాకెండ్ తప్పు స్థలంలో ఉన్నట్టుగా కాకుండా విరిగిన సైట్లా చదవబడుతుంది. సూచన TCP సర్వర్ మోడ్లో మాత్రమే ఉంటుంది, UDP వినేవాడికి పరిశీలించడానికి ప్రవాహం లేదు.
VPN ప్రక్రియ ప్రతి కనెక్షన్ను అంగీకరించడం వల్ల, వెబ్ అప్లికేషన్ పంపిన అభ్యర్థన సందర్శకుడి నుండి కాకుండా హోస్ట్ స్వంత చిరునామాల్లో ఒకటి నుండి వస్తున్నట్టు చూస్తుంది. నిజమైన క్లయింట్ చిరునామా అవసరమైన ప్రతిదీ బ్యాకెండ్లో PROXY ప్రోటోకాల్ మద్దతు లేదా దాన్ని జోడించే ముందుభాగంపై ఆధారపడి ఉంటుంది. బ్యాకెండ్ను మరో స్థానిక చిరునామాకు తరలించడం సందర్శకుడి చిరునామాను తిరిగి తీసుకురాదు; సైట్ హోస్ట్ యొక్క ఏ చిరునామాలను నమోదు చేస్తుందో మాత్రమే మారుస్తుంది. విశ్లేషణ నివేదిక ప్రశ్న లేవనెత్తే ముందు ఈ పరిమితిని అమలు గమనికల్లో రాయండి.
రివర్స్ ప్రాక్సీ తప్పు సాధనం; లేయర్-నాలుగు రౌటర్ కాదు
HTTP రివర్స్ ప్రాక్సీ అభ్యర్థనలను చదవడానికి TLSను ముగిస్తుంది, అంటే అది OpenVPN ప్రవాహాన్ని తాకకుండా దాటించలేదు. SNI లేదా మొదటి ప్యాకెట్ పరిశీలన ప్రకారం పంపే లేయర్-నాలుగు రౌటర్ VPN ఆధారపడే సెషన్ను ముగించకపోతే రెండింటి ముందూ నిలబడగలదు. రెండు పరికరాలు రేఖాచిత్రంలో ఒకేలా కనిపిస్తాయి, సాకెట్ వద్ద పూర్తిగా భిన్నంగా ప్రవర్తిస్తాయి.
వాణిజ్య Access Server తన స్వంత పోర్ట్ పంచుకునే సెట్టింగ్లతో వస్తుంది, అవి సమాజ సూచనతో ఒకటికి ఒకటి సరిపోలవు. మరొకదాని కోసం రాసిన మార్గదర్శిని స్వీకరించే ముందు ఉత్పత్తి మరియు వెర్షన్ను గుర్తించండి. నిశ్శబ్దంగా నిర్లక్ష్యం చేయబడిన కాపీ చేసిన సెట్టింగ్ సెట్టింగ్ లేకపోవడం కంటే చెడ్డది, ఎందుకంటే దాని తర్వాత కూడా వినేవారి జాబితా నమ్మదగినదిగా కనిపిస్తుంది.
వెబ్సైట్ మరియు సొరంగాన్ని రెండు వేర్వేరు మార్గాలుగా పరీక్షించండి
సైట్ను లోడ్ చేసి సొరంగాన్ని కనెక్ట్ చేయండి, తర్వాత 443 ఇప్పుడు ఏ ప్రక్రియ యాజమాన్యంలో ఉందో చూడటానికి వినేవారి జాబితాను మళ్లీ చదవండి. లోడ్ అయ్యే పేజీ VPN గురించి ఏమీ నిరూపించదు, కనెక్ట్ అయ్యే సొరంగం సైట్ గురించి ఏమీ నిరూపించదు, రెండూ ఒకే సంఖ్యను ఉపయోగించినా. క్రింది మూడు ఆదేశాలు పంచుకున్న సాకెట్, వెబ్ మార్గం మరియు VPN సేవను ఆ క్రమంలో తనిఖీ చేస్తాయి.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
అదే క్షణానికి బ్యాకెండ్ యాక్సెస్ లాగ్లోని క్లయింట్ చిరునామాను VPN లాగ్లోని దానితో పోల్చండి. సైట్ ప్రతి సందర్శకుడిని హోస్ట్ తానే అని నమోదు చేస్తే పంపడం పని చేస్తుంది, చిరునామా నిర్వహణ పని చేయదు. రెండు లాగ్లు నిశ్శబ్దంగా ఉంటే ముందుభాగం ఎప్పుడూ కనెక్షన్ను అప్పగించలేదు. ఏదేమైనా, సాకెట్ను ఎవరు అంగీకరిస్తారో వినేవారి జాబితా నిర్ణయిస్తుంది, మరియు మరో ఫైల్ను మార్చే ముందు నిర్ధారించవలసిన వాస్తవం అదే.
ఆ వినేవారి పటాన్ని కాన్ఫిగరేషన్ పక్కన ఉంచండి, తద్వారా 443ను తాకే తదుపరి వ్యక్తి ఏ ప్రక్రియ అంగీకరిస్తుందో మరియు మరో ప్రోటోకాల్ ఎక్కడికి వెళ్ళిందో తెలుసుకోగలడు. సవరణ ఏమి చేయాలనుకుందో నమ్మడం బదులు మార్పు తర్వాత యాజమాన్యాన్ని నిర్ధారించండి.