టన్నెల్ ద్వారా దూర /24 చేరుకోవడం: NETMAP, DNAT లేదా మార్గం?
NETMAP తో మొత్తం ప్రిఫిక్స్ మ్యాప్ చేయండి, ప్రతి హోస్ట్కు DNAT నియమాలు జోడించండి లేదా నిజమైన పరిధిని రూట్ చేయండి, మరియు దూర వైపు ఏమి చూడాలి, ఎవరు ట్రాఫిక్ ప్రారంభించగలరు అనే దాని ఆధారంగా నిర్ణయించండి.
టన్నెల్ ముగింపు బిందువు వెనుక ఉన్న ఉపవలయాన్ని మీరు మూడు విధాలుగా చేరుకోవచ్చు, మరియు ఒక నిమిషం వాస్తవాల సేకరణ సాధారణంగా రెండింటిని తొలగిస్తుంది. వాస్తవాలు: అక్కడి సర్వర్లు వినియోగదారులను వేరు చేయాలా, అక్కడి నుంచి ఎవరైనా ఎప్పుడైనా మీ పరిధికి కాల్ చేస్తారా, మరియు దూర రౌటర్ను ఎవరు సవరించగలరు. ఈ మూడింటికి సమాధానం చెప్పండి, రూపకల్పన తనంతట తానే ఎంపికవుతుంది. మిగిలినది మీరు ముగింపు బిందువును నిర్వహిస్తారని మరియు దాని firewall ను సవరించగలరని ఊహిస్తుంది.
మూడు ఎంపికలు, ప్రతి ఒక్కటి నిజంగా ఏమి మారుస్తుంది
ప్రిఫిక్స్ మ్యాపింగ్, ప్రతి హోస్ట్కు DNAT మరియు రూట్ చేయబడిన ప్రిఫిక్స్ అన్నీ ఒకే రెండు పరిధుల మధ్య ప్యాకెట్లను కదిలిస్తాయి, కానీ వేర్వేరు విషయాలను మారుస్తాయి. మ్యాపింగ్ అలియాస్ పరిధిని సృష్టించి ప్రయాణంలో చిరునామాలను గణితపరంగా తిరిగి రాస్తుంది. ప్రతి హోస్ట్ నియమాలు కూడా తిరిగి రాస్తాయి, కానీ ప్రతి గమ్యం చేతితో పేరు పెట్టబడుతుంది. రూట్ చేయబడిన ప్రిఫిక్స్ ఏమీ తిరిగి రాయదు: ప్యాకెట్లు నిజమైన చిరునామాలను నిలుపుకుంటాయి మరియు రెండు చివరలు ఆ చిరునామాలు ఎక్కడ ఉన్నాయో అంగీకరిస్తాయి.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
తొలగింపును దూర వైపు నుంచి ప్రారంభించండి, అక్కడ పరిమితులను మార్చడం అత్యంత కష్టం. అక్కడి సర్వర్ క్లయింట్ చిరునామాలను లాగ్లలో రాస్తే, అనుమతి జాబితాతో తనిఖీ చేస్తే లేదా మరొక వ్యవస్థకు అప్పగిస్తే, మూలాన్ని అనువదించడం దాని ఏకైక గుర్తింపును నాశనం చేస్తుంది. దూర వైపు కూడా లోపలికి కాల్ చేయాల్సి వస్తే, అనువాదం పూర్తిగా మినహాయించబడుతుంది, ఎందుకంటే అక్కడ అలియాస్ ఉన్నట్లు ఎవరికీ తెలియదు. దూర వైపు అభ్యర్థనలకు సమాధానం ఇచ్చినప్పుడు మాత్రమే చవకైన ఎంపికలు సురక్షితమవుతాయి.
ప్రిఫిక్స్ జంటలు, ఎందుకు పరిమాణాలు సరిపోలాలి
NETMAP అనేది ఒకే పొడవు గల ప్రిఫిక్స్ జంటపై పనిచేసే nat పట్టిక లక్ష్యం. లోపల ప్రతి చిరునామాకు పట్టిక లేదు: అది ప్రిఫిక్స్ను తీసివేసి, హోస్ట్ బిట్లను ఉంచి కొత్త ప్రిఫిక్స్కు తిరిగి జోడిస్తుంది, అందుకే /24 /24 పై మ్యాప్ అవుతుంది మరియు ఎప్పటికీ /25 పై కాదు. స్థానం దిశను నిర్ణయిస్తుంది: PREROUTING లో గమ్యం సరిపోలిక ప్యాకెట్ ఎక్కడికి వెళ్తుందో తిరిగి రాస్తుంది, POSTROUTING లో మూలం సరిపోలిక అది ఎక్కడి నుంచి వచ్చిందో తిరిగి రాస్తుంది.
192.168.2.17 లోని హోస్ట్ మీ క్లయింట్లకు 10.50.1.17 గా కనిపిస్తుంది, చివరి ఆక్టెట్ అలంకారం కాదు — అది రెండు వైపులా ఒకే సంఖ్య. రేపు 192.168.2.40 లో హోస్ట్ను జోడించండి, దాని అలియాస్ 10.50.1.40 అవుతుంది, సవరించాల్సిన నియమం లేదు.
క్లయింట్లకు అలియాస్ పరిధి కోసం మీ బాక్స్ వైపు చూపే మార్గం ఇంకా అవసరం, అలియాస్ వారు ఇప్పటికే చేరుకునే ఉపవలయంలో ఉంటే తప్ప. గేట్వేకు అలియాస్ కోసం మార్గం అవసరం లేదు, ఎందుకంటే గమ్యం అనువాదం మార్గ శోధనకు ముందు PREROUTING లో నడుస్తుంది. ఫార్వార్డింగ్ కూడా ఆన్ ఉండాలి, లేకుంటే తిరిగి రాసిన తర్వాత కర్నెల్ ప్యాకెట్ను విసిరివేస్తుంది. క్రింది మూడు ఆదేశాలు క్లయింట్లు br0 లో, అలియాస్ 10.50.1.0/24 లో, టన్నెల్ tun0 లో ఉన్న Debian శైలి గేట్వేపై మొత్తం సెటప్.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEసమాధానం తనంతట తానే తిరుగు మార్గాన్ని కనుగొనాలి
గమ్యాన్ని తిరిగి రాయడం ప్యాకెట్ ఎక్కడ పంపబడుతుందో మాత్రమే నిర్ణయిస్తుంది. దూర సర్వర్ ఇంకా తాను చేరుకునే చిరునామాకు సమాధానం ఇవ్వాలి, దాన్ని రెండు విధాలుగా ఏర్పాటు చేయవచ్చు. సమాధానాలు మీ బాక్స్కు తిరిగి వచ్చేలా మూలాన్ని అనువదించండి, లేదా మూలాన్ని వదిలి దూర వైపుకు క్లయింట్ పరిధి కోసం మార్గం ఇవ్వండి.
బయటికి వెళ్లే మార్గంలో masquerade చిన్న మార్గం: POSTROUTING లో ఒక నియమం మరియు దూర వైపు మీ టన్నెల్ చిరునామాను చూస్తుంది, కాబట్టి దానికి సొంత మార్గం అవసరం లేదు. ధర ఏమిటంటే ప్రతి వినియోగదారు ఒకే చిరునామాలో కుదించబడతారు, వినియోగదారు వారీ లాగ్లు అర్థం కోల్పోతాయి. మూలాన్ని అలాగే ఉంచితే ఆ సమాచారం నిలిచి ఉంటుంది, కానీ అప్పుడు దూర సైట్ క్లయింట్ పరిధి సమాధానాలను టన్నెల్ ద్వారా తిరిగి పంపాలి.OpenVPN సర్వర్లో అది push చేయబడిన push "route 10.50.9.0 255.255.255.0", అలాగే route 192.168.2.0 255.255.255.0 పంక్తి.
ఖరీదైన వైఫల్యం అంటే ప్రతి దానిలో సగం చేయడం. కొంత ట్రాఫిక్ను masquerade చేస్తూ దూర వైపు మరో ట్రాఫిక్ కోసం తిరుగు మార్గాన్ని కూడా మోస్తే, సమాధానాలు కనెక్షన్ ట్రాకింగ్ నమోదు ఎప్పుడూ కనిపించని ఇంటర్ఫేస్కు వస్తాయి. సర్వర్ సేవ చేసినట్లు నమోదు చేసిన అభ్యర్థనకు క్లయింట్ టైమ్అవుట్ నివేదిస్తుంది. ప్రవాహం యొక్క రెండు దిశలు ఒకే netfilter ఇన్స్టాన్స్ గుండా వెళ్లాలి: ఒక గేట్వే అనువదిస్తుంది, వరుసలో రెండు firewall లు కాదు.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nనమోదును రెండు దిశల్లో చదవండి: అసలు tuple గమ్యంలో మీ అలియాస్ను ఉంచుతుంది, సమాధాన tuple నిజమైన చిరునామాను మోస్తుంది. సమాధాన tuple లేకుంటే, సమస్య నియమం కాదు, తిరుగు మార్గం. PREROUTING కౌంటర్లు ఎప్పుడూ కదలకుంటే, ప్యాకెట్ ఆ hook ను ఎప్పుడూ చేరుకోలేదు.
ఢీకొనడాలు మరియు మొదట నడిచే శోధన
రెండు వేర్వేరు పరిధులు ఢీకొనవచ్చు, రెండు వైఫల్యాలు చెడ్డ నియమం కాకుండా విరిగిన టన్నెల్లా కనిపిస్తాయి. మీరు సృష్టించే అలియాస్ మొత్తం మార్గంలో ఉపయోగించబడకూడదు, నిజమైన దూర పరిధి మీ నెట్వర్క్లో ఇప్పటికే ఉండకూడదు. నకిలీ అప్పుడప్పుడు తప్పు హోస్ట్కు ట్రాఫిక్ను కలిగిస్తుంది, దాన్ని తిరస్కరించిన కనెక్షన్ కంటే నిర్ధారణ చేయడం కష్టం. నియమాన్ని జోడించే ముందు రూటింగ్ పట్టికను అడగండి.
గేట్వేలో, ip route get 192.168.2.17 టన్నెల్ పరికరాన్ని పేర్కొనాలి; స్థానిక bridge అంటే దూర పరిధి కప్పబడింది మరియు ఏ nat నియమం దాన్ని సరిచేయదు. మీ నెట్వర్క్ ఇప్పటికే 192.168.2.0/24 ఉపయోగిస్తుంటే, ఢీకొనడంపై మ్యాపింగ్ పోగుచేయడం బదులు దూర సైట్ను తిరిగి సంఖ్యీకరించండి.
నిజమైన క్లయింట్ నుంచి పరీక్షించి, తర్వాత నిలుపుకోవడం
అలియాస్ను నిజంగా ఉపయోగించే మెషీన్ నుంచి పరీక్షించండి, గేట్వే నుంచి కాదు, ఎందుకంటే స్థానికంగా ఉత్పత్తి అయ్యే ట్రాఫిక్ PREROUTING గుండా ఎప్పుడూ అదే విధంగా వెళ్లదు. అలియాస్ ఉన్న ఒక హోస్ట్కు కనెక్షన్ తెరిచి కౌంటర్లు మరియు conntrack నమోదు కలిసి కనిపించడాన్ని గమనించండి, తర్వాత మూసి నమోదు పోతున్నట్లు నిర్ధారించండి. పాత నమోదు సగం తెరిచిన కనెక్షన్ను సూచిస్తుంది, అంటే సాధారణంగా సమాధానం ఎప్పుడూ తిరిగి రాలేదని అర్థం.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17రెండు లేదా మూడు విజయవంతమైన కనెక్షన్లు గణితాన్ని నిరూపిస్తాయి, కానీ స్థిరత్వం లేదా తదుపరి ఇంజనీర్ గురించి ఏమీ చెప్పవు. నియమాలను బూట్ ప్రక్రియ చదివే చోట భద్రపరచండి, Debian మరియు Ubuntu లో అది iptables-save > /etc/iptables/rules.v4 netfilter-persistent ప్రారంభించిన స్థితిలో అని అర్థం. రీబూట్లో మాయమయ్యే మ్యాపింగ్ ఏమీ లేకపోవడం కంటే చెడ్డది, ఎందుకంటే అంతరాయం నిందించదగిన ఇటీవలి మార్పు లేకుండా వస్తుంది.
నియమాల పక్కన గమనికను విడిచిపెట్టండి: అలియాస్ పరిధి, నిజమైన పరిధి, జంటకు కారణం మరియు ఏ వైపు ప్రారంభించగలదు. ఆ గమనిక రూపకల్పనను ఎవరూ తొలగించడానికి సాహసించని నియమాల కుప్ప నుంచి వేరు చేస్తుంది. తర్వాత వచ్చే ప్రశ్నను కూడా అది పరిష్కరిస్తుంది: దూర సైట్ హోస్ట్ను జోడించినప్పుడు, ఎవరూ కాన్ఫిగర్ చేయని చిరునామా ఇప్పటికే సమాధానం ఇస్తుంది. గమనికలో దూర వైపుకు తిరుగు మార్గం అవసరమని ఉంటే, masquerade నియమాన్ని తొలగించడం కనెక్టివిటీని బద్దలు కొడుతుందని తదుపరి వ్యక్తికి తెలుస్తుంది. ఇక్కడ డాక్యుమెంటేషన్ చవక; రాత్రి మూడు గంటలకు NAT ఆధారాన్ని మళ్లీ కనుగొనడం చవక కాదు.