రెండు సైట్లు, ఒక సబ్నెట్, ఒక WireGuard హబ్: దీన్ని పని చేయించండి

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

అతివ్యాప్తి నిజమైన సమస్య ఎందుకు కాదు

WireGuard గమ్యం ఆధారంగా పంపుతుంది: ఒక peer యొక్క AllowedIPs ఏ peer ప్యాకెట్ను పొందుతుందో నిర్ణయిస్తాయి. రెండు peer ఒకేసారి 10.10.7.0/24 ప్రకటించలేవు, వాటిలో ఒకటి ప్రతి శోధనను గెలవకపోతే. ఇది peer పట్టిక లక్షణం, సొరంగం లక్షణం కాదు, అందుకే ఇక్కడ పరిష్కారం చిరునామా ప్రణాళిక, రూటింగ్ ఉపాయం కాదు.

ప్రణాళిక LAN ప్రకటనను పూర్తిగా ఆపడం. బదులుగా ప్రతి సేవకు alias ప్రకటించండి, ప్రతి సైట్కు ఒక చిరునామా, మరియు ప్రతి సైట్ గేట్వే ఆ aliasను దాని నిజమైన అనువర్తనంలోకి అనువదించనివ్వండి.

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

ప్రతి సైట్కు వినియోగదారు రూట్ చేయగల alias ఇవ్వండి

వినియోగదారు యంత్రం, హబ్ లేదా రెండు LANలలో ఏదైనా ఒకదానితో ఢీకొనని పరిధి నుండి చిరునామాలు ఎంచుకోండి. ఇక్కడ హబ్ 10.66.0.1, వినియోగదారు 10.66.0.10, గేట్వేలు 10.66.0.21 మరియు 10.66.0.22, రెండు aliasలు 10.77.1.20 మరియు 10.77.2.20. హబ్ ప్రతి aliasను దానిని కలిగి ఉన్న peer ద్వారా ప్రచురిస్తుంది, కాబట్టి ఒక aliasకు పంపిన బయలుదేరే ప్యాకెట్ సరిపోలే సైట్ ద్వారా మాత్రమే బయటకు వెళ్లగలదు:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

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

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

ప్రతి గేట్వే హబ్ను మరియు వినియోగదారు మూలాన్ని ప్రకటిస్తుంది, మరేమీ లేదు, కాబట్టి ఒక సైట్ ఎప్పుడూ మరో సైట్ LANను తెలుసుకోదు. Keepalive సైట్ అప్లింక్పై NAT మ్యాపింగ్ను నిర్వహిస్తుంది; అది ట్రాఫిక్కు అనుమతి ఇవ్వదు, మరియు ఏమి అంగీకరించాలో ఫైర్వాల్ ఇప్పటికీ నిర్ణయిస్తుంది. ఒక గేట్వే కాన్ఫిగరేషన్ను మరొకదానికి కాపీ చేయడం సరైనది, ప్రైవేట్ కీ, ఇంటర్ఫేస్ చిరునామా మరియు alias అన్నీ మారితే.

హబ్ తన రెండు peerల మధ్య ఏమి అనుమతించాలి

హబ్ తన సొంత రెండు peerల మధ్య ప్యాకెట్లను పంపుతుంది, ఇది forward గొలుసులోని నిర్ణయం, ఇన్పుట్ నిర్ణయం కాదు. ప్లాట్ఫారమ్ సాధారణ విధానంతో IPv4 ఫార్వార్డింగ్ను ప్రారంభించి, ఆపై డిజైన్కు అవసరమైన జతలకు మాత్రమే అనుమతి ఇవ్వండి.

క్రింది నియమం వినియోగదారుకు ఒక alias మరియు ఒక పోర్టుకు అనుమతి ఇస్తుంది, మరియు కనెక్షన్ ట్రాకింగ్ ద్వారా తిరిగి వచ్చే ట్రాఫిక్కు అనుమతి ఇస్తుంది. ఇది forward మార్గంలో మిగతావన్నీ విసర్జిస్తుంది, అదే ముఖ్యాంశం:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

