คู่มือ MikroTik IPsec Site-to-Site VPN

สรุป MikroTik IPsec site-to-site VPN เข้ารหัสทราฟฟิกระหว่างเครือข่ายทั้งสองฝั่ง — สำนักงานใหญ่กับสาขา, NOC กับไซต์เสาสัญญาณ — เพื่อให้เครื่องในแต่ละ LAN เข้าถึงอีกฝั่งได้เหมือนอยู่ในเครือข่ายเดียวกัน คู่มือนี้ตั้งค่าเราเตอร์ทั้งสองตัวบน RouterOS v7: peer IKEv2, identity ด้วยคีย์ที่แชร์ล่วงหน้า, proposal ของเฟส 2, policy ของอุโมงค์, กฎ NAT bypass ที่ทำให้ความพยายามครั้งแรกส่วนใหญ่ล้มเหลว รวมถึงกฎไฟร์วอลล์และการตรวจสอบที่ยืนยันว่าอุโมงค์ทำงานอยู่

MikroTik IPsec site-to-site VPN คืออะไร?

MikroTik IPsec site-to-site VPN คืออุโมงค์เข้ารหัสถาวรระหว่างเราเตอร์สองตัวที่รวม LAN สองวงที่แยกจากกันให้เป็นเครือข่ายเดียวที่เราต์ได้ในเลเยอร์ 3 โดยไม่ต้องให้เราเตอร์ตัวใดเปิดพอร์ตจัดการสู่อินเทอร์เน็ตสาธารณะ ต่างจาก VPN แบบเข้าถึงจากไคลเอนต์อย่าง WireGuard หรือ OpenVPN — ที่มีอุปกรณ์ผู้ดูแลเพียงเครื่องเดียวเชื่อมต่อเข้ามา — อุโมงค์ site-to-site จะเปิดทำงานตลอดเวลาและเชื่อมจากซับเน็ตถึงซับเน็ต: ทุกเครื่องหลังเราเตอร์ A เข้าถึงทุกเครื่องที่ได้รับอนุญาตหลังเราเตอร์ B ได้โดยอัตโนมัติ IPsec เหมาะกับงานนี้เพราะเป็นมาตรฐานเปิดที่ผู้ผลิตไฟร์วอลล์และเราเตอร์แทบทุกรายรองรับ ทำงานในเคอร์เนลของ RouterOS จึงให้ throughput ที่ดี และบน MikroTik มีมาให้ในตัวโดยไม่ต้องติดตั้งแพ็กเกจเพิ่ม

อุโมงค์สร้างขึ้นผ่านการเจรจาสองรอบ เฟส 1 (IKE) ยืนยันตัวตนระหว่างเราเตอร์ทั้งสองและสร้างช่องทางที่ปลอดภัย ส่วนเฟส 2 (IPsec) เจรจาคีย์ที่ใช้เข้ารหัสทราฟฟิกข้อมูลจริง ถ้าทั้งสองเฟสตรงกันทั้งสองฝั่ง อุโมงค์จะขึ้น แต่ถ้าอัลกอริทึมต่างกันเพียงตัวเดียวมันจะล้มเหลวแบบเงียบ ๆ — นี่คือเหตุผลที่ขั้นตอนด้านล่างรักษาความสมมาตรของทั้งสองฝั่งไว้

ก่อนเริ่มต้น

คุณต้องมีเราเตอร์ MikroTik สองตัวที่ใช้ RouterOS v7 แต่ละตัวมีที่อยู่ IP สาธารณะหรือชื่อโฮสต์ DDNS ที่ใช้งานได้ และซับเน็ต LAN สองวงที่ ไม่ทับซ้อนกัน คู่มือนี้ใช้ 192.168.10.0/24 ที่ไซต์ A และ 192.168.20.0/24 ที่ไซต์ B ถ้าทั้งสองไซต์ใช้ 192.168.88.0/24 การเราต์จะเป็นไปไม่ได้ — ต้องเปลี่ยนที่อยู่ฝั่งใดฝั่งหนึ่งก่อน เนื่องจาก IPsec ไวต่อความคลาดเคลื่อนของนาฬิกามาก ให้เปิด NTP บนเราเตอร์ทั้งสองตัวก่อนเริ่ม หากปลายทั้งสองฝั่งเวลาเคลื่อนออกจากกัน security associations จะหมดอายุและอุโมงค์จะหลุดอยู่เรื่อย ๆ

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

ขั้นตอนที่ 1: สร้าง profile และ peer ของ IKE

