คุณสามารถเชื่อมต่อกับ Amazon ElastiСache Redis นอก Amazon ได้หรือไม่


93

ฉันสามารถที่จะเชื่อมต่อกับElastiCacheเช่น Redis ใน VPCจากEC2 กรณี แต่ฉันต้องการทราบว่ามีวิธีเชื่อมต่อกับโหนด ElastiCache Redis ภายนอกอินสแตนซ์ Amazon EC2 หรือไม่เช่นจากการตั้งค่าการพัฒนาในพื้นที่ของฉันหรืออินสแตนซ์ VPS ที่ผู้ขายรายอื่นให้มา

ขณะนี้เมื่อลองจากการตั้งค่าในพื้นที่ของฉัน:

redis-cli -h my-node-endpoint -p 6379

ฉันจะหมดเวลาหลังจากผ่านไปสักระยะ

คำตอบ:


75

อัปเดต 2018

คำตอบก่อนหน้านี้ถูกต้องเมื่อเขียนอย่างไรก็ตามขณะนี้เป็นไปได้ด้วยการกำหนดค่าบางอย่างเพื่อเข้าถึงแคช redis จากภายนอกโดยใช้คำแนะนำตามการเข้าถึงทรัพยากร ElastiCache จากภายนอก AWS


คำตอบเก่า

ไม่คุณไม่สามารถทำได้โดยไม่ต้องใช้ 'เทคนิค' เช่นอุโมงค์ซึ่งอาจใช้ได้สำหรับการทดสอบ แต่จะฆ่าประโยชน์ที่แท้จริงของการใช้แคชที่รวดเร็วเป็นพิเศษด้วยเวลาแฝง / ค่าโสหุ้ยที่เพิ่มเข้ามา

คำถามที่พบบ่อยเก่าภายใต้วิธีการคือใช้ Amazon ElastiCache ภายใน VPC ที่แตกต่างจากการใช้มันนอก? :

ไม่อนุญาตให้เข้าถึงคลัสเตอร์ Amazon ElastiCache ภายในหรือภายนอก VPC จากอินเทอร์เน็ต

อย่างไรก็ตามภาษานี้ได้ถูกลบออกไปแล้วในคำถามที่พบบ่อยปัจจุบัน


1
ยังคงเป็นเช่นนี้อยู่หรือไม่? เอกสารไม่พูดแบบนี้อีกต่อไปพวกเขาอ้างว่า redis อยู่ภายใต้นโยบายกลุ่มความปลอดภัยมาตรฐาน แต่ฉันยังไม่สามารถเข้าถึงโหนด redis ของฉันได้ ตีที่ Ref เพิ่งย้าย: Amazon ElastiCache Nodes ที่ติดตั้งภายใน VPC ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตหรือจากอินสแตนซ์ EC2 ภายนอก VPC
metalaureate

7
ฉันรู้สึกว่า 'ฆ่า' ค่อนข้างแรง ตัวอย่างเช่นเราไม่ได้รับผลกระทบด้านประสิทธิภาพเมื่อเรียกใช้แอปของเรานอก AWS (ผ่านอุโมงค์ดังกล่าว) ค่าโสหุ้ยของอุโมงค์มีขนาดเล็กเมื่อเทียบกับการดำเนินการ DB โหลดเบราว์เซอร์ดิสก์ I / O และอื่น ๆ
59


97

การส่งต่อพอร์ต SSH ควรทำเคล็ดลับ ลองเรียกใช้สิ่งนี้จากลูกค้าของคุณ

ssh -f -N -L 6379:<your redis node endpoint>:6379 <your EC2 node that you use to connect to redis>

จากลูกค้าของคุณ

redis-cli -h 127.0.0.1 -p 6379

มันใช้ได้กับฉัน

