టన్నెల్ పైకి లేచిన వెంటనే UFW VPN DNS సర్వర్ను వదిలేస్తుంది
UFW యొక్క డిఫాల్ట్ తిరస్కరణ విధానం టన్నెల్ ఇంటర్ఫేస్ను కూడా కవర్ చేస్తుంది. ట్రాఫిక్ను దిశ ప్రకారం అమర్చి, tun0 పై నెట్టబడిన resolver కు అనుమతి ఇచ్చి, ఆపై బయటి మార్గాన్ని తెరవండి.
VPN కనెక్ట్ అయిన క్షణంలోనే పేర్లు పరిష్కరించడం ఆగిపోతుంది, అయితే పబ్లిక్ చిరునామాకు ping ఇప్పటికీ సమాధానం ఇస్తుంది మరియు firewall స్థితిలో తప్పుగా కనిపించే ఏదీ కనిపించదు. విధనంలో ఏమీ మారలేదు; మారింది కొత్త ఇంటర్ఫేస్ వచ్చింది, మరియు డిఫాల్ట్ తిరస్కరణ మొదటి ప్యాకెట్ నుండే దాన్ని కవర్ చేస్తుంది. UFW దిశ మరియు ఇంటర్ఫేస్ ప్రకారం నిర్ణయిస్తుంది, కాబట్టి వైర్లెస్ లింక్ కోసం రాసిన నియమం టన్నెల్ నుండి బయటకు వెళ్లే ట్రాఫిక్ గురించి ఏమీ చెప్పదు. పరిష్కారం నిర్దిష్ట క్రమంలో వర్తించే కొన్ని సన్నని నియమాలు.
లక్షణం టన్నెల్ పైకి లేచిన తర్వాత మాత్రమే కనిపిస్తుంది
డిఫాల్ట్ తిరస్కరణ విధానం చెప్పినది సరిగ్గా చేస్తుంది: సరిపోయే నియమం లేని ప్రతిదీ, ఉన్న ప్రతి ఇంటర్ఫేస్లో తిరస్కరించబడుతుంది. నియమాలు రాసినప్పుడు టన్నెల్ లేదు, కాబట్టి వాటిలో ఏదీ దాన్ని పట్టుకోలేదు, మరియు ఎప్పుడూ ఉన్న తిరస్కరణ ఇప్పుడు పేర్ల పరిష్కారానికి వర్తిస్తుంది. అక్షర చిరునామాకు నేరుగా ట్రాఫిక్, విస్తృత అనుమతి దాన్ని కవర్ చేసినప్పుడు ఇంకా పనిచేయవచ్చు, అందుకే పబ్లిక్ resolver కు ping విజయవంతమవుతుంది కానీ పేరు వెతకడం విఫలమవుతుంది. ఖాళీ అనేది విధానం ఎప్పుడూ చూడని ఇంటర్ఫేస్ కోసం ఉన్న నియమం.
వైఫల్యం ఎందుకు శుభ్రంగా తిరగబడుతుందో కూడా ఇది వివరిస్తుంది: టన్నెల్ దించండి, పేర్లు మళ్లీ పరిష్కరించబడతాయి, ఎందుకంటే ప్రశ్న నియమాలు ఉన్న ఇంటర్ఫేస్కు తిరిగి వెళ్తుంది. టన్నెల్ పైన ఉన్నప్పుడు మాత్రమే విఫలమయ్యే విధానం DNS సమస్య కాదు, మరియు resolver ను స్వయంగా ట్యూన్ చేయడం ఇక్కడ ఎక్కువ సమయాన్ని వృథా చేస్తుంది. resolver కాన్ఫిగరేషన్ చదవడానికి ముందు ఇంటర్ఫేస్ జాబితా చదవండి.
మూడు దిశలు, మూడు వేర్వేరు నియమ సమూహాలు
ఒక సెషన్ ఒకటి కంటే ఎక్కువ దిశల్లో నియమాలను తాకుతుంది, మరియు టన్నెల్ వాటిలో దాదాపు అన్నింటికీ రెండవ ఇంటర్ఫేస్ను జోడిస్తుంది. ట్రాఫిక్ను మొదట దిశ మరియు ఇంటర్ఫేస్ ప్రకారం అమర్చడం మిగతాదాన్ని యాంత్రికంగా చేస్తుంది, ఎందుకంటే క్రింది ప్రతి వరుసకు తన స్థానంలో తన నియమం కావాలి. ఉదాహరణలు tun0 మరియు 10.8.0.0/24 పూల్ ఉపయోగిస్తాయి, కాబట్టి పేర్లు మరియు పరిధులను క్లయింట్ స్వంత అవుట్పుట్లో ఉన్నవాటితో మార్చండి.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
రెండు వరుసలు తరచుగా గందరగోళానికి గురవుతాయి ఎందుకంటే రెండూ టన్నెల్ను ప్రస్తావిస్తాయి. resolver కోసం నియమం క్లయింట్ టన్నెల్లోకి పంపే ట్రాఫిక్కు అనుమతిస్తుంది, అయితే SSH కోసం నియమం సర్వర్ అక్కడి నుండి పొందే ట్రాఫిక్కు అనుమతిస్తుంది; అవి వేర్వేరు మెషీన్లలో నివసిస్తాయి మరియు స్వతంత్రంగా విఫలమవుతాయి. అత్యంత మరచిపోయే వరుస రెండవది, ఎందుకంటే సర్వర్ పబ్లిక్ చిరునామాకు క్లయింట్ ట్రాఫిక్ అనుమతించబడే వరకు క్లయింట్ టన్నెల్ను నిర్మించలేదు. పై నుండి క్రిందకు పని చేయండి మరియు ప్రతి వైఫల్యానికి ఒక సంభావ్య కారణం ఉంటుంది.
నెట్టబడిన resolver కు దాని సొంత నియమం కావాలి
టన్నెల్ DNS మోసుకెళ్తుందా అనేది సర్వర్ ఏమి పంపుతుంది అనేదానిపై ఆధారపడి ఉంటుంది. resolver ఎంపికను నెట్టే సర్వర్ క్లయింట్ కాన్ఫిగరేషన్లో ప్రైవేట్ చిరునామాను ఇన్స్టాల్ చేస్తుంది, మరియు ఆ చిరునామా టన్నెల్ ద్వారా మాత్రమే రూట్ చేయబడుతుంది. సర్వర్ ఏమీ నెట్టకపోతే, క్లయింట్ ఇప్పటికే ఉన్న resolver ను ఉంచుకుంటుంది మరియు క్రింది నియమాలకు అనుమతించడానికి ఏమీ ఉండదు. ఏదైనా రాయడానికి ముందు నెట్టబడిన స్థితి మరియు ప్రస్తుత ప్రశ్న ఫలితాన్ని తనిఖీ చేయండి:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedస్థితి అవుట్పుట్ ఉపయోగించబడుతున్న resolver మరియు అది బంధించబడిన లింక్ను పేర్కొంటుంది, మరియు దాని వెనుక ఉన్న రూట్ శోధన ఆ చిరునామాకు ప్రశ్నను ఏ ఇంటర్ఫేస్ మోసుకెళ్తుందో చూపిస్తుంది. resolver వేరే లింక్పై కూర్చున్నప్పుడు, సమస్య firewall కంటే ముందుది మరియు ఏ నియమం సహాయపడదు. రెండూ టన్నెల్ విషయంలో ఏకీభవిస్తే, రెండు నియమాలు అవసరం, ఎందుకంటే చాలా ప్రశ్నలను UDP మోసుకెళ్తుంది మరియు సమాధానం కత్తిరించబడినప్పుడు TCP బాధ్యత తీసుకుంటుంది. రెండు విలువలను నమోదు చేయండి, ఎందుకంటే నియమాలు పేర్కొనేవి అవే:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'లోపలి మార్గానికి ముందు బయటి మార్గాన్ని తెరవండి
టన్నెల్ ఉనికిలోకి రాకముందు క్లయింట్ సర్వర్ పబ్లిక్ చిరునామాను చేరుకోవాలి, కాబట్టి దాని నియమం భౌతిక లింక్పై కూర్చుంటుంది మరియు మొదట తన స్థానంలో ఉండాలి. resolver ను అనుమతించి సర్వర్ను మరచిపోయే విధానం క్లయింట్ను టన్నెల్ నిర్మించలేని స్థితిలో వదిలేస్తుంది, మరియు ఆ లక్షణం సాధారణంగా kill switch పైకి నెట్టబడుతుంది. తర్వాత మీరు నిజంగా టన్నెల్ ద్వారా కోరుకున్న సేవలను అనుమతించండి, ఒకసారి ఒక సన్నని నియమం, ఇంటర్ఫేస్ మొత్తం తెరవడం బదులు. సన్నని నియమాలే తిరస్కరణ తన స్థానంలో కొనసాగగల కారణం.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'పరీక్షించేటప్పుడు క్రమం ముఖ్యం, ఎందుకంటే టన్నెల్ పైకి రావడానికి అనుమతించేది మొదటి నియమమే. దాన్ని జోడించి, కనెక్ట్ అయి, సేవా నియమాన్ని జోడించే ముందు టన్నెల్ పైన ఉందని నిర్ధారించుకోండి, ఎందుకంటే రెండూ ఒకేసారి చేస్తే వైఫల్యం ఏ సగం తప్పో ఏమీ చెప్పదు. పైన ఉన్న డాక్యుమెంటేషన్ చిరునామా స్థానంలో క్లయింట్ ఉపయోగించడానికి కాన్ఫిగర్ చేయబడిన ముగింపు బిందువును పెట్టండి.
ఉద్దేశపూర్వకంగా డిస్కనెక్ట్ చేసి క్లయింట్ వైపు పూర్తి చేయండి. తిరస్కరణ ఉద్దేశపూర్వకంగా మినహాయించిన ట్రాఫిక్ను ఇంకా తిరస్కరించాలి, ఎందుకంటే టన్నెల్ పైన ఉన్నప్పుడు సమాధానం ఇచ్చే resolver సందేహం వచ్చినప్పుడు తిరస్కరించే విధానంలో సగాన్ని మాత్రమే కవర్ చేస్తుంది.
కనెక్ట్ అయ్యే క్లయింట్ ఇంకా అంగీకరించబడలేదు
సర్వర్కు పరిగణించవలసిన దాని సొంత దిశ ఉంది, మరియు చేతిని కలిపే ప్రక్రియను పూర్తి చేసే క్లయింట్ సర్వర్ అతన్ని అంగీకరించే వరకు సర్వర్పై నడిచే ఏదీ చేరుకోలేడు. పబ్లిక్ శ్రోత నియమం టన్నెల్ ఉనికికి మాత్రమే అనుమతిస్తుంది; టన్నెల్ ట్రాఫిక్ను లోపలికి రానివ్వదు. సర్వర్పై ఇవి రెండు నియమాలు మరియు సేవ నిజంగా వింటున్నదా అనే ఒక తనిఖీ:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'నియమంలోని పూల్ సర్వర్ కేటాయించే పరిధికి సమానంగా ఉండాలి, మరియు టన్నెల్ సంఖ్య సర్వర్ సృష్టించిన దానితో సరిపోలాలి, ఎందుకంటే వేరే ఇంటర్ఫేస్ కోసం నియమం నియమం లేకపోవడం నుండి వేరు చేయలేము. limit పరిపాలనా పోర్టు కోసం ఉద్దేశపూర్వకం, ఎందుకంటే అది పునరావృత కనెక్షన్లను పరిమితి లేకుండా అంగీకరించడం బదులు పరిమితం చేస్తుంది. శ్రోత తనిఖీ మూసి ఉన్న పోర్టును పడవేసిన ప్యాకెట్ నుండి వేరు చేస్తుంది, అవి క్లయింట్ నుండి ఒకేలా కనిపిస్తాయి. సంఖ్యా నియమాలు కూడా పూర్తి చిత్రం కాదు: UFW యొక్క before నియమాలు మరియు చేతితో రాసిన ఏదైనా nftables లైన్ ముందుగా సరిపోతాయి మరియు జాబితా అనుమతిస్తున్నట్టు కనిపించే ప్యాకెట్ను కూడా ఇంకా తిరస్కరించగలవు.