ที่ ไซต์ A ให้กำหนด profile ของเฟส 1 และชี้ peer ไปยังที่อยู่สาธารณะของไซต์ B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 คือ Diffie-Hellman กลุ่ม 14 — ค่าเริ่มต้นสมัยใหม่ที่มั่นคง exchange-mode=ike2 เลือกใช้ IKEv2 ซึ่งเร็วกว่าและทนทานกว่าโหมด main/IKEv1 แบบเดิม ทั้งสองฝั่งต้องใช้ค่า profile เดียวกันและโหมดแลกเปลี่ยนเดียวกัน

ขั้นตอนที่ 2: เพิ่ม identity (คีย์ที่แชร์ล่วงหน้า)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

ใช้รหัสลับแบบสุ่มที่ยาว และเก็บรักษาเหมือนที่คุณเก็บคีย์ SSH — ไม่ใช่ในข้อความแชท รหัสลับเดียวกันนี้ต้องใส่บนเราเตอร์ทั้งสองตัว

ขั้นตอนที่ 3: กำหนด proposal ของเฟส 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) หมายความว่าการต่ออายุคีย์แต่ละครั้งจะใช้วัสดุคีย์ชุดใหม่ ดังนั้นคีย์ที่ถูกเจาะจะไม่เปิดเผยทราฟฟิกในอดีต เช่นเดียวกับเฟส 1 อัลกอริทึมต้องตรงกันทั้งสองฝั่ง

ขั้นตอนที่ 4: สร้าง policy ของอุโมงค์

Policy บอก RouterOS ว่าจะเข้ารหัสทราฟฟิกใด — จาก LAN ในพื้นที่ไปยัง LAN ปลายทาง:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

tunnel=yes คือสิ่งที่ทำให้การเชื่อมต่อนี้เป็นแบบ site-to-site แทนที่จะเป็นโฮสต์ต่อโฮสต์: แพ็กเก็ตต้นฉบับจะถูกห่อทั้งก้อน ทำให้ LAN ทั้งสองวงสื่อสารกันได้อย่างโปร่งใส

ขั้นตอนที่ 5: เพิ่มกฎ NAT bypass (ขั้นตอนที่ทุกคนลืม)

ตรงนี้คือจุดที่ความพยายามครั้งแรกส่วนใหญ่ล้มเหลว เราเตอร์ของคุณมีกฎ masquerade อยู่แล้วซึ่งเขียนที่อยู่ต้นทางของทราฟฟิก LAN ขาออกใหม่ ถ้ากฎนั้นทำงานก่อน IPsec ปลายทางจะได้รับแพ็กเก็ตที่ต้นทางไม่ตรงกับ policy อีกต่อไปและจะทิ้งมันไป ให้เพิ่มกฎ accept ไว้ เหนือ masquerade เพื่อให้ทราฟฟิกที่มุ่งเข้าอุโมงค์ข้าม NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 วางกฎไว้บนสุดของเชน srcnat ซึ่งจำเป็นอย่างยิ่ง — กฎ bypass ที่วางไว้หลัง masquerade จะไม่ทำอะไรเลย

ขั้นตอนที่ 6: เปิดไฟร์วอลล์และตรวจสอบ

อนุญาตพอร์ต IKE และ NAT-T รวมถึงโปรโตคอล ESP ในเชน input เพื่อให้อุโมงค์สร้างการเชื่อมต่อได้ โดยเฉพาะถ้าไซต์ใดไซต์หนึ่งอยู่หลังอุปกรณ์ NAT อีกชั้น:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

จากนั้นยืนยันว่าอุโมงค์ทำงานอยู่:

/ip ipsec active-peers print
/ip ipsec policy print

อุโมงค์ที่สมบูรณ์จะแสดง peer ที่ใช้งานอยู่ และ policy ที่มีค่า ph2-state เป็น established การ ping สั้น ๆ จากเครื่องใน LAN หนึ่งไปยังเครื่องในอีก LAN หนึ่งพิสูจน์การเข้าถึงแบบครบวงจร

ทำการตั้งค่าแบบเดียวกันที่ไซต์ B

ทำซ้ำทุกขั้นตอนที่ไซต์ B โดยสลับที่อยู่: peer ชี้ไปยัง IP สาธารณะของไซต์ A ส่วน policy และ NAT bypass ใช้ src-address=192.168.20.0/24 และ dst-address=192.168.10.0/24 ส่วน profile, proposal, รหัสลับของ identity และโหมด IKEv2 ยังคงเหมือนเดิม เมื่อทั้งสองฝั่งตรงกัน เฟส 1 และเฟส 2 จะสำเร็จและอุโมงค์จะขึ้น

