Docker పోర్ట్ ప్రచురణ vs VPN: ప్రత్యుత్తరం ఎక్కడికి వెళ్తుంది

ప్రచురించిన కంటైనర్ రివర్స్ NAT కి ముందు తన స్వంత చిరునామా నుండి సమాధానం ఇస్తుంది. రెండు డిజైన్లు ఆ సమాధానాన్ని పబ్లిక్ మార్గంలో ఉంచగలవు, వేర్వేరు ఖర్చులతో.

పూర్తి టన్నెల్ VPN పైకి వచ్చిన తర్వాత కూడా హోస్ట్ SSH కి సమాధానం ఇస్తూనే ఉంటుంది, కానీ అదే మెషీన్‌లో Docker ద్వారా ప్రచురించిన సేవ మౌనమవుతుంది. వినేవాడిలో ఎలాంటి లోపం లేదు: కంటైనర్ నడుస్తోంది, పోర్ట్ మ్యాపింగ్ ఉంది, ప్యాకెట్ వస్తుంది. కంటైనర్ ఆరోగ్యంగా ఉంది, అభ్యర్థన నిజంగానే దానిని చేరుతుంది. తేడా ఏమిటంటే, Linux తన మార్గాన్ని ఎంచుకునేటప్పుడు సమాధానం ఎక్కడి నుండి మొదలవుతుంది అనేది, ఆ తేడానే క్రింది రెండు డిజైన్లలో మీకు ఏది కావాలో నిర్ణయిస్తుంది.

గమ్యం NAT ద్వారా ట్యూపుల్‌ను అనుసరించండి

ఒక హోస్ట్ తీసుకోండి 192.0.2.10 లో, అది TCP 2222 ను 172.30.240.5:22 లోని కంటైనర్‌కు ప్రచురిస్తుంది. 198.51.100.25 నుండి వచ్చిన అభ్యర్థన కంటైనర్‌ను చేరుకునే ముందే అనువదించబడుతుంది, కంటైనర్ తనలాగే సమాధానం ఇస్తుంది.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

హోస్ట్ మార్గ నిర్ణయం సమయంలో సమాధానం ఇంకా కంటైనర్ మూల చిరునామాను మోస్తుంది. రివర్స్ అనువాదం తర్వాత ప్రచురించిన ట్యూపుల్‌ను పునరుద్ధరిస్తుంది, అందుకే మార్గం ఎంచుకున్న అదే క్షణంలో ప్యాకెట్ తప్పుగా కనిపిస్తుంది.

హోస్ట్‌కు మాత్రమే ఉన్న నియమం దానిని ఎందుకు మిస్ అవుతుంది

WAN పట్టికను 192.0.2.10 నుండి వచ్చే ప్యాకెట్లకు మాత్రమే ఎంచుకునే నియమం హోస్ట్ యొక్క సొంత డీమన్‌లను కవర్ చేస్తుంది మరియు ఈ ఫార్వర్డ్ చేసిన సమాధానాన్ని పూర్తిగా మిస్ అవుతుంది. సమాధానంపై మూల చిరునామా 172.30.240.5, హోస్ట్ కాదు.

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

DNAT తర్వాత సరిపోలిక వేరే హుక్

Docker యొక్క ఫైర్‌వాల్ డాక్యుమెంటేషన్ ఇలా గుర్తిస్తుంది: సాధారణ వినియోగదారు ఫిల్టరింగ్ DNAT తర్వాత గమ్యాన్ని చూస్తుంది, కాబట్టి సాధారణ నియమంలో ప్రచురించిన పోర్ట్ 2222 ను సరిపోల్చడం కంటైనర్ పోర్ట్ 22 ను సరిపోల్చడం వంటిది కాదు. అసలు ట్యూపుల్ ముఖ్యమైతే, ఏ పోర్ట్ కనిపిస్తుందో ఊహించడం బదులు మద్దతు ఉన్న అసలు-గమ్యం విధానాన్ని ఉపయోగించండి.

ఈ హుక్ గందరగోళం సరైనవిగా కనిపించే మరియు ఎప్పుడూ సరిపోలని నియమాలను సృష్టిస్తుంది. విధానాన్ని తిరిగి రాసే ముందు నియమంపైనే కౌంటర్లను తనిఖీ చేయండి. హిట్‌లు లేని నియమం, ప్యాకెట్ ఎప్పుడూ చేరని ప్రదేశంలో అది మూల్యాంకనం అవుతోందని మీకు చెబుతుంది.

డిజైన్ A: నిర్ణయాన్ని కనెక్షన్ స్థితిగా మోయండి

