OpenBSD VPN గేట్‌వేలో tun0 ద్వారా LAN కు NAT

ఒకే OpenBSD గేట్‌వే ఉన్న ఇద్దరు ఇంజనీర్లు దూర నెట్‌వర్క్ చేరుకోవడానికి తరచుగా రెండు వేర్వేరు నియమ సముదాయాలను ఇస్తారు, రెండింటినీ సమర్థించవచ్చు. మూల అనువాదం మరియు తిరిగి వెళ్లే మార్గం మధ్య ఎంపిక అసలు వాక్య నిర్మాణ ప్రశ్న కాదు. ఎదురు వైపు 192.168.88.0/24 గురించి ఇప్పటికే ఏమి తెలుసు, మీ లాగ్‌లలో ఏమి ఉంచాలి అనే దానిపై ఆధారపడి ఉంటుంది. ఇక్కడ తప్పు చేస్తే nat-to లైన్ పూర్తిగా సరిగ్గా కనిపిస్తుంది, కానీ ప్రతిస్పందనలు దూర డిఫాల్ట్ గేట్‌వేలో మాయమవుతాయి.

రూటింగ్ మరియు పునర్లేఖనం వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి

172.20.0.0/16 tun0 ద్వారా చేరుకోగలదని రూటింగ్ పట్టిక నిర్ణయిస్తుంది, ఆ నిర్ణయం ఏదైనా pf అనువాదాన్ని సంప్రదించక ముందే జరుగుతుంది. తర్వాత మూల అనువాదం ప్యాకెట్ శీర్షికను మారుస్తుంది, తద్వారా దూర చివర LAN హోస్ట్‌కు బదులు గేట్‌వే సొరంగ చిరునామాను చూస్తుంది. ఏ యంత్రాంగం మరొకదాన్ని భర్తీ చేయదు: nat నియమం మార్గాన్ని సృష్టించలేదు, మార్గం మీ ప్రైవేట్ సబ్‌నెట్ గురించి ఎప్పుడూ వినని దూర రూటర్‌ను ఒప్పించలేదు. ఎదురు వైపు తిరిగి వెళ్లే మార్గం లేకపోతే ప్రతిస్పందనలు విస్మరించబడతాయి లేదా దాని డిఫాల్ట్ గేట్‌వేకు పంపబడతాయి, నియమాలను ఎంత సర్దుబాటు చేసినా అది సరికాదు.

సరళంగా చెప్పాలంటే, ఫార్వార్డింగ్ ట్రాఫిక్ ఎక్కడికి వెళ్తుందో సమాధానం ఇస్తుంది, అనువాదం అది ఎక్కడి నుండి వస్తున్నట్టు కనిపిస్తుందో సమాధానం ఇస్తుంది. నియమ సముదాయాన్ని రూపకల్పన చేస్తున్నప్పుడు రెండింటినీ వేర్వేరు మానసిక పెట్టెల్లో ఉంచండి.

నిర్ణయించే మూడు షరతులు

మూడు ప్రశ్నలను వరుసగా అడగండి, రూపకల్పన సాధారణంగా తనే ఎంపిక చేసుకుంటుంది. దూర నెట్‌వర్క్‌లో 192.168.88.0/24 కోసం సొరంగ చిరునామా వైపు చూపే స్థిర మార్గం ఉందా, లేదా దాని నిర్వాహకుడు ఆ మార్గంలోని రూటర్లను నియంత్రిస్తున్నాడా? అవును అయితే, LAN చిరునామాలు మార్పు లేకుండా వెళ్లనివ్వండి మరియు అనువాదాన్ని పూర్తిగా దాటవేయండి. ఎదురు వైపు ప్రతి క్లయింట్‌కు కనిపించడం అవసరమా, ప్రాప్యత విధానానికి లేదా ఆడిట్ జాడకు? అవసరమైతే, మూలాన్ని కాపాడుకోవడం రూటింగ్ పనికి తగినది. సొరంగ చిరునామా దూర మార్గంలో రాయడానికి స్థిరంగా ఉందా, లేదా పునఃకనెక్షన్ల మధ్య మారుతుందా?

ఏదైనా సమాధానం కాదు లేదా తెలియనిది అయితే, nat-to ఆచరణాత్మక ఎంపిక, అది తిప్పికొట్టగలిగేది కూడా. ఎదురు వైపు సరైన మార్గాన్ని జోడించగానే అనువాద నియమం ఒకే లైనులో బయటకు వెళ్తుంది. ఎప్పుడూ ఇన్‌స్టాల్ చేయని తిరిగి వెళ్లే మార్గం, సొరంగం ఒకే దిశలో ఎందుకు పనిచేస్తుంది అని ఎవరైనా అడిగిన ప్రతిసారీ ఒక మద్దతు దారాన్ని తింటుంది.

pf నిజంగా మూల్యాంకనం చేసేలా భాగాన్ని ఉంచండి

క్రింది భాగం LAN 192.168.88.0/24, దూర నెట్‌వర్క్ 172.20.0.0/16 మరియు సొరంగ ఇంటర్‌ఫేస్ tun0 అని ఊహిస్తుంది. అందులో తదుపరి అడుగును ఎంచుకునేది ఏమీ లేదు. ఇప్పటికే సొరంగం ద్వారా బయటకు వెళ్తున్న ప్యాకెట్లలో మూలాన్ని మాత్రమే పునర్లేఖిస్తుంది.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

