ผู้ใช้ระยะไกลเข้าถึงไซต์ที่สองผ่านฮับ VPN ไม่ได้

ผู้ใช้ระยะไกลเชื่อมต่อกับฮับ เข้าถึงเซิร์ฟเวอร์ไฟล์บน LAN ของฮับเอง และทุกอย่างดูปกติ จากนั้นเปิดแชร์ที่ 10.20.0.50 ในสำนักงานใหญ่ ซึ่งฮับเข้าถึงผ่านอุโมงค์ไซต์-ทู-ไซต์แยกต่างหาก และหมดเวลา อุโมงค์ทั้งสองทำงานอยู่และตัวนับทั้งสองเพิ่มขึ้น ดังนั้นไม่มีอุโมงค์ใดเสีย การข้ามฮับคือการตัดสินใจกำหนดเส้นทางสามครั้งบนอุปกรณ์สามเครื่อง และ อุโมงค์บรรทุกเฉพาะคำนำหน้าที่สร้างขึ้นเพื่อมันเท่านั้นนี่คือลำดับที่ฉันตรวจสอบ และคำสั่งที่แสดงว่าแต่ละขั้นตอนเป็นจริงหรือไม่

การส่งผ่านต้องค้นหาสามครั้ง ไม่ใช่อุโมงค์เดียว

ทุกอุปกรณ์จับคู่คำนำหน้าที่ยาวที่สุดของตัวเองแล้วลืมมันไป โน้ตบุ๊กต้องส่ง 10.20.0.50 เข้าอุโมงค์แทนที่จะส่งไปยังเราเตอร์ท้องถิ่น ฮับต้องรับแพ็กเก็ตที่มาถึงอินเทอร์เฟซการเข้าถึงระยะไกลและส่งต่อให้อินเทอร์เฟซไซต์-ทู-ไซต์ สำนักงานใหญ่ต้องส่งคำตอบสำหรับที่อยู่ของผู้ใช้กลับผ่านอุโมงค์ ความล้มเหลวใด ๆ ในสามอย่างนี้ดูเหมือนกันในเบราว์เซอร์: ความเงียบ

นั่นคือเหตุผลที่การทดสอบแต่ละอุโมงค์แยกกันพิสูจน์ได้น้อยมาก การปิงที่อยู่ LAN ของฮับฝึกการตัดสินใจครั้งแรก และการปิงฮับจากสำนักงานใหญ่ฝึกครั้งที่สาม แพ็กเก็ตที่ล้มเหลวมีต้นทางเป็นพูลผู้ใช้และปลายทางเป็นไซต์ที่สอง ดังนั้นจดคำนำหน้าเหล่านั้นไว้ก่อน ที่นี่พูลคือ 10.80.0.0/24 LAN ของฮับคือ 10.10.0.0/24 และสำนักงานใหญ่คือ 10.20.0.0/24

ดันคำนำหน้าฝั่งไกลไปยังไคลเอนต์ระยะไกล

บนเซิร์ฟเวอร์การเข้าถึงระยะไกล OpenVPN ไคลเอนต์เรียนรู้เส้นทางเมื่อเชื่อมต่อ หากไม่มี push ไคลเอนต์ที่ใช้การแบ่งอุโมงค์จะส่ง 10.20.0.50 ไปยังเกตเวย์ของตัวเองและแพ็กเก็ตไม่เคยเข้าอุโมงค์

push "route 10.20.0.0 255.255.255.0"

เส้นทางที่ถูกดันจะมีผลเมื่อไคลเอนต์เชื่อมต่อ ดังนั้นผู้ใช้ที่ออนไลน์อยู่จะไม่เห็นอะไรจนกว่าจะเชื่อมต่อใหม่ ตรวจสอบบนไคลเอนต์: ip route get 10.20.0.50 บน Linux และ route print บน Windows ผลลัพธ์ควรระบุอินเทอร์เฟซของอุโมงค์