โปรดทราบว่าพอร์ตเริ่มต้นสำหรับ Redis เป็นไม่ได้6379 6739และตรวจสอบให้แน่ใจว่าคุณอนุญาตให้อนุญาตกลุ่มความปลอดภัยของโหนด EC2 ที่คุณใช้เพื่อเชื่อมต่อกับอินสแตนซ์ redis ของคุณในกลุ่มความปลอดภัยแคชของคุณ

นอกจากนี้ AWS ยังสนับสนุนการเข้าถึงคลัสเตอร์ของคุณข้อมูลเพิ่มเติมที่นี่


ขอขอบคุณที่ชี้ให้เห็นพอร์ตเพียงแค่พิมพ์ผิด คุณกำลังบอกว่า SSH tunneling ผ่าน EC2 เป็นวิธีเดียวในการเข้าถึงโหนด elasticache นอก Amazon หรือไม่? ขอบคุณ
Loic Duros

ถูกต้องเช่นเดียวกับที่ @EJBrennan กล่าวไว้ในคำตอบอื่น ๆ
Rico

เราจะเพิกถอนการส่งต่อพอร์ต ssh ได้อย่างไร ... ?
Muthukumar K

คุณสามารถฆ่ากระบวนการ ssh บน Linux: kill -9 <pid>
Rico

27

คำตอบเหล่านี้ล้าสมัย

คุณสามารถเข้าถึง elastic-cache ภายนอก AWS ได้โดยทำตามขั้นตอนเหล่านี้:

  1. สร้างอินสแตนซ์ NAT ใน VPC เดียวกันกับคลัสเตอร์แคชของคุณ แต่อยู่ในซับเน็ตสาธารณะ
  2. สร้างกฎกลุ่มความปลอดภัยสำหรับแคชคลัสเตอร์และอินสแตนซ์ NAT
  3. ตรวจสอบกฎ
  4. เพิ่มกฎ iptables ในอินสแตนซ์ NAT
  5. ตรวจสอบว่าไคลเอ็นต์ที่เชื่อถือได้สามารถเชื่อมต่อกับคลัสเตอร์ได้
  6. บันทึกการกำหนดค่า iptables

สำหรับคำอธิบายโดยละเอียดเพิ่มเติมโปรดดูคู่มือ AWS:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/accessing-elasticache.html#access-from-outside-aws


ฉันไม่ต้องการอินสแตนซ์ NAT ฉันต้องการตรวจสอบสักครู่ คำตอบของ Rico คือสิ่งที่ฉันต้องการ
Pysis

6

ไม่ใช่คำถามเก่า ๆ ฉันพบปัญหาเดียวกันด้วยตัวเองและแก้ไข:

ในบางครั้งด้วยเหตุผลในการพัฒนาที่คุณจำเป็นต้องเข้าถึงจากภายนอก (เพื่อหลีกเลี่ยงการปรับใช้หลายอย่างเพียงเพื่อการแก้ไขข้อบกพร่องอย่างง่าย)

Amazon ได้เผยแพร่คู่มือใหม่ที่ใช้ EC2 เป็นพร็อกซีสำหรับโลกภายนอก:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/accessing-elasticache.html#access-from-outside-aws

โชคดี!


3
สำหรับการอ้างอิงแนวทางที่ Amazon กล่าวถึงคืออินสแตนซ์ NAT
russellpierce

FYI จากเอกสาร: "ควรใช้แนวทางนี้เพื่อการทดสอบและพัฒนาเท่านั้นไม่แนะนำให้ใช้ในการผลิต"
jasonjonesutah

1
ใช่นั่นเป็นความจริง @jasonjonesutah ฉันได้พูดถึงสิ่งนี้ในคำตอบของฉันด้วย เป็นความคิดที่แย่มากสำหรับการผลิต แต่ยอดเยี่ยมสำหรับการพัฒนา
Shay Elkayam

4

เรากำลังใช้ HAProxy เป็นพร็อกซีเซิร์ฟเวอร์ที่สงวนไว้

