VPN వెలుపల ఒక స్థానిక వెబ్ సేవను మాత్రమే, పోర్టు ఆధారంగా మళ్లించండి
మూల-పోర్టు నియమం ఒక హోస్ట్ సేవను WAN ద్వారా బయటకు పంపగలదా, మిగిలిన హోస్ట్ VPNనే వాడుతూ ఉంటుందా, దాని ఖర్చు ఏమిటి అనేది నిర్ణయించండి.
ఒక హోస్ట్ సేవ భౌతిక ఎగువ లింకు ద్వారా ఇంటర్నెట్కు సమాధానం ఇవ్వాలి, మిషన్లోని మిగతావన్నీ టన్నెల్నే వాడుతూ ఉండాలి. విధాన ఆధారిత రూటింగ్ ఆ భారాన్ని మోయగలదా అనేది మూడు షరతులు నిర్ణయిస్తాయి, నియమం రాయడానికి ముందు ప్రతిదీ తనిఖీ చేయడం చవక. సేవ DNAT లేదా ముందుకు పంపిన పోర్టు వెనుక కాకుండా ఈ హోస్ట్పైనే ముగియాలి, VPN యొక్క స్వంత నియమాలు మినహాయింపును అనుమతించాలి, మీరు అభ్యర్థనను కాదు, సమాధానాన్ని సరిపోల్చాలి. మూడింటిలో ఏదైనా విఫలమైతే క్రింది ఆదేశాలు లోపం లేకుండా లోడ్ అవుతాయి, కానీ ఉపయోగకరమైనది ఏమీ చేయవు.
నియమం రాయడానికి ముందు మూడు షరతులను తనిఖీ చేయండి
DNAT ద్వారా పోర్టును ప్రచురించే కంటైనర్, లేదా పోర్టు ఫార్వార్డింగ్ వెనుక ఉన్న సర్వర్, ఈ హోస్ట్పై పుట్టని ప్యాకెట్లను సృష్టిస్తుంది. ఆ ప్యాకెట్లు ఫార్వార్డ్ అవుతాయి, కాబట్టి హోస్ట్-స్థానిక ఇన్పుట్ ఆధారంగా ఉన్న నియమం వాటిని ఎప్పటికీ చూడదు మరియు ట్రాఫిక్ డిఫాల్ట్ మార్గాన్నే తీసుకుంటూపోతుంది. కొనసాగించడానికి ముందు సేవ నిజంగా ఎక్కడ నడుస్తుందో నిర్ధారించండి, ఎందుకంటే ప్రజలు ఎక్కువగా తప్పు చేసే షరతు ఇదే.
రెండవ షరతు విధానం, యాంత్రికత కాదు. టన్నెల్ను దాటవేసే ఏ మార్గమైనా టన్నెల్ లక్ష్యానికి మినహాయింపు, నిర్వహించబడే హోస్ట్లో ఆ నిర్ణయం విధానాన్ని కలిగి ఉన్నవారిది, టైమౌట్ను డీబగ్ చేసే వ్యక్తిది కాదు.
సమాధానాన్ని సరిపోల్చండి, క్లయింట్ గమ్యస్థాన పోర్టును కాదు
TCP 443పై వినిపించే సర్వర్ సమాధానం మూల పోర్టు 443తో హోస్ట్ను విడిచిపోతుంది. అదే హోస్ట్లోని బ్రౌజర్ దూరపు HTTPS సైట్కు కనెక్ట్ అయ్యేటప్పుడు తాత్కాలిక మూల పోర్టును, గమ్యస్థాన పోర్టు 443నూ పంపుతుంది. రెండూ పోర్టు 443 ట్రాఫిక్, వాటిలో ఒకటి మాత్రమే WAN పట్టికను తీసుకోవాలి, అందుకే గమ్యస్థాన-పోర్టు సరిపోలిక తప్పు సగాన్ని పట్టుకుంటుంది.
సమాధానం దిశనే మీరు వేరు చేయగలరు. మూల పోర్టును సరిపోల్చండి, నియమాన్ని స్థానికంగా సృష్టించిన ప్యాకెట్లకు మాత్రమే పరిమితం చేయండి, అప్పుడు నియమం బ్రౌజర్ అభ్యర్థనలను తాకకుండా సేవ యొక్క స్వంత సమాధానాలను కవర్ చేస్తుంది.
నియమం దానివైపు చూపించే ముందు పూర్తి రిటర్న్ పట్టికను నిర్మించండి
ఖాళీ పట్టిక అంటే మార్గం లేదు, అది విరిగిన విధానం కంటే విరిగిన సేవలా కనిపిస్తుంది. మొదట దాన్ని నింపండి, హోస్ట్పై మరేదీ క్లెయిమ్ చేయని పట్టిక సంఖ్య, ప్రాధాన్యతతో:
ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100
సంఖ్యలను కాపీ చేయకుండా సజీవ హోస్ట్ నుండి చదవండి. ip -4 rule show ఏ ప్రాధాన్యతలు తీసుకోబడ్డాయో చెబుతుంది, ఇప్పటికే ఉన్న ప్రాధాన్యతపై నియమాన్ని జోడించడం విడివిడిగా సరిగ్గా కనిపించే రెండు నియమాల క్రమాన్ని నిశ్శబ్దంగా మారుస్తుంది.
ఇక్కడ నిజమైన పనిని రెండు ఎంపికదారులు చేస్తాయి. iif lo అంటే హోస్ట్ తానే సృష్టించిన ప్యాకెట్లను కెర్నల్ ఎలా నివేదిస్తుందో, కాబట్టి నియమం బయట నుండి వచ్చే ఫార్వార్డ్ ట్రాఫిక్ను అనుకోకుండా పట్టుకోలేదు. ipproto tcp sport 443 దాన్ని ఒక రవాణా, ఒక పోర్టుకు సంకుచితం చేస్తుంది, అది అవసరం అనుమతించినంత కఠినం. ప్రోటోకాల్ ఎంపికదారును తీసేస్తే నియమం UDP 443నూ పడుతుంది, అది వేరే ప్రవర్తన ఉన్న వేరే సేవ.
ప్రైవేట్ సమాధానాలను టన్నెల్ లోపలే ఉంచండి
అదే వినేవాడు ప్రైవేట్ వైపు క్లయింట్లకూ సమాధానం ఇస్తే, పట్టిక 100లో అన్నింటినీ పట్టుకునే WAN డిఫాల్ట్ ఆ సమాధానాలను ఎగువ లింకు ద్వారా తిరిగి పంపడానికి ప్రయత్నిస్తుంది. WAN డిఫాల్ట్ను అనుసరించకూడని ప్రైవేట్ ప్రిఫిక్స్లను జోడించండి, లేదా అవి తదుపరి విధాన నియమంలోకి పడనివ్వండి:
ip -4 route add table 100 throw 10.90.0.0/24
throw మార్గం ఈ పట్టికలో వెతకడం ముగించి ప్యాకెట్ను నియమాల జాబితాకు తిరిగి ఇస్తుంది, కాబట్టి తర్వాతి VPN విధానానికి అవకాశం లభిస్తుంది. అది తానే టన్నెల్లోకి ఏమీ రూట్ చేయదు, తర్వాత ఏ నియమానికీ సరిపోయే మార్గం లేకపోతే ప్యాకెట్ అయినా విఫలమవుతుంది; throw పరిష్కారం అని భావించకుండా తర్వాతి విధానాన్ని ధృవీకరించండి.
రివర్స్-పాత్ ఫిల్టరింగ్, హోస్ట్ ఫైర్వాల్ నియమాలు వచ్చే అభ్యర్థనపై ఇప్పటికీ వర్తిస్తాయి. ధృవీకరణను సడలించే ముందు వాటి నిజమైన తీర్పులను చూడండి, ఎందుకంటే రూటింగ్ మినహాయింపు rp_filter అసాధ్యమని భావించే తిరిగి వచ్చే మార్గాన్ని అంగీకరించేలా చేయదు.
TCP, తర్వాత QUIC, తర్వాత రీబూట్ పరీక్షించండి
అధీకృత బాహ్య క్లయింట్ నుండి ఒకటి, ప్రైవేట్ వైపు నుండి ఒకటి కనెక్షన్ తెరిచి, తర్వాత నిజమైన చిరునామాలు, పోర్టులతో సమాధాన వెతుకుడును పరిశీలించండి. బాహ్య సమాధానం పట్టిక 100 తీసుకుని ప్రైవేట్ సమాధానం తీసుకోకపోతే, విధానం మీరు అడిగినట్టే చేస్తోంది.
HTTP/3 UDP ద్వారా అందించబడుతుంది, TCP నియమంతో సరిపోలదు, కాబట్టి QUIC వినేవాడికి దాని స్వంత ఎంపికదారు అవసరం, లేకపోతే HTTPS పనిచేస్తున్నప్పుడూ అది టన్నెల్నే వాడుతుంది. మీరు నిలబడే నియమాలను ఇంటర్ఫేస్ను కలిగి ఉన్న భాగంలో సేవ్ చేయండి, మళ్లీ కనెక్ట్ అయిన తర్వాత లేదా DHCP పునరుద్ధరణ తర్వాత వాటిని నిర్ధారించండి. రీబూట్ తర్వాత పోటీ మేనేజర్ రన్టైమ్ మార్గాన్ని తీసేస్తే, అది మూలంలో సరిచేయాల్సిన యాజమాన్య సమస్య, పైన మరింత విస్తృత NAT నియమాలను జోడించడానికి కారణం కాదు.