Сайт хоорондын VPN-ийн хариу туннелээр дамждаггүй
Туннелийг тойрч гарсан хариу нь алслагдсан талын чиглүүлэлтийн шийдвэр юм. Хостын хүснэгт, селекторууд болон rp_filter-ийг шалгаад дараа нь маршрут эсвэл NAT-ыг сонгоно уу.
Нэг өглөөг туннельд зориулсан: энэ нь цэвэрхэн босч, урсгалыг яг нэг чиглэлд зөөж байв — салбар төв оффис дахь файлын серверт хүрч байсан бол төв оффисоос салбар руу нээгдсэн холболт бүр эхний SYN дээр үхэж байлаа. SA-ууд боссон, туннелийн тоолуурууд өсч байсан, гар барилт хэзээ ч асуудал болоогүй. Хариу нь туннель хамрахгүй газар руу чиглүүлэгдэж байсан бөгөөд энэ сонголт алслагдсан талд хамаарна. Сайт хоорондын VPN нь зөвхөн хост гарц руу шилжүүлсэн пакетуудыг зөөдөг бөгөөд хост бүр энэ сонголтыг тус тусад нь, чиглэл бүрд, өөрийн чиглүүлэлтийн хүснэгтээс хийдэг.
Хоёр чиглэл тус тусад нь чиглүүлэгддэг
IP нь ярианы чиглэлийн талаар ямар ч санамсаргүй хадгалдаггүй. Пакет илгээдэг хост бүр өөрийн хамгийн урт угтварын хайлтыг хийдэг, нэг дараагийн үсрэлтийг сонгоод шийдвэрийг мартана. Хүсэлт ба хариу нь нэг холболтод санамсаргүй хамаарах хоёр хамааралгүй пакет бөгөөд туннель нь аль нэг нь ашиглаж болох эсвэл болохгүй нэг үсрэлт юм. IKE солилцоонд алслагдсан серверт таны дэд сүлжээнд хэрхэн хүрэхийг заадаг зүйл байхгүй; хэлэлцээр нь аль угтварыг шифрлэж болохыг л зөвшилцдөг.
Энэ зөвшилцөл нь хоёр дахь хаалга юм. strongSwan дээр урсгалын селекторууд нь leftsubnet ба rightsubnet бөгөөд эх үүсвэр эсвэл очих газар нь тохиролцсон хосоос гадуур байгаа пакет чиглүүлэлтийн хүснэгт юу ч гэсэн шифрлэгдэхгүй. Туннельд чиглүүлэгдсэн ч селекторуудад байхгүй угтвар нь чимээгүй нэг талын алдаа: маршрут зөв харагдана, пакет нээлттэй гарна эсвэл хаягдана, зөвхөн charon-ийн бүртгэл гомдоллодог.
Алслагдсан хост таны туннелийн талаар юу ч мэдэхгүй
Алслагдсан LAN дотор хариу нь таны клиентэд хаягласан энгийн пакет юм. Очих газрын хост ямар ч IPsec толгойг хардаггүй бөгөөд VPN гарцыг илүүд үзэх шалтгаан байхгүй; таны угтварыг хайж, анхдагч маршрутаас илүү тодорхой зүйл олдохгүй тул түүнийг дагана. Хэрэв анхдагч нь үндсэн галт хана руу зааж байвал галт хана туннель руу буцах маршруттай эсвэл байхгүй. Байхгүй бол та чимээгүй хаялт, ICMP unreachable, эсвэл интернэт рүү харсан интерфэйсээр гарч үхэх хариу авна.
Маршрут байсан ч хоёр дахь интерфэйс үүнийг эвдэхэд хангалттай. Өөр VLAN дээр удирдлагын холбоостой NAS, нөөц uplink-тай сервер, нэг эх үүсвэрийн мужийг хоёр дахь хүснэгт рүү илгээдэг бодлогын дүрэм: эдгээрийн аль нь ч хариуг барьж чадна. Linux дээр ip rule show ба ip route show table all нь анхдагч жагсаалт нуудаг дүрэм, хүснэгтүүдийг харуулна.
Хариу илгээж буй машин дээр шийдвэрийг уншина уу
Ямар нэг зүйлийг өөрчлөхөөс өмнө цөмөөс асууж, түүнд эх үүсвэрийн хаягийг өгнө үү, учир нь эх үүсвэрээс хамааралтай дүрмүүд хариуг өөрчилдөг.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Гаралт нь гарч буй интерфэйс болон дараагийн үсрэлтийг нэрлэнэ. Хэрэв интерфэйс VPN гарц руу харсан нь биш бол та согогийг олсон бөгөөд үлдсэн ажил нь маршрут хаана байх ёстойг сонгох юм. Гарцаас хийсэн ping энд бага зүйл батална: алслагдсан хост байрлуулж чадах хаягаар хариулдаг, таны зөөврийн компьютерын хаягаар биш.
Windows дээр эквивалентууд нь шийдвэрт Find-NetRoute -RemoteIPAddress 10.10.5.10, хүснэгтэд Get-NetRoute юм. Анхдагчаас өндөр хэмжүүртэй New-NetRoute-ээр нэмсэн маршрут чимээгүй ялагдана, тиймээс бичлэгийг биш, хэмжүүрийн баганыг уншина уу. Дараа нь пакетуудаар баталгаажуулна: алслагдсан LAN интерфэйс дээр tcpdump -ni any "host 10.10.5.10 and tcp port 445" хүсэлтийг харуулж, туннелийн талд ижил шүүлтүүр хариу буцаж ирсэн эсэхийг харуулна. Хүсэлт харагдаж байгаа ч хариу байхгүй бол хариу өөр тийш чиглүүлэгдсэн эсвэл хаягдсан гэсэн үг; буруу интерфэйс дээрх хариу маршрутад хүрэхээс өмнө гэмтэн этгээдийг өгнө.
Серверийн гарц нь VPN-ийн төгсгөлийн цэг биш үед
Олон сайт серверүүд болон төвлөрүүлэгчийн хооронд галт хана тавьдаг. Тэр галт хана хариуг дамжуулдаг тул таны клиентийн угтварт зориулсан VPN гарц руу заасан маршрут, хоёр чиглэлд дамжуулах бодлого хэрэгтэй. Төлөв хадгалдаг төхөөрөмжүүд байдлыг улам дордуулдаг: хүсэлт нь түүний зөвшөөрсөн LAN хостоос галт ханыг давсан, хариу одоо өөр чиглэлээс ирж байна, холболт хянах бичлэг дахин тохирохгүй байгаа тул пакет татгалзагдахын оронд хүчингүй гэж хаягдана. Трафик алга болох үед бодлогын бүртгэл хоосон харагдах шалтгаан энэ.
Гарц өөрийн хоёр дахь шүүлтүүртэй. Linux-ийн урвуу замын шүүлтүүр нь эх үүсвэр нь ирсэн интерфэйсээр хүрэх боломжгүй пакетуудыг хаядаг бөгөөд энэ нь хууль ёсны тэгш бус буцах замын яг хэлбэр юм. strongSwan-ийн дамжуулалтын заавар яг энэ шалтгаанаар net.ipv4.ip_forward ба суларсан net.ipv4.conf.all.rp_filter шаарддаг. Аль ч гарц дээр хатуу 1 утга зөв маршрутыг чимээгүй эвддэг бөгөөд хаана харахаа мэдвэл nstat -az хаялтуудыг харуулна.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Чиглүүлэх эсвэл хөрвүүлээд, дараа нь хоёр чиглэлд шалгана уу
Хоёр засвар тэнцүү биш. Маршрут нэмэх нь клиентийн хаягийг хөндөхгүй үлдээдэг тул эх үүсвэрт суурилсан дүрэм, аудитын бүртгэл, дуудагчийг тэмдэглэдэг програмууд үргэлжлүүлэн ажиллана; үнэ нь шийдвэр гаргадаг үсрэлт бүрт маршрут хэрэгтэй, өөрөөр хэлбэл алдаа гаргах илүү олон газар. Алслагдсан гарц дээрх маск буцах замыг нэг үсрэлт болгон хумидаг, учир нь хариу одоо гарц өөрт рүү хаяглагдсан, мөн аль клиент юу хийснийг нуудаг.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEҮүнийг санаатайгаар сонгоно уу: клиентүүд гарцын хаяг мэт харагдаж эхэлмэгц эх үүсвэрт суурилсан ACL-ууд тэднийг ялгахаа болих бөгөөд хариуг туннель руу буцааж бичихийн тулд conntrack зураглалыг барих ёстой. Хэрэв селекторууд клиентийн угтварыг орхигдуулснаар байвал NAT юу ч өөрчлөхгүй, учир нь хүсэлт туннельд хэзээ ч ороогүй.
Үүнийг зассан гэж хэлэхийн өмнө дөрвөн зүйлийг дараалан баталгаажуулна уу: хариу илгээж буй хост дээрх маршрут, түүнийг дамжуулж буй үсрэлт бүр дээрх маршрут, хоёр угтварыг хамарсан селекторууд, хариу таны хүлээж буй эх үүсвэртэйгээр туннельд орж буйг харуулсан бичлэг. Дараа нь туршилтыг нөгөө сайтаас давтана уу. Нэг чиглэл дамжих нь хагас нээлттэй загвар бөгөөд хоёр дахь чиглэл ихэвчлэн дөнгөж зассан зүйлээс өөр шалтгаанаар бүтэлгүйтдэг.