rsync ผ่าน VPN: พอร์ตเดมอน 873 กับโหมด SSH
พอร์ต 873 คือบริการภายในที่อุโมงค์ขนส่ง ไม่ใช่ตัวแทนของมัน แยกโหมดเดมอนออกจากโหมด SSH แล้วเปิดเฉพาะเส้นทางที่คุณใช้จริง
การอนุญาต TCP 873 บนอินเทอร์เฟซของอุโมงค์ไม่ได้ดัน rsync ให้ผ่าน OpenVPNและไม่ได้ทำให้ปลายทางอีกฝั่งยอมรับโมดูล อุโมงค์ขนส่งการเชื่อมต่อภายในซึ่งกฎของโปรโตคอลและปลายทางยังคงเหมือนเดิมทุกประการ ดังนั้นคำถามแรกจึงไม่ใช่จะเปิดพอร์ตใด แต่เป็นว่า rsync สร้างการเชื่อมต่อชนิดใด ทุกอย่างด้านล่างนี้ถือว่าอุโมงค์เปิดอยู่แล้วและเหลือเพียงบริการภายในที่ยังเป็นข้อสงสัย
ตัดสินใจว่า rsync สร้างการเชื่อมต่อใดจริง ๆ
อาร์กิวเมนต์ระยะไกลในคำสั่งมักตอบคำถามนั้นก่อนการเปลี่ยนแปลงไฟร์วอลล์ใด ๆ เครื่องหมายทวิภาคคู่หรือสคีมา URL เลือกเดมอน ขณะที่เครื่องหมายทวิภาคเดี่ยวหลังชื่อโฮสต์เลือกเชลล์ระยะไกล อ่านอาร์กิวเมนต์ที่คุณรันจริง ไม่ใช่ตัวในตัวอย่างของเอกสาร
ตัวเลือกเชลล์ระยะไกลแบบชัดเจนอาจเปลี่ยนคำตอบอีกครั้ง เพราะมันบอก rsync ว่าจะเริ่มโปรแกรมใดสำหรับการขนส่ง อ่านทั้งบรรทัดคำสั่ง รวมถึงสคริปต์ห่อที่สืบทอดมา ไม่ใช่แค่ส่วนโฮสต์
| Remote argument | What it opens |
|---|---|
rsync://vault.corp.internal/archive/ | rsync daemon, normally TCP 873 |
vault.corp.internal::archive/ | rsync daemon, normally TCP 873 |
[email protected]:/srv/archive/ | Remote shell, normally SSH on its configured port |
โหมดเดมอน: ที่อยู่ผูก โมดูล และพอร์ต
ในไวยากรณ์ของเดมอน ส่วนของพาธระบุชื่อโมดูลที่กำหนดค่าไว้ ไม่ใช่ไดเรกทอรีบนดิสก์ รหัสผ่านของโมดูลจะถูกตรวจสอบหลังจากการเชื่อมต่อได้รับการยอมรับแล้วเท่านั้น และโมดูลอาจเป็นแบบอ่านอย่างเดียวหรือซ่อนจากการแสดงรายการก็ได้ ลำดับนี้สำคัญเมื่อคุณอ่านข้อผิดพลาด เพราะการเชื่อมต่อที่ถูกปฏิเสธและโมดูลที่ถูกปฏิเสธเป็นความล้มเหลวในสองขั้นตอนที่ต่างกัน ไม่มีข้อความใดบอกอะไรเกี่ยวกับอุโมงค์เอง
เดมอนแบบสแตนด์อโลนสามารถผูกกับที่อยู่ของอุโมงค์ในไฟล์กำหนดค่าได้ ซึ่งทำให้มันอยู่ห่างจากอินเทอร์เฟซสาธารณะโดยไม่ต้องมีกฎไฟร์วอลล์ใด ๆ ค่าต้องมีอยู่เมื่อเดมอนผูก และตัวรับฟังที่เปิดใช้งานด้วยซ็อกเก็ตหรือจัดการโดย inetd อาจเพิกเฉยต่อค่านี้ทั้งหมด
address = 10.44.0.1
port = 873
[archive]
path = /srv/archive
read only = yesจากนั้นทดสอบกับที่อยู่ส่วนตัวแทนชื่อสาธารณะ ชื่อโฮสต์สาธารณะจะแปลงเป็นที่อยู่ WAN และเดินคนละเส้นทาง แม้เครื่องเดียวจะตอบทั้งสองอย่าง
rsync --list-only rsync://10.44.0.1/archive/โหมดเชลล์ระยะไกล: SSH ขนส่งการถ่ายโอน
ด้วยเครื่องหมายทวิภาคเดี่ยว rsync จะเริ่มโปรแกรมเชลล์ระยะไกลและพูดโปรโตคอลของมันผ่านช่องทางนั้น ดังนั้นบริการเดียวที่เข้าถึงได้คือ SSH บนพอร์ตใดก็ตามที่เซิร์ฟเวอร์รับฟัง เดมอนของ rsync ไม่เคยทำงาน พอร์ต 873 ไม่เกี่ยวข้อง และการตัดสินใจเข้าถึงกลายเป็นการตัดสินใจเรื่องบัญชี SSH เส้นทางระยะไกลจึงเป็นพาธจริงของระบบไฟล์ที่เชลล์อีกฝั่งตีความ นั่นคือเหตุผลที่การเปลี่ยนแปลงไฟร์วอลล์ที่มุ่งเป้าไปที่ 873 ไม่ได้ทำอะไรเลยสำหรับโหมดนี้
การออกแบบนั้นต้องใช้ บัญชีที่ได้รับอนุญาตและการตรวจสอบคีย์โฮสต์และสืบทอดนโยบายการพิสูจน์ตัวตนของ SSH เอง มักเป็นทางเลือกที่ดีกว่าเมื่อการถ่ายโอนต้องข้ามเครือข่ายที่ไม่น่าเชื่อถือ เพราะการเข้ารหัสเป็นของโปรโตคอลที่สร้างมาเพื่อสิ่งนี้ เดมอนที่ถามรหัสผ่านไม่ใช่สิ่งเดียวกัน
เปิดเฉพาะเส้นทางที่คุณเลือก
เมื่อกำหนดโหมดได้แล้ว อนุญาตบริการภายในเดียวบนอินเทอร์เฟซเดียวที่ขนส่งอุโมงค์ จำกัดกฎตามอินเทอร์เฟซ พูลต้นทาง และที่อยู่ปลายทาง เพื่อให้การเปลี่ยนแปลงการปฏิเสธโดยค่าเริ่มต้นในภายหลังไม่สามารถขยายมันได้อย่างเงียบ ๆ จากนั้นทบทวนลำดับกฎ เพราะกฎที่อนุญาตก่อนหน้าในเชนทำให้กฎที่แคบเป็นเพียงเครื่องประดับ
หากเดมอนทำงานบนเครื่องที่อยู่หลังเกตเวย์ VPN ไม่ใช่บนเกตเวย์เอง เกตเวย์ก็ต้องมีเส้นทางส่งต่อ และเป้าหมายต้องมีสิทธิ์และเส้นทางกลับของตัวเอง การเปิดพอร์ตเฉพาะบนเกตเวย์ให้การเชื่อมต่อที่ได้รับการยอมรับแล้วก็ไปไม่ถึงไหน
ตรวจสอบจากไคลเอนต์ด้วยโหมดและปลายทางเดียวกับที่คุณตั้งใจจะใช้ในโปรดักชัน การแสดงรายการที่สำเร็จพิสูจน์ตัวรับฟัง เส้นทาง และกฎพร้อมกัน การหมดเวลาชี้ไปที่เส้นทาง และการปฏิเสธชี้ไปที่ตัวรับฟัง
ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873