కనెక్షన్ మార్క్ ఇన్‌గ్రెస్ నిర్ణయాన్ని అనువాదం ద్వారా మోయగలదు, కానీ ముఖ్యమైన మార్గ శోధనకు ముందు దానిని ప్యాకెట్‌కు పునరుద్ధరించాలి. దశలు ఇవి:

  1. Docker, VPN లేదా మరొక విధాన యజమానితో ఢీకొనని మార్క్ ఫీల్డ్ మరియు నియమ ప్రాధాన్యతను కేటాయించండి.
  2. కనెక్షన్ ట్రాకింగ్ అందుబాటులో ఉన్న DNAT-పూర్వ బిందువు వద్ద ఉద్దేశించిన కొత్త WAN కనెక్షన్‌ను మాత్రమే గుర్తించండి.
  3. అసలు అభ్యర్థనను నేరుగా WAN పట్టికలోకి నెట్టకుండా నిర్ణయాన్ని కనెక్షన్ మార్క్‌పై నమోదు చేయండి.
  4. సమాధాన దిశలో, మార్గనిర్దేశనానికి ముందు మీ సొంత మార్క్ బిట్‌లను మాత్రమే ప్యాకెట్‌కు పునరుద్ధరించండి.
  5. VPN నియమం మొదట గెలవలేకుండా పూర్తి WAN పట్టికను తగినంత ముందుగానే ఎంచుకోండి.

ఆ పట్టికకు నిజమైన కనెక్ట్ అయిన మార్గాలు మరియు గేట్‌వే అవసరం. మార్గం లేనప్పుడు నిర్వచించిన ప్రవర్తన కూడా అవసరం. టన్నెల్‌లోకి నిశ్శబ్దంగా పడిపోవడం అత్యంత దుర్భర ఫలితం, ఎందుకంటే కాన్ఫిగరేషన్ ఇంకా పని చేస్తున్నట్టే కనిపిస్తుంది. బదులుగా మూసివేసిన రూపంలో విఫలమై దాన్ని లాగ్ చేయండి.

డిజైన్ B: హోస్ట్‌పై ముగించండి

కంటైనర్ ముందు TCP ప్రాక్సీ లేదా రివర్స్ ప్రాక్సీ వంటి ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేసిన హోస్ట్-వైపు ఫ్రంటెండ్, సమాధానం హోస్ట్ చిరునామా నుండి వస్తున్నట్టే ఉంచుతుంది. అప్పుడు హోస్ట్ కోసం రాసిన నియమాలు ఆశించినట్టు ప్రవర్తిస్తాయి, కంటైనర్ తన ప్రైవేట్ నెట్‌వర్క్‌లోనే ఉంటుంది.

ఖర్చు అంటే తన సొంత కాన్ఫిగరేషన్, మూల-చిరునామా నిర్వహణ మరియు యాక్సెస్ నియంత్రణలు ఉన్న మరో కదిలే భాగం. ఇది సాధారణంగా సరళమైన మద్దతు ఉన్న పరిమితి, మరియు మార్గనిర్దేశన విధానాన్ని వదిలి వెళ్లగల ఒక వ్యక్తి నిర్వహించాల్సి వస్తే ఇదే తరచుగా సరైన సమాధానం.

మార్పును ధృవీకరించండి, ఉద్దేశాన్ని కాదు

పబ్లిక్ వైపు నుండి కొత్త అధికృత కనెక్షన్ తెరిచి, సమాధానం ఉద్దేశించిన ఇంటర్‌ఫేస్ ద్వారా బయటకు వెళ్తున్నట్టు నిర్ధారించండి. తర్వాత కంటైనర్ ప్రారంభించిన సంబంధం లేని అభ్యర్థన ఇంకా VPN ను అనుసరిస్తోందా అని తనిఖీ చేయండి.

ఒక నియమాన్ని పరీక్షించడానికి మెషీన్ కనెక్షన్ పట్టికను ఫ్లష్ చేయవద్దు: ఉన్న ఎంట్రీలు వాటి మునుపటి మ్యాపింగ్‌ను నిలుపుకుంటాయి, ఫ్లష్ హోస్ట్‌పై మిగతా అన్నింటినీ పాడు చేస్తుంది. పోర్ట్ ప్రచురించడం చేరుకోగల సామర్థ్యాన్ని నిర్వచిస్తుంది. అది సమాధాన మార్గాన్ని నిర్వచించదు. ఎంచుకున్న డిజైన్‌ను దాని పట్టిక పేర్లతో రాసి ఉంచండి, సంఘటన సమయంలో తదుపరి వ్యక్తి దాన్ని మళ్లీ కనుగొనకుండా.

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