push ไม่ช่วยฮับ มันเป็นข้อความถึงไคลเอนต์ ไม่ใช่เส้นทางบนเซิร์ฟเวอร์และไม่ใช่อนุญาตให้ส่งต่อ ดังนั้นฮับที่มีบรรทัด push สมบูรณ์แบบก็ยังทิ้งโฟลว์ไปหนึ่งฮอปถัดมา นี่คือสาเหตุปกติที่ผู้คนสรุปว่า push ล้มเหลว

ให้ฮับมีเส้นทางออกจริง

ฮับต้องการฮอปถัดไปของตัวเองสำหรับคำนำหน้าของสำนักงานใหญ่ บนอุโมงค์ที่กำหนดเส้นทาง นี่คือเส้นทางธรรมดาผ่านอินเทอร์เฟซไซต์-ทู-ไซต์ และคำสั่งเดียวแสดงทั้งเส้นทางที่เลือกและต้นทางที่เลือก:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

เมื่อขาไซต์-ทู-ไซต์เป็น OpenVPN เอง เส้นทางสามารถอยู่ในคอนฟิกนั้นโดยใช้ที่อยู่ของอุโมงค์ของคู่เป็นเกตเวย์: route 10.20.0.0 255.255.255.0 172.30.0.2 เกตเวย์ไม่ใช่ตัวเลือกเสริม หากละไว้ ฮอปถัดไปจะตกไปที่ค่าเริ่มต้นของการนำไปใช้ ซึ่งแตกต่างกันระหว่างไคลเอนต์ระยะไกลเดียวและฮับที่มีหลายคู่

IPsec ที่อิงนโยบายแตกต่างออกไป: เคอร์เนลของฮับส่งแพ็กเก็ตไปยังเกตเวย์ LAN ปกติ และนโยบายดักจับตอนออกไป ดังนั้นเส้นทางอุโมงค์จึงไม่ทำอะไรเลยหรือพาทราฟฟิกอ้อมนโยบาย สังเกตต้นทางในคำสั่งข้างต้น เพราะ 10.10.0.1 แทนที่อยู่พูลหมายถึงเคอร์เนลเลือกที่อยู่ที่ฝั่งไกลจะปฏิเสธ iroute ก็ไม่ใช่คำตอบ มันบอกเซิร์ฟเวอร์ว่าไคลเอนต์ใดเป็นเจ้าของซับเน็ตหลังอุโมงค์ของตัวเอง ไม่ใช่จะส่งทราฟฟิกไปที่ใดสำหรับไซต์ที่สาม

ขยายฝั่งไกลไปถึงพูลผู้ใช้

สำนักงานใหญ่ครอบคลุม LAN ของฮับคือ 10.10.0.0/24 อยู่แล้ว พูลผู้ใช้เป็นคำนำหน้าที่สองและต้องอยู่ในซีเล็กเตอร์ด้วย ไม่เช่นนั้นจะไม่มีนโยบายใดครอบคลุมคำตอบที่ส่งไปยัง 10.80.0.25 คู่แต่ละรายระบุชุดคำนำหน้าคู่เดียวกันจากฝั่งของตน:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts ของอุปกรณ์หนึ่งคือ remote_ts ของอีกอุปกรณ์หนึ่งคัดลอกบล็อกของฮับไปยังสำนักงานใหญ่แล้วคู่จะกลับด้าน ดังนั้น SA ลูกจะไม่มีวันขึ้น

ไวยากรณ์เก่าของ ipsec.conf ใช้ leftsubnet ที่คั่นด้วยจุลภาค ความสัมพันธ์ด้านความปลอดภัยที่ทำงานอยู่เก็บซีเล็กเตอร์ที่เจรจาไว้ ดังนั้นสร้างอุโมงค์ใหม่หลังแก้ไข ซีเล็กเตอร์ที่เปลี่ยนเมื่อ 10:00 และทดสอบกับ SA ที่ขึ้นเมื่อ 09:40 ก็ยังล้มเหลว ขณะที่ไฟล์คอนฟิกดูถูกต้องตลอดเวลา

