VPN సబ్నెట్కు పోర్ట్ ఫార్వర్డింగ్పై SNATని వర్తింపజేయాలా?

రౌటర్ స్వంత VPN క్లయింట్ వెనుక ఉన్న హోస్ట్కు పోర్ట్ను ఫార్వర్డ్ చేయడం ఫైర్వాల్ సమస్యలా కనిపించే విధంగా విఫలమవుతుంది, ఎందుకంటే అభ్యర్థన స్పష్టంగా చేరుతుంది. సేవ కనెక్షన్ను నమోదు చేస్తుంది, క్లయింట్ వేచి ఉంటుంది, ఏదీ తిరిగి రాదు. గమ్యస్థాన అనువాదం తన పని చేసింది; తిరిగి వచ్చే ప్యాకెట్ కోల్పోయిన భాగం. రౌటర్లోని ఒక ఎంపిక మూల-NAT నియమం దీన్ని సరిచేస్తుంది, ఆసక్తికరమైన భాగం ఆ నియమం ఎంత ఇరుకైనది కాగలదో నిర్ణయించడం.

ప్రతిస్పందన వేరే మార్గం ఎందుకు తీసుకుంటుంది

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

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

నమ్మడానికి తగినంత ఇరుకైన మూల నియమం

దూర హోస్ట్ సమాధానం ఇచ్చే మూలంగా రౌటర్ను చేయండి. ఈ అమరికలో WAN చిరునామా 203.0.113.24, LAN 192.168.88.0/24, రౌటర్ టన్నెల్ చిరునామా 172.20.5.1, మరియు సేవ 172.20.5.40:8443 వద్ద సమాధానం ఇస్తుంది. క్రింది నియమం గమ్యస్థాన అనువాదం తర్వాతి ప్యాకెట్తో సరిపోతుంది, అందుకే ఇది ప్రజా చిరునామా బదులు అనువదించిన చిరునామాను పేర్కొంటుంది. అందులో ఏదీ క్లయింట్ చిరునామాపై ఆధారపడదు, అదే అసలు విషయం.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

ఎప్పుడు సర్వవ్యాప్త మాస్కరేడ్ నిజాయితీ ఎంపిక

రౌటర్ చాలా సేవలను అదే VPN సబ్నెట్కు ఫార్వర్డ్ చేస్తే, ప్రతి సేవకు నియమం ఎవరూ నిర్వహించని జాబితాగా మారుతుంది. టన్నెల్ ఇంటర్ఫేస్ నుంచి బయటకు వెళ్లే ప్రతిదాన్ని మాస్క్ చేయడం సరళమైనది మరియు ఊహించదగినది, దాని ధర ఏమిటంటే అసలు క్లయింట్ ఎదురు వైపు ప్రతి హోస్ట్ నుంచి దాచబడతాడు. అక్కడి లాగ్లు ఆరోపణకు ఉపయోగించకపోతే దాన్ని ఎంచుకోండి; ఉపయోగిస్తే ఇరుకైన నియమాన్ని ఉంచండి.

రెండు ఎంపికలు వేర్వేరుగా కూడా విఫలమవుతాయి. తప్పిపోయిన ఇరుకైన నియమం ఒక సేవను విరగ్గొడుతుంది; చాలా ఎక్కువ సరిపోలే విశాలమైన మాస్కరేడ్ ఇప్పటికే పని చేస్తున్న ట్రాఫిక్ను, రౌటర్ స్వంత బయటకు వెళ్లే కనెక్షన్లతో సహా, నిశ్శబ్దంగా తిరిగి రాయవచ్చు.

ప్రచురించే ముందు కౌంటర్లను తనిఖీ చేయండి

ఎప్పుడూ సరిపోలని నియమాలు ప్యాకెట్లను లెక్కించే వరకు పని చేసే నియమాల్లాగే కనిపిస్తాయి. ఏ క్లయింట్ కనెక్ట్ అయ్యే ముందు బైట్ కౌంటర్లతో పట్టికను తిరిగి చదవండి, తర్వాత LAN కాని నెట్వర్క్ నుంచి కనెక్ట్ అయ్యి మళ్లీ చదవండి. ఊహను వాస్తవంగా మార్చేది ఆ రెండు పఠనాలే. రెండోది కదిలిన తర్వాత మాత్రమే ఫార్వర్డ్ను ప్రచురించండి.

iptables -t nat -L POSTROUTING -v -n --line-numbers

నిజమైన కనెక్షన్ తర్వాత మూల నియమంపై సున్నా కౌంటర్ అంటే సరిపోలిక తప్పు, సాధారణంగా గమ్యస్థానం లేదా పోర్ట్ అనువాదం తర్వాతి ప్యాకెట్తో సరిపోలకపోవడం వల్ల. కౌంటర్ పెరిగినా క్లయింట్ ఇంకా సమయం మీరితే, తిరిగి వచ్చే మార్గం సరిచేయబడింది మరియు మరేదో ప్రతిస్పందనను పడేస్తోంది, కాబట్టి తర్వాత ఎదురు వైపు ఫార్వర్డ్ విధానాన్ని చూడండి. LAN లోపలి నుంచి హెయిర్పిన్ యాక్సెస్ వేరే సమస్య మరియు దానికి సొంత నియమం కావాలి, దీని మరింత విశాలమైన కూర్పు కాదు.