Клиентүүд холбогдож баталгаажуулалт хийдэг, дараа нь тэдний урсгал буруу дээд холбоосоор гардаг, учир нь төхөөрөмж дээрх цорын ганц өгөгдмөл маршрут нь гарцад өөрт нь хамаардаг. Тэр өгөгдмөл маршрутыг солих нь төхөөрөмжийн өөрийн шинэчлэлт, удирдлагын хандалтыг эвдэх тул сонголт нь «бүх урсгал»-аас нарийхан байх ёстой. Ажиллах хэлбэр нь клиентийн пулын дотоод эх хаягт тулгуурласан, өөр WAN-ыг эзэмшдэг хоёр дахь маршрутжуулалтын хүснэгт рүү заасан бодлогын дүрэм юм. Тэндээс хойш шалгах хуудас нь дүрмийн тухай биш, бүрэн бүтэн байдал ба алдааны үеийн зан төлөвийн тухай.

Эх хаяг нь маршрутжуулалтын шийдвэр хүртэл үлддэгийг батал

Эх мужид тохирох бодлогын дүрэм нь хайлтын үед пакет тэр эхээ одоо ч зөөж байгаа үед л идэвхждэг. Дамжуулсан клиентийн урсгал маршрутжуулалтын өмнө дээрээс юу ч дахин бичээгүй л бол тийн хийдэг. Гарцын өөрөө үүсгэсэн урсгал тийн хийдэггүй, яг ийм учраас гарцын өөрийн өгөгдмөл маршрут байрандаа үлдэж чадна.

Энд локал туршилтууд төөрөгдүүлдэг. Гарц дээр ажиллуулсан curl нь гарцын хаягтай локал үүссэн урсгал тул үндсэн хүснэгтийг авч, клиентийн замд юу ч нотлохгүй. Холбогдсон клиентээс туршиж үзэх, эсвэл пулд үнэхээр хамаарах эхтэй урсгал үүсгэ.

Бодит утгуудыг бичээд эхэл: пулын префикс, түүнийг зөөж буй туннелийн интерфейс, хоёр дахь WAN-ы хаяг ба дараагийн үсрэлт, мөн ашиглахаар төлөвлөж буй хүснэгтийн дугаар. Шинэ дүрэм нэмэхийн өмнө өмнөх оролдлогын хуучин дүрмүүдийг цэвэрлэ, учир нь өөр өөр эрэмбэ бүхий давхар дүрмүүд санамсаргүй мэт харагдах алдаа үүсгэдэг.

Бүрэн сонгосон хүснэгтийг байгуул

Хүснэгт бол найзтай өгөгдмөл маршрут биш. Хайлт бүр түүний дотор шийдэгдэх хангалттай маршрут хэрэгтэй, түүний дотор WAN дэд сүлжээний холбогдсон маршрут, дараагийн үсрэлт хүрч болохоор. tun1 дээрх 10.77.0.0/24 пул, дараагийн үсрэлт 203.0.113.1 бүхий WAN хаяг 203.0.113.20/24, мөн 600 хүснэгтийн хувьд:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Дүрэм нь одоо байгаа бүгдийг барих дүрмээс доогуур эрэмбэд суудаг тул тохирох клиентүүд эхлээд 600 хүснэгтэд хүрч, бусад бүхэн үндсэн хүснэгт рүү унана. ip-rule лавлагаа нь дараалсан хайлтын загвар, сонгогчийн синтаксийг бүрэн тайлбарладаг.

Дараа нь хүснэгтэд юу байхгүйг бод. Зөвхөн үндсэн хүснэгтэд маршруттай очих газар, жишээ нь eth0-оор хүрч болох удирдлагын дэд сүлжээ, 600 хүснэгтээс олдохгүй бөгөөд тэнд өгөгдмөл маршрут үүссэний дараа үндсэн рүү буцахгүй. Хэрэв тэдгээр зам чухал бол тэдгээрийг сонгосон хүснэгтэд тодорхой нэм, энэ нь VPN-ийн гаралтын хүснэгтэд ердийн зөв хариулт юм.

Сонсогчийн өөрийн урсгалыг бодлогоос гадуур байлга

OpenVPN сонсогчийн өөрийн гадаад холболт байдаг бөгөөд клиент түүнд хүрсэн дээд холбоосоор зөөгддөг. Тэр урсгал нь ирсэн буцах замаа хадгалах ёстой, серверийн нийтийн хаяг эсвэл бүх туннелийн интерфейсийг хамарсан өргөн дүрэм түүнийг өөр хүснэгт рүү татаж болно. Дүрмийг дотоод пулаар хязгаарла, өөр юугаар ч биш.