จากนั้นตรวจสอบฮอปสุดท้าย ip route get 10.80.0.25 ที่ปลายทางไกลควรชี้เข้าอุโมงค์ หากบริการใช้เราเตอร์ LAN เป็นเกตเวย์เริ่มต้น เราเตอร์นั้นก็ต้องการเส้นทางกลับด้วย ไม่เช่นนั้นคำตอบจะตายที่นั่น การรัน tcpdump -ni eth1 host 10.80.0.25 บนเซกเมนต์นั้นจะแสดงว่าคำตอบออกจากปลายทางหรือไม่

อนุญาตโฟลว์ที่ฮับ

ต้องเปิดการส่งต่อและอนุญาตเส้นทาง จำกัดกฎให้แคบลงเหลือสองคำนำหน้าแทนที่จะยอมรับทุกอย่างระหว่างอินเทอร์เฟซ

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

การกรองเส้นทางย้อนกลับคือความล้มเหลวเงียบข้าง ๆ: เมื่อสองขาอยู่บนอินเทอร์เฟซต่างกัน rp_filter=1 อาจทิ้งคำตอบในขณะที่ตัวนับของกฎอนุญาตไม่ขยับเลย เปรียบเทียบ iptables -vnL FORWARD ก่อนและหลังความพยายาม กฎที่ไม่เคยเพิ่มขึ้นนั้นไม่ถูกเข้าถึง ดังนั้นมองลงไปอีกชั้นแทนการเขียนใหม่

หากมีเพียงกลุ่มเดียวที่ต้องการส่งผ่าน ให้ใส่เส้นทางในไฟล์ต่อไคลเอนต์ภายใต้ client-config-dir แทนการขยาย push ทั่วโลก Source NAT บนฮับยังขจัดความจำเป็นของเส้นทางกลับฝั่งไกล แต่มันซ่อนที่อยู่ของผู้ใช้ ดังนั้นบันทึกของไซต์ไกลและกฎที่อิงที่อยู่จึงแยกผู้ใช้ไม่ออกอีกต่อไป

ตรวจสอบจากไคลเอนต์ แล้วย้อนกลับในลำดับตรงข้าม

ทดสอบพอร์ต TCP ไม่ใช่แค่ ICMP เพราะ ping อาจผ่านได้ในขณะที่บริการยังถูกบล็อก nc -vz 10.20.0.50 445 และ traceroute -n 10.20.0.50 จากไคลเอนต์แสดงว่าฮอปที่สองเป็นที่อยู่ของอุโมงค์ฮับหรือไม่ บนฮับ tcpdump -ni tun0 host 10.20.0.50 และตัวกรองเดียวกันบนอินเทอร์เฟซไซต์-ทู-ไซต์: คำขอทั้งสองแต่ไม่มีคำตอบทั้งคู่ย้ายปัญหาไปยังฝั่งไกล

จากนั้นทดสอบสิ่งที่ต้องถูกบล็อกต่อไป หากโฮสต์ที่พูลไม่ควรเข้าถึงตอบกลับด้วย แสดงว่าคุณเปิดมากกว่าการส่งผ่านและควรจำกัดกฎให้แคบลง ฮับที่ส่งต่อทุกอย่างไปยังทุกสาขาผ่านการทดสอบแรกและล้มเหลวในการทดสอบที่สอง

เก็บบัญชีการย้อนกลับไว้ เพราะมีสี่วัตถุที่เปลี่ยนและสามอย่างจำได้ง่าย: เส้นทางที่ถูกดัน เส้นทางของฮับ ซีเล็กเตอร์ และกฎไฟร์วอลล์ ยกเลิกตามลำดับย้อนกลับ สร้าง SA ใหม่ และให้ผู้ใช้หนึ่งรายเชื่อมต่อใหม่ การย้อนกลับบางส่วนทิ้งเส้นทางที่ชี้ไปยังอุโมงค์ที่ไม่ตรงกันอีกต่อไป และอ่านได้ยากกว่าความเงียบเดิม คู่มือ OpenVPN 2.6 เอกสาร push, route และ iroute สำหรับเวอร์ชันของคุณ