Алсын хэрэглэгчид VPN төвөөр дамжин хоёр дахь сайтад хүрч чадахгүй

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

Дамжуулалтад гурван хайлт хэрэгтэй, нэг туннель биш

Төхөөрөмж бүр өөрийн хамгийн урт префиксийн тохирлыг хийгээд мартдаг. Зөөврийн компьютер 10.20.0.50-ыг локал чиглүүлэгч рүү биш, туннель рүү илгээх ёстой. Төв нь алсын хандалтын интерфэйсээр ирсэн пакетыг авч, сайт-сайтын интерфэйсэд дамжуулах ёстой. Төв оффис хэрэглэгчийн хаяг руу хариуг туннелээр буцааж илгээх ёстой. Эдгээр гурвын аль нэг нь бүтэлгүйтвэл хөтөч дээр ижил харагдана: чимээгүй.

Тиймээс туннел бүрийг тус тусад нь шалгах нь маш бага зүйлийг батална. Төвийн LAN хаяг руу ping хийх нь эхний шийдвэрийг шалгана, төв оффисоос төв рүү ping хийх нь гурав дахь шийдвэрийг шалгана. Бүтэлгүйтэх пакетын эх сурвалж нь хэрэглэгчийн пул, очих газар нь хоёр дахь сайт тул эхлээд эдгээр префиксүүдийг бичээрэй. Энд пул нь 10.80.0.0/24, төвийн LAN нь 10.10.0.0/24, төв оффис нь 10.20.0.0/24.

Холын префиксийг алсын клиент рүү түлхээрэй

Нэг OpenVPN алсын хандалтын сервер дээр клиент маршрутуудыг холбогдох үед сурдаг. push байхгүй бол хуваагдсан туннельтай клиент 10.20.0.50-ыг өөрийн гарц руу илгээж, пакет туннельд хэзээ ч орохгүй.

push "route 10.20.0.0 255.255.255.0"

Түлхсэн маршрут клиент холбогдох үед хүчин төгөлдөр болдог тул онлайн үлдсэн хэрэглэгч дахин холбогдох хүртэл юу ч харахгүй. Клиент дээр шалгаарай: Linux дээр ip route get 10.20.0.50, Windows дээр route print. Гаралт нь туннелийн интерфэйсийн нэрийг дурдах ёстой.

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

Төвд жинхэнэ гарцын маршрут өгөөрэй

Төвд төв оффисын префиксийн өөрийн дараагийн хоп хэрэгтэй. Маршрутлагдсан туннель дээр энэ нь сайт-сайтын интерфэйсээр дамжих энгийн маршрут бөгөөд нэг команд тань сонгосон маршрут болон сонгосон эх сурвалжийг хоёуланг нь харуулна:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Сайт-сайтын хэсэг өөрөө OpenVPN бол маршрут нь тухайн тохиргоонд түншийн туннелийн хаягийг гарц болгон амьдарч болно: route 10.20.0.0 255.255.255.0 172.30.0.2. Гарц нь заавал байх ёстой. Хэрэв орхивол дараагийн хоп нь хэрэгжүүлэлтийн өгөгдмөл утгад шилжих бөгөөд энэ нь нэг алсын клиент болон олон түнштэй төвийн хооронд ялгаатай.

Бодлогод суурилсан IPsec өөр: төвийн цөм пакетыг ердийн LAN гарц руу илгээж, бодлого нь гарч явах замд нь барьдаг тул туннелийн маршрут нь юу ч хийдэггүй эсвэл трафикийг бодлогыг тойруулан чиглүүлдэг. Дээрх команд дахь эх сурвалжийг анхаараарай, учир нь пулын хаягийн оронд 10.10.0.1 байвал цөм холын тал татгалзах хаягийг сонгосон гэсэн үг. iroute ч хариулт биш; энэ нь серверт аль клиент өөрийн туннелийн ард байгаа дэд сүлжээг эзэмшиж байгааг хэлдэг, гурав дахь сайт руу трафикийг хаашаа илгээхийг биш.

Холын талыг хэрэглэгчийн пул хүртэл өргөтгөөрэй

Төв оффис төвийн LAN буюу 10.10.0.0/24-ийг аль хэдийн хамрах байна. Хэрэглэгчийн пул нь хоёр дахь префикс бөгөөд селекторуудад ч байх ёстой, эс тэгвээс 10.80.0.25 руу илгээсэн хариуг ямар ч бодлого хамрахгүй. Түнш бүр өөрийн талаас префиксийн олонлогийн ижил хосыг нэрлэнэ:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Нэг төхөөрөмжийн local_ts нь нөгөөгийнх нь remote_ts. Төвийн блокыг төв оффис руу хуулбал хос эргэж, охин SA хэзээ ч босохгүй.

