OpenVPN-д холбогдсон ч ping, SMB хуваалт байхгүй юу? Гурван хаалгыг шалгаарай

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

Хаалга бүр өөр шинж тэмдгээр бүтэлгүйтдэг бөгөөд зөвхөн эхнийх нь VPN сервер дээр байдаг.

Дамжуулалт бол FORWARD гинжин хэлхээний бодлого юм

OpenVPN-ийн сонсогчийг хүлээн авах нь INPUT дээр явагддаг тул LAN руу чиглэсэн бүх пакет хаягдсан ч туннель холбогдож чадна. tun0 дээр ирж LAN интерфейсээр гарч буй урсгал FORWARD-оор дамждаг бөгөөд тэнд өгөгдмөл DROP бодлоготой хост түүнийг чимээгүй хаядаг. Өөр юунд ч хүрэхийн өмнө sysctl болон гинжийг хоёуланг нь шалгаарай: sysctl net.ipv4.ip_forward ба iptables -L FORWARD -v -n.

Хүссэн чиглэл болон түүнд хамаарах хариуг зөвшөөрөөрэй, жишээ нь туннелийн интерфейсээс LAN интерфейс рүү accept дүрэм ба established болон related урсгалд зориулсан stateful дүрэм. Хэрэв LAN өөр чиглүүлэгчийн ард байвал тэр чиглүүлэгчид клиентийн сан руу буцах зам эсвэл VPN сервер дээр source NAT хэрэгтэй. Илүү олон дүрэм нэмэхийн өмнө тэр замыг нэг ping-ээр баталгаажуулаарай, учир нь хүрэх боломжгүй дүрэм тоолуурт хэзээ ч харагдахгүй.

SMB-д нэг порт хангалтгүй

Файлын хуваалт нь нэг TCP 445 яриа биш. Илрүүлэлт UDP 137 ба 138, хуучин NetBIOS сессүүд TCP 139, орчин үеийн SMB сессүүд TCP 445 ашигладаг. Зөвхөн 445-ыг онгойлгосон дүрэм нь холбосон диск ажиллаж, сүлжээг үзэх ажиллахгүй, эсвэл эсрэгээрээ байх төвөгтэй нөхцөлийг үүсгэдэг.

Туннелээр дамжуулах том өгөгдөл нь эвдэрсэн хуваалт мэт харагдах MSS асуудалд ч таардаг. LAN-ийн бүрэн сегментийн хэмжээг зарласан SYN нь туннелийн бага MTU-аас болж хаягдаж, холболт гар барилдсаны дараа гацана. Дамжуулалтын зам дээр MSS-ийг хязгаарлах нь, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, ийм төрлийн гацалтыг арилгадаг. Хавтасны жагсаалтын оронд хэдэн мегабайтын хуулбараар шалгаарай, учир нь жижиг хариу том дамжуулалт өнгөрөхгүй үед ч өнгөрдөг.

Туннелийн адаптер шинэ сүлжээний профайл болж ирдэг

Windows адаптер бүрийг сүлжээний профайлд ангилдаг бөгөөд шинэ туннелийн адаптер ихэвчлэн Public-д ордог, тэнд файл болон принтерийн хуваалтын дүрмүүд хаалттай байдаг. Энэ нь файлын сервер дээрх хост галт ханын шийдвэр, VPN сервер дээрх чиглүүлэлтийн асуудал биш. Бодлого зөвшөөрч байгааг баталсны дараа ангиллыг санаатайгаар өөрчил Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private ашиглан, учир нь ангилал нь ямар орж ирэх дүрэм хүчинтэй байхыг ч өөрчилдөг.

Мөн профайл нь TCP 445 амжилттай байхад ping бүтэлгүйтэхийг тайлбарладаг: Public-д цуурайн хүсэлтүүд өгөгдмөлөөр хаягддаг.

Нэрс чиглүүлсэн туннелийг өөрөө гаталдаггүй

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

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

Нэг удаад нэг давхаргыг туршаад эхний алдааг уншаарай

Доороос дээш яв: туннелийн гарц руу ping хий, хаягаар LAN хост руу ping хий, дараа нь Test-NetConnection -ComputerName 10.8.0.5 -Port 445 ашиглан үйлчилгээний портыг онгойлгоод, зөвхөн дараа нь хуваалтад нэвтрэлт хий. Эхний бүтэлгүйтсэн алхам нь засах ёстой давхарга бөгөөд дараагийн алхам бүр тэр нь өнгөрөх хүртэл чимээ юм. Порт хаалттай байхад ping хариу өгвөл энэ нь файлын серверийн өөрийн галт хан руу заана, харин чимээгүй ping-ийн дараа ч порт онгойвол ICMP шүүлт рүү заана. Ямар нэгэн зүйл өөрчлөхийн өмнө эхний бүтэлгүйтсэн алхмыг бичиж аваарай, учир нь хоёр дахь өөрчлөлт эхнийхийн үр дүнг нуудаг.

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

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