Tôi muốn chia sẻ kinh nghiệm của mình về việc kết hợp các mạng trong ba căn hộ cách xa nhau về mặt địa lý, mỗi căn hộ sử dụng bộ định tuyến với OpenWRT làm cổng, thành một mạng chung. Khi chọn phương pháp kết hợp mạng giữa L3 với định tuyến mạng con và L2 với cầu nối, khi tất cả các nút mạng sẽ nằm trong cùng một mạng con, phương pháp thứ hai sẽ được ưu tiên, phương pháp này khó định cấu hình hơn nhưng cung cấp nhiều cơ hội hơn, vì trong suốt việc sử dụng các công nghệ đã được lên kế hoạch trong mạng Wake-on-Lan và DLNA đã tạo.
Phần 1: Bối cảnh
Giao thức được chọn để thực hiện nhiệm vụ này ban đầu là OpenVPNThứ nhất, bởi vì nó có thể tạo ra một thiết bị vòi có thể được thêm vào cầu nối mà không gặp bất kỳ vấn đề nào, và thứ hai, OpenVPN Nó hỗ trợ TCP, điều này cũng rất quan trọng, vì không căn hộ nào có địa chỉ IP riêng. Tôi không thể sử dụng STUN vì nhà cung cấp dịch vụ Internet của tôi, vì một lý do nào đó, chặn các kết nối UDP đến từ mạng của họ. TCP cho phép tôi chuyển tiếp cổng máy chủ VPN đến VPS thuê bằng SSH. Mặc dù phương pháp này tạo ra một chi phí đáng kể, vì dữ liệu được mã hóa hai lần, tôi không muốn tích hợp VPS vào mạng riêng của mình, vì có nguy cơ bên thứ ba giành quyền kiểm soát nó. Do đó, việc có một thiết bị như vậy trên mạng gia đình của tôi là điều không mong muốn, vì vậy tôi quyết định trả một khoản chi phí đáng kể để đảm bảo an ninh.
Để chuyển tiếp cổng trên bộ định tuyến nơi dự kiến triển khai máy chủ, tôi đã sử dụng chương trình sshtunnel. Tôi sẽ không đi sâu vào chi tiết cấu hình của nó — khá dễ dàng. Tôi chỉ lưu ý rằng mục đích của nó là chuyển tiếp cổng TCP 1194 từ bộ định tuyến đến VPS. Tiếp theo, tôi đã cấu hình máy chủ. OpenVPN Trên thiết bị tap0, được kết nối với cầu nối br-lan. Sau khi kiểm tra kết nối đến máy chủ mới được tạo từ máy tính xách tay của tôi, rõ ràng là ý tưởng chuyển tiếp cổng đã hoạt động và máy tính xách tay của tôi đã trở thành một thành viên của mạng bộ định tuyến, mặc dù về mặt vật lý nó không phải là một phần của mạng đó.
Việc duy nhất còn lại là phân bổ địa chỉ IP cho các căn hộ khác nhau để tránh xung đột và cấu hình bộ định tuyến như sau: OpenVPN- khách hàng.
Các địa chỉ IP bộ định tuyến và phạm vi máy chủ DHCP sau đây đã được chọn:
- 192.168.10.1 với phạm vi 192.168.10.2 - 192.168.10.80 cho máy chủ
- 192.168.10.100 với phạm vi 192.168.10.101 - 192.168.10.149 cho một bộ định tuyến trong căn hộ số 2
- 192.168.10.150 với phạm vi 192.168.10.151 - 192.168.10.199 cho một bộ định tuyến trong căn hộ số 3
Việc gán các địa chỉ này cho các bộ định tuyến của khách hàng cũng là điều cần thiết. OpenVPN-server, bằng cách thêm dòng sau vào cấu hình của nó:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0và thêm các dòng sau vào tệp /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
trong đó flat1_id và flat2_id là tên thiết bị được chỉ định khi tạo chứng chỉ để kết nối. OpenVPN
Tiếp theo, các bộ định tuyến đã được cấu hình. OpenVPN- Các thiết bị tap0 trên cả hai máy khách đã được thêm vào cầu nối br-lan. Lúc này, mọi thứ dường như ổn, vì cả ba mạng đều có thể nhìn thấy nhau và hoạt động như một thể thống nhất. Tuy nhiên, một chi tiết khá khó chịu đã xuất hiện: đôi khi các thiết bị sẽ nhận được địa chỉ IP từ bộ định tuyến sai, với tất cả các hậu quả kèm theo. Vì một lý do nào đó, bộ định tuyến trong một trong các căn hộ đã không phản hồi DHCPDISCOVER kịp thời, và thiết bị nhận được địa chỉ sai. Tôi nhận ra rằng tôi cần lọc các yêu cầu như vậy trong tap0 trên mỗi bộ định tuyến, nhưng hóa ra, iptables không thể hoạt động với một thiết bị nếu nó là một phần của cầu nối, vì vậy tôi cần sử dụng ebtables. Thật không may, firmware của tôi không bao gồm nó, vì vậy tôi phải xây dựng lại hình ảnh cho mỗi thiết bị. Sau khi thực hiện điều này và thêm các dòng sau vào /etc/rc.local trên mỗi bộ định tuyến, vấn đề đã được giải quyết:
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
Cấu hình này kéo dài trong ba năm.
Phần 2: Làm quen WireGuard
Gần đây, trên mạng internet đang ngày càng có nhiều cuộc thảo luận về... WireGuardTôi rất ấn tượng với khả năng cấu hình dễ dàng, tốc độ truyền tải cao, độ trễ thấp và bảo mật tương đương của nó. Tuy nhiên, khi tìm kiếm thêm thông tin, tôi phát hiện ra rằng nó không hỗ trợ cả thành viên cầu nối (bridge member) lẫn giao thức TCP, điều này khiến tôi tin rằng không còn lựa chọn nào khác. OpenVPN Với tôi thì điều đó vẫn chưa có. Vì vậy, tôi tạm thời trì hoãn việc tìm hiểu. WireGuard.
Vài ngày trước, tin tức lan truyền trên các nguồn thông tin liên quan đến lĩnh vực CNTT rằng: WireGuard Cuối cùng nó sẽ được đưa vào nhân hệ điều hành. LinuxBắt đầu từ phiên bản 5.6. Các bài báo, như thường lệ, đều khen ngợi. WireGuardTôi lại một lần nữa lao vào tìm kiếm những cách thức để thay thế những thứ cũ kỹ quen thuộc. OpenVPNLần này tôi tình cờ gặp . Nó nói về việc tạo một đường hầm Ethernet qua L3 bằng GRE. Bài viết này đã cho tôi hy vọng. Vẫn chưa rõ phải làm gì với giao thức UDP. Việc tìm kiếm đã đưa tôi đến các bài báo về việc sử dụng socat kết hợp với đường hầm SSH để chuyển tiếp cổng UDP, tuy nhiên, họ lưu ý rằng phương pháp này chỉ hoạt động ở chế độ kết nối duy nhất, điều đó có nghĩa là không thể sử dụng nhiều máy khách VPN. Tôi nảy ra ý tưởng thiết lập máy chủ VPN trên VPS và thiết lập GRE cho khách hàng, nhưng hóa ra GRE không hỗ trợ mã hóa, điều này sẽ dẫn đến thực tế là nếu bên thứ ba có quyền truy cập vào máy chủ , tất cả lưu lượng truy cập giữa các mạng của tôi đều nằm trong tay họ, điều này hoàn toàn không phù hợp với tôi.
Một lần nữa, quyết định được đưa ra có lợi cho mã hóa dự phòng, bằng cách sử dụng VPN qua VPN theo sơ đồ sau:
VPN lớp XNUMX:
VPS là người phục vụ với địa chỉ nội bộ 192.168.30.1
MS là khách hàng VPS có địa chỉ nội bộ 192.168.30.2
MK2 là khách hàng VPS có địa chỉ nội bộ 192.168.30.3
MK3 là khách hàng VPS có địa chỉ nội bộ 192.168.30.4
VPN lớp XNUMX:
MS là người phục vụ với địa chỉ bên ngoài 192.168.30.2 và nội bộ 192.168.31.1
MK2 là khách hàng MS có địa chỉ 192.168.30.2 và có IP nội bộ là 192.168.31.2
MK3 là khách hàng MS có địa chỉ 192.168.30.2 và có IP nội bộ là 192.168.31.3
* MS - bộ định tuyến-máy chủ trong căn hộ 1, MK2 - bộ định tuyến trong căn hộ 2, MK3 - bộ định tuyến trong căn hộ 3
* Cấu hình thiết bị được công bố trong spoiler ở cuối bài viết.
Và như vậy, ping giữa các nút của mạng 192.168.31.0/24 đã đi, đã đến lúc chuyển sang thiết lập đường hầm GRE. Trước đó, để không bị mất quyền truy cập vào các bộ định tuyến, bạn nên thiết lập các đường hầm SSH để chuyển tiếp cổng 22 sang VPS, chẳng hạn như một bộ định tuyến từ căn hộ 10022 sẽ có sẵn trên cổng 2 của VPS và một bộ định tuyến từ căn hộ 11122 sẽ có sẵn trên cổng 3 của VPS Bộ định tuyến từ căn hộ XNUMX. Tốt nhất là định cấu hình chuyển tiếp với cùng một sshtunnel, vì nó sẽ khôi phục đường hầm trong trường hợp nó bị sập.
Đường hầm được định cấu hình, bạn có thể kết nối với SSH thông qua cổng được chuyển tiếp:
ssh root@МОЙ_VPS -p 10022Tiếp theo, bạn nên vô hiệu hóa OpenVPN:
/etc/init.d/openvpn stopBây giờ, hãy thiết lập đường hầm GRE trên bộ định tuyến từ căn hộ 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Và thêm giao diện đã tạo vào cây cầu:
brctl addif br-lan grelan0
Hãy thực hiện quy trình tương tự trên bộ định tuyến máy chủ:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Ngoài ra, thêm giao diện đã tạo vào cầu nối:
brctl addif br-lan grelan0
bắt đầu từ thời điểm này, ping bắt đầu chuyển thành công sang mạng mới và tôi hài lòng đi uống cà phê. Sau đó, để xem mạng ở đầu dây bên kia hoạt động như thế nào, tôi thử SSH vào một trong các máy tính ở căn hộ 2, nhưng ứng dụng khách ssh bị treo mà không nhắc tôi nhập mật khẩu. Tôi cố gắng kết nối với máy tính này qua telnet trên cổng 22 và thấy một dòng mà bạn có thể hiểu rằng kết nối đang được thiết lập, máy chủ SSH đang phản hồi, nhưng vì lý do nào đó, nó không cho phép tôi truy cập.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Tôi đang cố gắng kết nối với nó qua VNC và tôi thấy một màn hình đen. Tôi thuyết phục bản thân rằng vấn đề là ở máy tính từ xa, vì tôi có thể dễ dàng kết nối với bộ định tuyến từ căn hộ này bằng địa chỉ nội bộ. Tuy nhiên, tôi quyết định SSH vào máy tính này thông qua bộ định tuyến và ngạc nhiên khi thấy rằng kết nối thành công và máy tính từ xa hoạt động tốt nhưng cũng không kết nối được với máy tính của tôi.
Tôi tháo thiết bị grelan0 ra khỏi cầu nối và chạy nó. OpenVPN Trên bộ định tuyến ở căn hộ số 2, tôi đã xác nhận rằng mạng hoạt động bình thường trở lại và không còn bị gián đoạn kết nối. Khi tìm kiếm, tôi thấy trên các diễn đàn mọi người phàn nàn về cùng một vấn đề và được khuyên nên tăng MTU. Nói rồi làm ngay. Tuy nhiên, cho đến khi MTU được đặt đủ cao—7000 cho thiết bị gretap—tôi vẫn gặp phải tình trạng mất kết nối TCP hoặc tốc độ truyền tải chậm. Do MTU cao cho gretap, MTU cho các kết nối cũng cao. WireGuard Mức độ khó của cấp độ thứ nhất và thứ hai lần lượt được đặt ở mức 8000 và 7500.
Tôi đã thiết lập tương tự trên bộ định tuyến từ căn hộ 3, với điểm khác biệt duy nhất là giao diện gretap thứ hai có tên grelan1 đã được thêm vào bộ định tuyến máy chủ, giao diện này cũng được thêm vào cầu br-lan.
Mọi thứ đang hoạt động. Bây giờ bạn có thể đặt cụm grtap vào chế độ tự động tải. Đối với điều này:
Đặt những dòng này trong /etc/rc.local trên bộ định tuyến trong căn hộ 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Đã thêm phần này vào /etc/rc.local trên bộ định tuyến trong căn hộ 3:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Và trên bộ định tuyến máy chủ:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0
ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1
Sau khi khởi động lại các bộ định tuyến của khách hàng, tôi phát hiện ra rằng vì lý do nào đó chúng không kết nối được với máy chủ. Sau khi kết nối với SSH của chúng (may mắn thay, tôi đã cấu hình sshtunnel trước đó cho việc này), tôi phát hiện ra rằng WireGuard Vì lý do nào đó, nó tạo ra một tuyến đường cho điểm cuối, nhưng tuyến đường này không chính xác. Ví dụ, đối với 192.168.30.2, bảng định tuyến chỉ định một tuyến đường thông qua giao diện pppoe-wan, tức là thông qua internet, mặc dù tuyến đường đến đó đáng lẽ phải được định tuyến qua giao diện wg0. Sau khi xóa tuyến đường này, kết nối đã được khôi phục. Tôi có thể tìm thấy hướng dẫn ở đâu đó về cách buộc thiết lập lại tuyến đường này không? WireGuard Tôi không thể tránh khỏi việc tạo ra các tuyến đường này. Hơn nữa, tôi thậm chí còn không hiểu liệu đây là tính năng của OpenWRT hay của hệ điều hành khác. WireGuardKhông mất nhiều thời gian để tìm hiểu vấn đề, tôi chỉ đơn giản là thêm một dòng vào tập lệnh hẹn giờ trên cả hai bộ định tuyến để xóa tuyến đường này:
route del 192.168.30.2
Tổng kết
Từ chối hoàn toàn OpenVPN Tôi vẫn chưa đạt được điều này, vì thỉnh thoảng tôi cần kết nối với mạng mới từ máy tính xách tay hoặc điện thoại, và việc thiết lập thiết bị gretap trên chúng thường là không thể. Tuy nhiên, bất chấp điều đó, tôi đã có được lợi thế về tốc độ truyền dữ liệu giữa các căn hộ, và việc sử dụng VNC, chẳng hạn, giờ đây trở nên dễ dàng hơn. Độ trễ (ping) đã giảm nhẹ nhưng trở nên ổn định hơn:
Khi sử dụng OpenVPN:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms
Khi sử dụng WireGuard:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
Nó chủ yếu bị ảnh hưởng bởi ping cao đến VPS, khoảng 61.5 mili giây
Tuy nhiên, tốc độ đã tăng lên đáng kể. Vì vậy, trong căn hộ có bộ định tuyến kiêm máy chủ, tôi có tốc độ kết nối internet 30 Mbps, còn ở các căn hộ khác thì chỉ còn 5 Mbps. Hơn nữa, trong quá trình sử dụng... OpenVPN Theo kết quả đo của iperf, tôi không thể đạt được tốc độ truyền dữ liệu giữa các mạng lớn hơn 3,8 Mbps. WireGuard Đã "tăng" tốc độ lên cùng mức 5 Mbit/giây.
Cấu hình WireGuard trên VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Ngang nhau]
Khóa công khai = <VPN_1_MS_PUBLIC_KEY>
Được phépIP = 192.168.30.2/32
[Ngang nhau]
Khóa công khai = <VPN_2_MK2_PUBLIC_KEY>
Được phépIP = 192.168.30.3/32
[Ngang nhau]
Khóa công khai = <VPN_2_MK3_PUBLIC_KEY>
Được phépIP = 192.168.30.4/32
Cấu hình WireGuard trên MS (đã thêm vào /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.2/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - сервер
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option listen_port '51821'
list addresses '192.168.31.1/24'
option auto '1'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
list allowed_ips '192.168.31.2'
config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
list allowed_ips '192.168.31.3'
Cấu hình WireGuard trên MK2 (đã thêm vào /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.3/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - клиент
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
list addresses '192.168.31.2/24'
option auto '1'
option listen_port '51821'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option endpoint_host '192.168.30.2'
option endpoint_port '51821'
option persistent_keepalive '25'
list allowed_ips '192.168.31.0/24'
Cấu hình WireGuard trên MK3 (đã thêm vào /etc/config/network)
#VPN первого уровня - клиент
config interface 'wg0'
option proto 'wireguard'
list addresses '192.168.30.4/24'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
option auto '1'
option mtu '8000'
config wireguard_wg0
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.30.0/24'
option endpoint_host 'IP_АДРЕС_VPS'
#VPN второго уровня - клиент
config interface 'wg1'
option proto 'wireguard'
option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
list addresses '192.168.31.3/24'
option auto '1'
option listen_port '51821'
option mtu '7500'
config wireguard_wg1
option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
option endpoint_host '192.168.30.2'
option endpoint_port '51821'
option persistent_keepalive '25'
list allowed_ips '192.168.31.0/24'
Trong các cấu hình được mô tả cho VPN cấp hai, tôi chỉ ra cho khách hàng. WireGuard Cổng 51821. Việc này lẽ ra không cần thiết, vì máy khách sẽ thiết lập kết nối từ bất kỳ cổng nào còn trống và không có đặc quyền, nhưng tôi đã làm theo cách này để có thể từ chối tất cả các kết nối đến trên giao diện wg0 của tất cả các bộ định tuyến, ngoại trừ các kết nối UDP đến cổng 51821.
Tôi hy vọng rằng bài viết sẽ hữu ích cho ai đó.
PS Ngoài ra, tôi muốn chia sẻ tập lệnh gửi cho tôi thông báo PUSH tới điện thoại của tôi trong ứng dụng WirePusher khi một thiết bị mới xuất hiện trên mạng của tôi. Đây là một liên kết đến kịch bản: .
UPDATE: Cấu hình OpenVPN- máy chủ và máy khách
OpenVPN-người phục vụ
client-to-client
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key
dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzoOpenVPN- khách hàng
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind
ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem
comp-lzo
persist-tun
persist-key
verb 3 Tôi đã sử dụng easy-rsa để tạo chứng chỉ.
Nguồn: www.habr.com