Буцах замын шүүлтүүр мөн адил шалтгаанаар анхаарал татахуйц. Клиентүүд рүү хариу usb0-ээр гарч, хүсэлт өөр холбоосоор ирсэн үед хатуу rp_filter тохиргоо нь маршрутжуулалтын бодлого хүчинтэй гэж үзсэн пакетуудыг хаяж болно. Дүрэм бүтэлгүйтсэн гэж дүгнэхийн өмнө хоёр интерфейсийн үйлчилж буй sysctl утгыг шалга.

Дараалал нь төхөөрөмж дээрх бусад бүхэнтэй харьцуулахад ч чухал. Docker гүүр, хоёр дахь VPN, нийлүүлэгчийн дүрсээс урьдчилан байгаа аливаа дүрэм бүгд эрэмбэ нэмдэг тул 100 эрэмбэ ганцаараа гэж таамаглахын оронд бүх дүрмийн жагсаалтыг унш.

Дамжуулалт ба орчуулгыг маршруттай нийцүүл

Маршрутжуулалт дээд холбоосыг сонгодог; энэ нь дамжуулах зөвшөөрөл өгдөггүй. Цөмд IPv4 дамжуулалт идэвхтэй байх ёстой, галт хана клиентээс WAN руу чиглэл болон буцах урсгыг хүлээн авах ёстой. Урсгыг хаядаг FORWARD гинжин хэлхээтэй зөв хүснэгт нь маршрут байхгүйтэй ижил шинж тэмдэг өгдөг тул хоёуланг нь нэг дамжуулалтад шалгадаг.

Хоёр дахь WAN хувийн пулыг та нар руу буцааж маршрутжуулахгүй бол тэр гаралт дээр эхийг орчуул. Динамик хаягтай интерфейсийн хувьд пул ба интерфейсээр хязгаарлагдсан нарийн masquerade дүрэм ердийн сонголт:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Энд хүрээ нь зорилтоос илүү чухал. Аливаа гарч буй интерфейст тохирох masquerade дүрэм eth0-оор зөв гарч буй урсгыг ч дахин бичих бөгөөд энэ нь маршрутжуулалтын алдааг засахын оронд нуудаг. Орчуулга нь маршрутжуулалтын шийдвэрийн дараа ажилладаг тул буруу дээд холбоос руу илгээсэн пакетыг хэзээ ч засаж чадахгүй.

Зам өөр болмогц туннелийн зардал ч анхаарал шаарддаг. Клиентүүд том TCP MSS-д тохиролцож, өөр WAN-ы MTU бага эсвэл дотор нь туннель байвал том сегментүүд гацаж, жижиг нь ажилладаг. Дамжуулах зам дээр MSS-ийг хавчих нь үүнийг хааяа гацахын оронд урьдчилан таамаглах боломжтой зан төлөв болгоно.

usb0 алга болоход юу болохыг шийд

Хоосон хүснэгт нь алдааны үед хаагддаг төлөв биш. Тохирох маршрут алга болвол хайлт дараагийн дүрэм рүү үргэлжилж, үндсэн хүснэгтэд хүрч eth0-ийн өгөгдмөлийг авна. Хоёр дахь WAN-аар гарах ёстой байсан урсгал чимээгүйгээр эхнийхээр гардаг бөгөөд бодлогоор маршрутжуулсан байршуулалтад энэ нь ихэвчлэн хамгийн бага хүсдэг үр дүн юм.

Тэр буцалт хүлээн зөвшөөрөхгүй газарт 600 хүснэгтэд тодорхой терминал маршрут нэм, жишээ нь blackhole өгөгдмөл, эсвэл интерфейс унтарсан үед пулыг галт хананд хая. Аль аль нь бичиж болох шийдвэр; дуугүй байх нь тийм биш.

Тогтвортой байдал бол сүүлийн зүйл. Хоёр холбоосыг эзэмшигч хэн ч бай, сүлжээний менежер, илгээгч скрипт эсвэл холболтын амьдралын мөчлөг бай, дахин холбогдох бүрд хуулбарыг нэмэхгүйгээр маршрутууд болон дүрмийг дахин үүсгэх ёстой. Бодит клиентээс хүсэлт, гарцаас тусдаа хүсэлтээр баталгаажуул, хоёуланд нь ажиглагдсан гаралтыг батал, дараа нь хоёр дахь WAN-ыг салгаж, зохиосон хоёр үр дүнгийн аль нь үнэхээр болж байгааг хар. IPv6-д өөрийн хүснэгт, дүрэм, орчуулга хэрэгтэй; дээрх IPv4 дүрэм түүний тухай юу ч хэлэхгүй.

Холбоотой нийтлэлүүд