ఆ మొదటి లైన్‌లోని రెండు వివరాలు ఎక్కువ బరువు మోస్తాయి. tun0 చుట్టూ ఉన్న కుండలీకరణాలు, స్థితి నమోదు నిర్మించిన ప్రతిసారీ ఇంటర్‌ఫేస్ చిరునామాను చదవమని pf కి చెబుతాయి, పునఃకనెక్షన్ తర్వాత సొరంగం మళ్లీ నంబర్ చేయబడినప్పుడు ఇది ముఖ్యం. match అనే పదం నియమం పునర్లేఖించి ఆపై క్రిందకు పడిపోతుందని అర్థం, కాబట్టి ప్రత్యేక pass నియమం ఇంకా ప్రవాహాన్ని అనుమతించాలి. match లైన్‌లో పేర్కొన్న ఇంటర్‌ఫేస్ కూడా రూటింగ్ పట్టిక ఎంచుకునేదే ఉండాలి, లేకపోతే pf నియమాన్ని ప్యాకెట్ నిజంగా వెళ్లే మార్గం కాకుండా వేరే నిష్క్రమణ మార్గంలో మూల్యాంకనం చేస్తుంది.

కర్నెల్ వైపు మరవద్దు. IPv4 ఫార్వార్డింగ్ ప్రారంభించబడాలి, సొరంగం మరియు LAN కోసం స్థితిగల pass నియమాలు ఇవన్నీ అర్థవంతం కాకముందే ఉండాలి. ఇక్కడ కీవర్డ్ క్రమానికి OpenBSD FAQ లోని PF NAT విభాగం సరైన సూచన.

ట్రాఫిక్‌ను నమ్మకముందు నియమ సముదాయాన్ని ధృవీకరించండి

మొదట pfctl -nf /etc/pf.conf తో వాక్య నిర్మాణాన్ని తనిఖీ చేయండి, అది ఫైల్‌ను లోడ్ చేయకుండా విశ్లేషిస్తుంది. తర్వాత విధానాన్ని లోడ్ చేసి కర్నెల్ నిజంగా ఏమి ఉంచుకుందో తిరిగి చదవండి, ఎందుకంటే శుభ్రంగా విశ్లేషించబడిన నియమం కూడా నీడపడవచ్చు లేదా తప్పు ఇంటర్‌ఫేస్‌కు జోడించబడవచ్చు. pfctl -sn అనువాద నియమాలను అవి లోడ్ అయిన రూపంలో ముద్రిస్తుంది, pfctl -sr ఫిల్టర్ నియమాలను మూల్యాంకన క్రమంలో ముద్రిస్తుంది.

తర్వాత తీగను గమనించండి. గేట్‌వేలో tcpdump -ni tun0 'host 172.20.0.10' సొరంగం నుండి బయటకు వెళ్లే మూల చిరునామా సొరంగ చిరునామా అా LAN హోస్ట్ అా అని చూపిస్తుంది. శీఘ్ర netstat -rn -f inet గమ్యం ఏ ఇంటర్‌ఫేస్‌కు పరిష్కరించబడుతుందో నిర్ధారిస్తుంది. ట్రాఫిక్ ప్రవహించడం ప్రారంభమైనప్పుడు pfctl -ss స్థితి నమోదులను జాబితా చేస్తుంది; ప్రవాహం స్థితిని సృష్టించకపోతే, ప్యాకెట్ స్థితిని సృష్టించే నియమాన్ని ఎప్పుడూ తాకలేదు.

సొరంగ వైపు సరిగ్గా కనిపించినా ప్రతిస్పందనలు రాకపోతే, pf ను సవరించడం ఆపండి. మిగిలిన వైఫల్యం దూర రూటర్‌లో ఉంది, అక్కడ ప్రతిస్పందన ఆ వైపు చేరుకోలేని ప్రైవేట్ చిరునామా వైపు పంపబడుతోంది.

అనువాదం ఆదాకు మించి ఖర్చు అయినప్పుడు

అనువాదం క్లయింట్లను దాచుతుంది, కొన్నిసార్లు అదే తప్పు లావాదేవీ. ఒకదానిపై ఒకటి వచ్చే సబ్‌నెట్‌లు ఒక సందర్భం: ఎదురు వైపు లోపల కూడా 192.168.88.0/24 ఉపయోగిస్తే, LAN హోస్ట్‌లను గేట్‌వేగా చూపడం ఘర్షణను మెరుగుపరచడం బదులు మరింత దిగజారుస్తుంది. చిరునామా జత ద్వారా ట్రాఫిక్ ఎంచుకునే IPsec విధానాలు మరో సందర్భం, ఎందుకంటే భద్రతా విధాన డేటాబేస్ అనువాదానికి ముందే సరిపోల్చబడుతుంది మరియు మీరు పునర్లేఖించిన ప్యాకెట్‌ను ఎప్పుడూ చూడదు. ప్రతి వినియోగదారుకు బిల్ చేసే, పరిమితం చేసే లేదా ఆడిట్ చేసే ఏ అమరిక అయినా మూలం ఒకే చిరునామాకు కుప్పకూలిన క్షణంలో అవసరమైన గుర్తింపును కోల్పోతుంది.

తీసుకెళ్లగల pf ఉత్పన్నాలు వేరే ఉచ్చు. తమ సొంత నియమ ఫైళ్లను ఉత్పత్తి చేసే ఉత్పత్తులు NAT తమ ఇంటర్‌ఫేస్ ద్వారా కాన్ఫిగర్ అవుతుందని ఆశిస్తాయి, చేతితో సవరించిన భాగాలు తదుపరి రీలోడ్‌లో పైన రాయబడతాయి. match కీవర్డ్ ఉనికిలోకి రాకముందే రాసిన మార్గదర్శకాల నుండి కాపీ చేసిన నియమ సముదాయాలు ప్రస్తుత కర్నెల్‌లో లోడ్ కావు, కాబట్టి వాక్య నిర్మాణాన్ని పోర్ట్ చేసి ఊహించడం బదులు లోపాన్ని చదవండి.

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