เคล็ดลับด้านความปลอดภัยและการดูแลระบบ

อัปเดต RouterOS อยู่เสมอ — รุ่นล่าสุดมีการแก้ไขที่เกี่ยวข้องกับการจับคู่ใบรับรอง peer ของ IPsec/IKEv2 ดังนั้นอุโมงค์ที่ใช้งานได้เมื่อไตรมาสก่อนควรถูกทดสอบใหม่หลังการอัปเกรดทุกครั้ง เลือกใช้ IKEv2 พร้อม PFS แทนค่าเริ่มต้นแบบเก่าของ IKEv1 เมื่อจำนวนอุโมงค์เพิ่มขึ้น ให้เปลี่ยนจากรหัสลับที่ใช้ร่วมกันไปเป็นการยืนยันตัวตนด้วยใบรับรองเท่าที่ทำได้ เพราะคีย์ที่แชร์ล่วงหน้าเพียงคีย์เดียวที่รั่วไหลจะกระทบทุกไซต์ที่ใช้คีย์นั้น และควรบันทึกสถานะอุโมงค์ไว้ในที่ที่คุณดูจริง ๆ เพราะลิงก์ site-to-site ที่ตายแล้วจะมองไม่เห็นจนกว่าจะมีคนพยายามเข้าถึง LAN ปลายทางแล้วเข้าไม่ได้

เมื่อดูแลอุปกรณ์จำนวนมาก อุโมงค์ IPsec ที่หลุดเงียบ ๆ หลังนาฬิกาไม่ตรงกันหรือ WAN สะดุด คือความผิดปกติแบบที่ลูกค้ามักรู้ก่อนคุณ MKController ปิดช่องว่างนี้: มันเฝ้าดูเราเตอร์ทุกตัวผ่านอุโมงค์ขาออกที่ปลอดภัยซึ่งไม่ต้องใช้ IP สาธารณะและไม่ต้องทำ port forwarding บนอุปกรณ์ เก็บสำรองการตั้งค่าแบบมีเวอร์ชันเพื่อให้คุณเปรียบเทียบและกู้คืนบล็อก IPsec ที่ใช้งานได้หลังการแก้ไขที่ผิดพลาด และเปิดทิกเก็ตเมื่อเกิดเหตุลิงก์ล่มได้ก่อนที่โทรศัพท์จะดัง สำหรับการตั้งค่าอุโมงค์เอง คู่มือของเราเรื่อง NAT บน MikroTik อธิบายกฎ masquerade ที่คุณกำลังข้ามอยู่ตรงนี้ และหากต้องการเข้าถึงเราเตอร์เพียงตัวเดียวแทนการเชื่อม LAN สองวง ดูที่ การจัดการระยะไกลหลัง CGNAT และคู่มือ การจัดการระยะไกลด้วย WireGuard ของเรา

รวมอุโมงค์ทั้งหมดไว้ในที่เดียว

IPsec เชื่อมสองไซต์ได้อย่างเรียบร้อย แต่ ISP หรือ MSP ที่กำลังเติบโตจะมีอุโมงค์ คีย์ และกฎไฟร์วอลล์นับสิบที่ต้องคอยซิงก์ให้ตรงกัน — และการแก้ไขด้วยมือทุกครั้งคือโอกาสที่จะล็อกตัวเองออกจากไซต์ปลายทาง MKController สร้างมาเพื่อสเกลแบบนี้โดยเฉพาะ: การจัดการอุปกรณ์แบบรวมศูนย์ การเข้าถึงระยะไกลที่ปลอดภัยโดยไม่ต้องเปิดพอร์ต ประวัติและสำรองการตั้งค่า และการส่งการเปลี่ยนแปลงกฎไฟร์วอลล์และ policy ไปทั้งระบบ ทำให้เทมเพลตอุโมงค์ถูกนำไปใช้ครั้งเดียวแทนที่จะพิมพ์ซ้ำทีละเราเตอร์ ผู้ให้บริการที่ใช้ MikroTik ในสเกลใหญ่ใช้มันเพื่อเปลี่ยนช่วงบ่ายที่เสียไปกับการ SSH ทีละเครื่อง ให้เหลือเพียงไม่กี่คลิกต่อการเปลี่ยนแปลงหนึ่งครั้ง

เริ่มทดลองใช้ MKController ฟรี