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

అనువాదం తర్వాత ప్యాకెట్‌ను అనుసరించండి

10.90.0.0/24 క్లయింట్ పూల్ మరియు 10.90.0.1 టన్నెల్ చిరునామా తీసుకోండి. ఒక వంతెనపై రెండు కంటైనర్లు ఉన్నాయి: 192.0.2.2 VPN ను, 192.0.2.3 అప్లికేషన్‌ను నడుపుతాయి. క్లయింట్ 10.90.0.1:8080 కు కనెక్ట్ అవుతుంది, VPN కంటైనర్ నేమ్‌స్పేస్‌లోని DNAT నియమం దాన్ని అప్లికేషన్ యొక్క నిజమైన చిరునామా మరియు పోర్టుకు మళ్లీ రాస్తుంది. తర్వాత ఒక మార్గం ప్యాకెట్‌ను వంతెన గుండా పంపుతుంది. ఈ చిరునామాలు ఉదాహరణకు మాత్రమే, అమరిక పాకం కాదు.

అప్లికేషన్ నిజంగా వినే పోర్టు హోస్ట్‌పై ప్రచురించిన ఏ పోర్టు నుండైనా భిన్నంగా ఉండవచ్చు. రెండు సంఖ్యలు సరిపోతాయని ఊహించకుండా కంటైనర్ లోపలి శ్రోతను చదవండి.

అనుమతి ఫార్వర్డ్ మార్గానికి చెందుతుంది

VPN కంటైనర్‌కు IP ఫార్వర్డింగ్ మరియు క్లయింట్ పూల్, అప్లికేషన్ చిరునామా, ఉద్దేశించిన పోర్టుకు పరిమితమైన ఫార్వర్డింగ్ నిర్ణయం అవసరం. స్థాపిత ప్రత్యుత్తరాలకు వాటి స్వంత అనుమతి అవసరం. అసలు టన్నెల్ చిరునామాతో సరిపోలే నియమం DNAT తర్వాత సరిపోలదు, ఎందుకంటే గమ్యం ఇప్పటికే మారింది. INPUT అనుమతి ఇప్పుడు ఈ హోస్ట్‌ను ఉద్దేశించని ట్రాఫిక్‌కు తప్పు హుక్.

పరిధిని సన్నగా ఉంచండి: ఒక మూల పరిధి, ఒక గమ్యం, ఒక సేవ. సడలిన ఫార్వర్డింగ్ నియమాన్ని రాయడం సులభం, తర్వాత దాన్ని సమర్థించడం చాలా కష్టం.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker చైన్లు మీ కంటైనర్ చైన్లు కావు

కంటైనర్ నేమ్‌స్పేస్ లోపలి నియమాలు Docker హోస్ట్ నియమాలు కావు. ట్రాఫిక్ టన్నెల్ ఇంటర్‌ఫేస్ నుండి వంతెనకు దాటినప్పుడు, హోస్ట్ వంతెన ఫైర్‌వాల్ మరో నిర్ణయం తీసుకోవచ్చు. Docker iptables బ్యాకెండ్‌తో, పత్రీకరించిన ఫార్వర్డింగ్ చైన్లు మరియు DNAT తర్వాతి సరిపోలిక బిందువులే ఆ నిర్ణయం కనిపించే స్థలం.

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

తిరిగి వెళ్లే మార్గాన్ని ఉద్దేశపూర్వక ఎంపిక చేయండి

మూల చిరునామా నిలిచి ఉంటే, అప్లికేషన్ 10.90.0.x చూస్తుంది మరియు ప్రత్యుత్తరాలను VPN కంటైనర్ ద్వారా తిరిగి పంపాలి. లేకపోతే దాని సాధారణ Docker గేట్‌వే వాటిని టన్నెల్ లేని హోస్ట్‌కు పంపుతుంది. ప్రత్యామ్నాయం VPN కంటైనర్‌లో సన్నని మూల అనువాదం, అది ప్రత్యుత్తరాన్ని సులభతరం చేస్తుంది కానీ అప్లికేషన్ నుండి క్లయింట్‌ను దాచుతుంది. ఉద్దేశపూర్వకంగా ఎంచుకోండి మరియు ఏది ఎంచుకున్నారో రాయండి.

సాధారణ క్లయింట్ నుండి కొత్త అనుమతి పొందిన కనెక్షన్‌ను పరీక్షించి, సంబంధం లేని పోర్టులు మూసివేయబడి ఉండేలా నిర్ధారించుకోండి. ప్యాకెట్ మాయమైనప్పుడు, VPN నేమ్‌స్పేస్, అప్లికేషన్ నేమ్‌స్పేస్ మరియు అప్లికేషన్ స్వంత లాగ్‌ను పరిశీలించండి. వంతెన గేట్‌వేకు ping సేవకు అంగీకార పరీక్ష కాదు.

నియమాలను కంటైనర్ మద్దతు ఉన్న ప్రారంభ కాన్ఫిగరేషన్‌లో ఉంచండి, ఎందుకంటే మళ్లీ సృష్టించినప్పుడు ఇంటరాక్టివ్ మార్పులు మాయమవుతాయి. హోస్ట్ పోర్టు ప్రచురణ మరో బహిర్గత మార్గం మరియు సేవ టన్నెల్ ద్వారా చేరుకోగలదు అనే కారణంతో మాత్రమే అవసరం లేదు.

సంబంధిత వ్యాసాలు