రెండు వివరాలు పేర్కొనదగినవి, ఎందుకంటే అవి నిశ్శబ్ద వైఫల్యాలను కలిగిస్తాయి. ఒక ఆధార గొలుసులోని accept మరొకదానిలోని dropను భర్తీ చేయదు, కాబట్టి దీన్ని ఉన్న విధానంతో కలపండి, పక్కన లోడ్ చేయవద్దు. మరియు మూల చిరునామా వ్యక్తిని కాదు, పరికరాన్ని గుర్తిస్తుంది; అనువర్తన ధృవీకరణను నెట్వర్క్ అనుమతి నుండి వేరుగా ఉంచండి.

alias నిజమైన చిరునామా అయ్యే చోటు

సైట్ A 10.77.1.20 కోసం అభ్యర్థనను స్వీకరిస్తుంది, గమ్యాన్ని నిజమైన అనువర్తనంలోకి తిరిగి రాస్తుంది, మూలాన్ని తన LAN చిరునామాలోకి తిరిగి రాస్తుంది, తద్వారా సమాధానం సొరంగానికి మార్గం లేకుండా తిరిగి రాగలదు. రెండు అనువాదాలను ఒకే చోట చేయడం మిగతా నెట్వర్క్ను alias గురించి అజ్ఞానంగా ఉంచుతుంది. క్రింది నియమాలే పూర్తి యంత్రాంగం:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

తర్వాత సైట్ A యొక్క forward విధానం అనువదించిన ప్రవాహాన్ని సొరంగం ఇంటర్ఫేస్ నుండి LAN ఇంటర్ఫేస్కు, అలాగే తిరిగి వచ్చే దిశను అనుమతించాలి. forward hook గమ్యాన్ని గమ్య అనువాదం తర్వాత మరియు మూల పునర్లేఖనానికి ముందు చూస్తుంది, అందుకే నియమం నిజమైన అనువర్తన చిరునామాను పేర్కొంటుంది. ఒక నియమం ఏదీ సరిపోలనట్టు కనిపించిన ప్రతిసారీ ఆ రెండు hookలను ఇదే క్రమంలో చదవండి. aliasకు వ్యతిరేకంగా రాసిన forward నియమం ఎప్పటికీ సరిపోలలేదు, ఎందుకంటే ఆ hookలో alias ఇక లేదు.

సైట్ B దీన్ని తన సొంత alias మరియు సొంత కీతో పునరావృతం చేస్తుంది. ఇది సైట్ A యొక్క ప్రైవేట్ కీని తిరిగి ఉపయోగించకూడదు, ఎందుకంటే రెండు peer ఒకే గుర్తింపును పంచుకోవడం చూడటానికి కష్టమైన, ఫైల్ను కాపీ చేయడం ద్వారా సృష్టించడానికి సులభమైన కాన్ఫిగరేషన్ లోపం. రెండు గేట్వే పత్రాలను భిన్నంగా ఉండాల్సిన విలువలు తప్ప సమానంగా ఉంచండి, సమీక్షలో తేడా స్పష్టంగా కనిపిస్తుంది. కాపీ చేసిన ఫైలే ఆ లోపానికి సాధారణ మూలం.

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

ప్రచురిత రెండు పేర్లు ప్రతిస్పందిస్తాయని ఎలా నిరూపించాలి

ప్రతి aliasకు DNS పేరు ఇచ్చి, ఆ పేరుకు అనువర్తనాన్ని మరియు ధృవపత్రాన్ని కాన్ఫిగర్ చేయండి, ఎందుకంటే అనువాదం రీడైరెక్ట్లను లేదా పొందుపరచిన సంపూర్ణ URLలను తిరిగి రాయదు. ప్రతి సైట్కు ఒక పేరు ఉపయోగించండి, ధృవపత్రం అసమానత ఎప్పుడూ రూటింగ్ లోపంగా తప్పుగా అర్థం చేసుకోబడకుండా.

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

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

మొదటి ఆదేశంలో alias ఖాళీగా లేదా అనుకోని విధంగా ఉంటే, ఏ ఫైర్వాల్ నియమం ముఖ్యమయ్యే ముందే peer ఎంపిక తప్పు. alias సరైనదైనా పేరు ఇప్పటికీ విఫలమైతే, సమస్య DNS మరియు ధృవపత్రాలకు మారింది. రెండు పేర్లూ ప్రతిస్పందించి మూడో పోర్టు మూసి ఉంటే, డిజైన్ తాను చెప్పినట్లే చేస్తుంది: సన్నగా ప్రచురించిన రెండు సేవలు, విలీనమైన రెండు LANలు కాదు.