Хоёр OpenVPN серверийн клиентүүд бие биедээ хүрч чадах уу?

Хоёр дахь OpenVPN серверийг босгох нь клиентүүд холбогдох хоёр дахь газар өгнө, үүнээс өөр зүйлгүй. Энэ нь тэдгээр клиентийг эхний серверийн сүлжээнд оруулахгүй, client-to-client нэртэй сонголт нь зөвхөн нэг серверийн процесс доторх дамжуулалтыг өөрчилдөг. Хоёр сан нэг сүлжээ болно, хэрэв та тэдний хооронд санаатайгаар маршрутлавал, чиглэл бүрт нэг хариуцлагатай хүнтэй. Доорх бүхэн хэрэглэгчийн орон зайн TUN горим, тэр дотоод дамжуулалт унтарсан гэж үздэг тул шийдвэрийг цөм гаргана.

Домог: нэг бүртгэлийн жагсаалт, нэг сүлжээ

Баталгаажуулалт ба хүртээмж холилддог, учир нь хоёулаа серверийн тохиргоонд амьдардаг. Хоёр гарцын аль нэгэнд нэвтэрч чадах хэрэглэгч гаднаас харвал хоёр хаалгатай нэг системийн хэрэглэгч мэт харагдана. Дотроо сервер бүр өөрийн сангаас хаяг олгож, өөрөө дуусгаж буй клиентүүдэд л маршрут суулгана. Тиймээс A гарц дээрх клиент B гарц дээрх клиент рүү багц илгээхдээ өөрийн сервер хэзээ ч сонсож байгаагүй очих газрыг асууна. Багц A-ийн үндсэн маршрутаар явж, туннелийг орхиж, үүнийг зөвшөөрөхийг хэзээ ч хүсээгүй галт ханы дээр ирнэ.

Тиймээс хоёр дахь сервер нэмэх нь илүүдэл, илрүүлэлт эсвэл хамтарсан нэвтрүүлэх домэйн нэмэхгүй. Төлөвлөгөө шаарддаг маршрутлагдсан сүлжээ нэмдэг бөгөөд төлөвлөгөө хаяглалаас эхэлдэг.

Гарц бүрт өөрийн сан, дамжуулалтын хаяг өгнө үү

Өөр юутай ч давхцах ёсгүй хоёр муж, дээр нь хост хоорондын жижиг дамжуулалтын холбоос — энэ бол бүх хаягийн төлөвлөгөө. Дамжуулалтыг өөрийн хянадаг хувийн сегмент дээр байлгаж, аль ч сервер лизинг олгохоос өмнө тоонуудыг бичиж аваарай.

Профайлууд ижил байхын тулд хоёр серверт ижил сан өгөх уруу таталтад эсэргүүцээрэй. Цөмийн маршрут нь хуваалцсан мужийн доторх дурын хаягийг одоо хоёр хостны алинд нь эзэмшиж байгааг хэлж чадахгүй тул маршрутын хүснэгт нэг гарцыг зааж, клиент нөгөөд холбогдсон байж болно. Интерфэйсийн нэрс нь орон нутгийн уламжлал, хуваалцсан төлөв биш. Энд хоёр хост туннелийн төхөөрөмжийг tun0, дамжуулалтын холбоосыг transit0 гэж нэрлэдэг нь зөв, учир нь ямар ч багц эдгээр нэрийг зөөдөггүй.

Маршрутыг хоёр талд суулгана уу

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

Эзэмшлийг хуурамчаар үйлдэхгүйгээр клиентийн маршрутыг түлхээрэй

Клиентүүдэд алслагдсан сан руу маршрут хэрэгтэй, эс бөгөөс тэдний үйлдлийн систем багцыг үндсэн гарц руу илгээж, туннель үүнийг хэзээ ч харахгүй. Серверийн тохиргоо нь үүнийг хүргэх байгалийн газар.

push "route 10.64.20.0 255.255.255.0"

Толин мөрийг нөгөө серверийн тохиргоонд хийж, дараа нь туршилтын клиентийг дахин холбож, түүний хүснэгтийг унш. Түлхэгдсэн маршрутыг үл хайхран клиент өөрийн батлагдсан тохиргоог шаардана, хэзээ ч ирдэггүй маршрут нь хандалтын хяналт биш. Клиентэд нөгөө гарцын бүх санд зориулж iroute бүү өг. Тэр заавар нь нэг холбогдсон клиентийн ард байгаа дэд сүлжээнд зориулагдсан бөгөөд гарцуудын хооронд дутуу маршрутыг далдлахад ашиглах нь хүрч чадахгүй хаягуудыг эзэмшдэг гэж итгэдэг сервер үүсгэдэг.

Нэг хүсэлтийг баталж, нөгөөгөөс татгалз

Бодит үйлдэл сонго, жишээлбэл 10.64.10.21 дээрх клиентээс 10.64.20.37 дээрх үйлчилгээ рүү HTTPS, хоёр хост дээр яг үүнийг зөвшөөр. Галт хан бүр хүсэлтийг орох талдаа, хянагдсан хариуг буцах талдаа хүлээн авна; очих газрын өөрийн үйлчилгээний бодлого үүнийг одоо ч хүлээн авах ёстой.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Харилцан маршруттай үед эх үүсвэрийн NAT шаардлагагүй бөгөөд энд идэвхтэй хор хөнөөлтэй: эх үүсвэрийг хөрвүүлэх нь аль клиент хүсэлт гаргасныг нууж, очих газрын талын эх үүсвэрт суурилсан бодлогыг эвддэг. Интернэт рүү гарах одоо байгаа masquerade дүрэм энэ замыг ч барихгүй эсэхийг шалга. Дараа нь татгалзалтыг турш. B санд орон нутгийн байх ёстой үйлчилгээ A сангаас хүрэхгүй хэвээр байх ёстой, мөн нэг гарц дээрх клиент хосуудыг ч турших хэрэгтэй, учир нь саяхан өөрчилсөн дамжуулалтын бодлого тэдэнд ч хамаарна.

Сэтгэл зүйн загварт дахин нэг засвар: дамжуулалтын холбоос тайлагдсан дотоод багцыг зөөдөг тул энэ нь хувийн баталгаа биш, итгэлийн хил юм. Хэрэв таны хянадаггүй сүлжээгээр дамжвал тэр үсрэлтийг батлагдсан шифрлэгдсэн туннелээр хамгаалж, түүний бодит топологиор маршрутла. Үзүүрээс үзүүр хүртэлх TLS аппликейшнийг өөрөө баталгаажуулснаар дотоод үйлчилгээ үүнийг үргэлжлүүлэн ашиглах ёстой.