VPN маршрут уу, галт хананы дүрэм үү: пакетыг аль нь унагаж байна вэ?

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

Хоёр шийдвэр, нэг пакет, хоёр эзэн

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

Шүүлт нь тусдаа. Linux хост дээр netfilter дэгээнүүд трафикийг пакет хэнд зориулагдсанаар нь хуваадаг: гаралт машиныг орхино, орох нь түүн дээр дуусна, дамжуулалт түүгээр дамжина. VPN клиентүүдийг хүлээн авч LAN руу чиглүүлдэг гарцанд дамжуулах зам хэрэгтэй бөгөөд энэ нь ихэнх анхдагч тохиргоонууд хоосон орхидог гинжин хэлхээ юм.

Эх сурвалжийн сонголт мөн адил шийдвэрт хамаарах бөгөөд хамгийн олон зөрүү энд нуугддаг. Цөм нь маршрут нэгийг заахгүй л бол гарах интерфэйсээс эх сурвалжийн хаяг сонгодог тул LAN дэд сүлжээнд зориулж бичсэн шүүлтүүрийн дүрэм туннелийн хаягтай гарч буй пакеттай хэзээ ч тохирохгүй.

Хайлт үнэндээ юу сонгосныг уншина уу

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

Бодлогод суурилсан IPsec нь маршрутчлал хамрахгүй гурав дахь тохирлын үе шатыг нэмдэг бөгөөд үүнийг strongSwan-ийн дамжуулалтын тэмдэглэл туннель ба тээврийн тохиргоонд тайлбарладаг. Аюулгүй байдлын бодлого трафикийг префикс ба протоколоор сонгодог бол маршрут нь хамгаалалтгүй пакет хаашаа явахыг л шийднэ. Маршрутлагдсан ч тохирох селекторгүй дэд сүлжээ нь эсвэл хамгаалалтгүй үлдэх, эсвэл тохиргооноос хамааран хаягдана, аль ч үр дүн галт хананы асуудал мэт харагдахгүй. Бодлогыг хэвлэж, селекторуудыг туннель зөөнө гэж хүлээсэн префикстэй харьцуул.

Шүүлт нь маршрут дээр биш, дэгээ дээр үйлчилнэ

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

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

Клиентийн ашигладаг замаар проб илгээ

Гарц дээр өөрөө ажиллуулсан тестүүд гарц өөрийн эх сурвалжийн хаягтайгаар гаралт ба оролтоор дамждаг. Энэ нь клиентийн дамжуулсан хүсэлтээс өөр зам тул амжилттай локал curl харагдахаас бага зүйг нотолно. Бүтэлгүйтэж буй машинаас шалга эсвэл интерфэйс ба эх сурвалжийг тодорхой бэхэл.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

Лог бичих нь эхний алхам биш, хоёр дахь санал болж ажиллана. Дамжуулах гинжин дээрх түр лог мэдэгдэл нь түүнд хүрсэн интерфэйс ба хаягуудыг нэрлэх бөгөөд дараа нь арилгахад хялбар. Үүнийг байнга үлдээвэл хариултын оронд логын эзлэхүүний асуудал бүтээсэн байна.

Өөрчлөлт бүрийг дахин холбогдсоны дараа үлдэх газарт тавь

ip route add-аар нэмсэн маршрут интерфэйс унах хүртэл амьдарна. Үүнийг холболтын профайлд хадгал: NetworkManager холболт дээр нэмэлт маршрут хүлээн авч, netplan тэдгээрийг ачааллагуудын хооронд хадгална. Мөн адил дүрэм клиентийн талын галт хананы үл хамаарах зүйлд хамаарах бөгөөд энэ нь дараагийн дахин ачааллын дараа алга болно.

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

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