Маршрутын хүснэгт ба бодит хайлт: VPN-ийн урсгал хаашаа явдаг

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

Хүснэгт бол нэр дэвшигчдийн багц, шийдвэр биш

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

Хайлт эхлээд дүрмээр, дараа нь хүснэгтээр дамждаг

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

ip rule show
ip route show table all | head -40
ip route show table 100

Хэрэв дүрэм таны VPN-ийн сангаас урсгалыг 100-р хүснэгт рүү илгээвэл чухал нь 100-р хүснэгт бөгөөд үндсэн хүснэгт бол өгөөш. Энэ нь мөн маршрутлагч дээрх эх үүсвэрт суурилсан маршрутлалтын механизм: нэг очих газар пакет хаанаас ирснээс хамаарч хоёр өөр хариулттай байж болох бөгөөд зөвхөн эх үүсвэрийн аргументтай хайлт аль нь үйлчилж байгааг илрүүлдэг.

IPv6 өөрийн дүрэм, хүснэгттэй. Хоёр гэр бүлийг ажиллуулдаг загварт хоёр хайлт хэрэгтэй бөгөөд ажиллаж буй IPv4 хариулт давхар стектэй клиент илүүд үзэж болох v6 замын талаар юу ч хэлэхгүй.

VPN клиент юу суулгадаг

Клиентүүд ихэвчлэн анхдагч маршрутыг сольдоггүй, учир нь энэ нь туннелийн өөрийн гадаад замыг эвдэх болно. Тэд префиксийн уртаар ялдаг илүү тодорхой зүйлийг суулгадаг: 0.0.0.0/1 ба 128.0.0.0/1-ийг хамарсан хагас анхдагч хос нь сонгодог арга, учир нь хоёулаа 0.0.0.0/0-ээс урт префикс бөгөөд хамтдаа бүх орон зайг хамардаг. Бусад нь тодорхой хувийн префиксүүд дээр бодлогын дүрэм суулгадаг, зарим нь зөвхөн сонгосон урсгал баригдахын тулд тэмдэг нэмдэг.

Тиймээс "VPN миний анхдагч маршрутыг өөрчлөөгүй" гэдэг нь бүтэлгүйтлийн нотолгоо биш. Энэ нь юу нэмсэн, тухайн очих газар тэдгээр префикс дотор байгаа эсэхийг шалгаарай:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

Гадаад зам ч мөн амьд үлдэх ёстой

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

Түншийн хаягийг дотоод очих газрыг шалгасан шигээ шалгаж, туннель руу биш физик интерфэйс рүү шийдэгдэж байгааг баталгаажуулаарай:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

Маршрутлалтын гаралт танд юу хэлж чадахгүй

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

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

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