ระบบของคุณภายนอก AWS ---> อินเทอร์เน็ต -> HAProxy พร้อม IP สาธารณะ -> Amazon Redis (Elasticache)

สังเกตว่ามีอีกเหตุผลที่ดีที่จะทำเช่นนั้น (ในเวลานั้น)

เนื่องจากเราใช้ไคลเอนต์ node.js ซึ่งไม่รองรับ Amazon DNS ล้มเหลวไดรเวอร์ไคลเอ็นต์จะไม่รองรับ DNS ค้นหาอีกครั้ง หาก redis ล้มเหลวไดรเวอร์ไคลเอ็นต์จะเชื่อมต่อกับมาสเตอร์เก่าซึ่งเป็นทาสหลังจากล้มเหลว

ด้วยการใช้ HAProxy จะช่วยแก้ปัญหานั้นได้

ตอนนี้ใช้ไดร์เวอร์ ioredis ล่าสุดมันรองรับการล้มเหลวของ amazon dns


1
อัปเดตสำหรับ node.js ตอนนี้ ioredis รองรับ DNS ล้มเหลว หากคุณใช้ชื่อโฮสต์ DNS สามารถล้มเหลวโดยอัตโนมัติได้โดยไม่ต้องใช้ HAProxy
teddychan

4

BTW หากใครต้องการโซลูชัน windows EC2 ลองใช้สิ่งเหล่านี้ที่พรอมต์ DOS (บนเครื่อง windows EC2 ดังกล่าว):

เพื่อเพิ่มการส่งต่อพอร์ต

C: \ Users \ Administrator>netsh interface portproxy add v4tov4 listenport=6379 listenaddress=10.xxx.64.xxx connectport=6379 connectaddress=xxx.xxxxxx.ng.0001.use1.cache.amazonaws.com

เพื่อแสดงรายการพอร์ตที่ส่งต่อพอร์ต

C: \ Users \ Administrator>netsh interface portproxy show all

ฟังบน ipv4: เชื่อมต่อกับ ipv4:

ที่อยู่พอร์ตที่อยู่พอร์ต


10.xxx.128.xxx 6379 xxx.xxxxx.ng.0001.use1.cache.amazonaws.com 6379

เพื่อลบการส่งต่อพอร์ต

C: \ Users \ Administrator>netsh interface portproxy delete v4tov4 listenport=6379 listenaddress=10.xxx.128.xxx


3

นี่คือสคริปต์โหนดที่มั่นคงที่จะทำงานสกปรกทั้งหมดให้คุณ ผ่านการทดสอบและตรวจสอบแล้วว่าใช้งานได้จริง

https://www.npmjs.com/package/uzys-elasticache-tunnel

วิธีใช้การใช้งาน: uzys-elasticache-tunnel [options] [command]

คำสั่ง:

start [filename]  start tunneling with configuration file (default: config.json)
stop              stop tunneling
status            show tunneling status

ตัวเลือก:

-h, --help     output usage information
-V, --version  output the version number

ตัวอย่างการใช้งาน

  • start - uzys-elasticache-tunnel start ./config.json
  • หยุด - uzys-elasticache-tunnel stop
  • สถานะ - สถานะ uzys-elasticache-tunnel

1

ไม่สามารถเข้าถึงคลาสสิกคลัสเตอร์โดยตรงจากอินสแตนซ์ VPC ได้ วิธีแก้ปัญหาคือการกำหนดค่า NAT บนอินสแตนซ์คลาสสิก

NAT ต้องมีพร็อกซี tcp แบบธรรมดา

YourIP=1.2.3.4
YourPort=80
TargetIP=2.3.4.5
TargetPort=22

iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT \
--to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort

คุณให้คำตอบเดียวกันในโพสต์ที่กล่าวถึงด้านล่างด้วยซึ่งมีข้อกำหนดที่แตกต่างกัน มันสามารถทำงานในสถานการณ์ที่กำหนดได้อย่างไร ?? stackoverflow.com/questions/38066908/…
abby37

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.