Хуучин ipsec.conf синтакс таслалаар тусгаарласан leftsubnet-ийг ашигладаг. Ажиллаж буй аюулгүй байдлын холбоо нь тохиролцсон селекторуудаа хадгалдаг тул засварын дараа туннелийг дахин байгуулаарай. 10:00-д өөрчилсөн селекторыг 09:40-д боссон SA-тай харьцуулан шалгавал одоо ч бүтэлгүйтнэ, харин тохиргооны файл бүх хугацаанд зөв харагдана.

Дараа нь сүүлчийн хопыг шалгаарай. Холын төгсгөл дэх ip route get 10.80.0.25 туннель рүү заах ёстой. Хэрэв үйлчилгээ LAN чиглүүлэгчийг өөрийн өгөгдмөл гарц болгон ашигладаг бол тэр чиглүүлэгчид ч буцах маршрут хэрэгтэй, эс тэгвээс хариу тэнд үхнэ. Тэр сегмент дээр tcpdump -ni eth1 host 10.80.0.25 ажиллуулах нь хариу төгсгөлөөс гарсан эсэхийг харуулна.

Төв дээр урсгалыг зөвшөөрөөрэй

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Урвуу замын шүүлт нь түүний хажууд байх чимээгүй бүтэлгүйтэл юм: хоёр хэсэг өөр интерфэйс дээр байвал rp_filter=1 хариуг унагаж болох бөгөөд хүлээн авах дүрмийн тоолуур огт хөдлөхгүй. Оролдлогын өмнө болон дараа iptables -vnL FORWARD-ийг харьцуулаарай. Хэзээ ч өсдөггүй дүрэмд хүрдэггүй тул дахин бичихийн оронд нэг давхарга доош хараарай.

Хэрэв зөвхөн нэг бүлэгт дамжуулалт хэрэгтэй бол дэлхийн push-ыг өргөтгөхийн оронд маршрутыг client-config-dir-ийн доорх клиент тус бүрийн файлд хийнэ үү. Төв дээрх Source NAT нь холын талын буцах маршрутын хэрэгцээг ч арилгадаг боловч хэрэглэгчийн хаягийг нуудаг тул холын сайтын лог болон хаягт суурилсан дүрмүүд хэрэглэгчдийг ялгахаа больдог.

Клиентээс шалгаад, дараа нь урвуу дарааллаар буцааарай

Зөвхөн ICMP биш, TCP порт шалгаарай, учир нь ping өнгөрч болох боловч үйлчилгээ хаалттай хэвээр байж болно. Клиентээс nc -vz 10.20.0.50 445 болон traceroute -n 10.20.0.50 нь хоёр дахь хоп төвийн туннелийн хаяг мөн эсэхийг харуулна. Төв дээр tcpdump -ni tun0 host 10.20.0.50 болон сайт-сайтын интерфэйс дээрх ижил шүүлт: хоёуланд нь хүсэлт байгаа ч аль нэгэнд нь хариу байхгүй бол асуудал холын тал руу шилжинэ.

Дараа нь хаалттай хэвээр байх ёстой зүйлийг шалгаарай. Хэрэв пул хэзээ ч хүрэх ёсгүй хост ч хариулбал та дамжуулалтаас илүү ихийг нээсэн тул дүрмийг нарийсгах хэрэгтэй. Бүгдийг салбар бүр рүү дамжуулдаг төв эхний шалгалтад тэнцэж, хоёр дахьд нь бүтэлгүйтнэ.

Буцаах жагсаалт хөтлөөрэй, учир нь дөрвөн объект өөрчлөгдөж, гурав нь мартагдахад амархан: түлхсэн маршрут, төвийн маршрут, селекторууд болон галт ханын дүрмүүд. Тэдгээрийг урвуу дарааллаар буцааж, SA-г дахин байгуулж, нэг хэрэглэгчийг дахин холбогдуулаарай. Хэсэгчилсэн буцаалт нь одоо тохирохгүй туннель рүү заасан маршрутыг үлдээдэг бөгөөд үүнийг унших нь анхны чимээгүй байдлаас хэцүү. OpenVPN 2.6 гарын авлага таны хувилбарын push, route болон iroute-ийг баримтжуулна.