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

Хайлт нь эх сурвалжийг дахин бичихээс өмнө болдог

VPN клиентээс дамжуулагдах пакетийн хувьд цөм тогтмол дарааллыг гүйцэтгэдэг. Тэр туннелийн интерфейс дээр ирж, conntrack ба DNAT байдаг prerouting-оор өнгөрч, дараа нь маршрутын шийдвэр гарч, дараа нь дамжуулалт, дараа нь SNAT хамгийн сүүлд хэрэгжих postrouting. from хэлбэрийн дүрмийг тэр маршрутын шийдвэрийн үеэр авч үздэг, өөрөөр хэлбэл энэ нь клиентийн анхны хаягийг хардаг, хөрвүүлсэн хаягийг биш.

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

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

StageSource the kernel seesWhat it means for your rule
PreroutingClient address, 172.31.7.42Where marks and DNAT are applied
Routing decisionStill 172.31.7.42This is where from rules match
PostroutingBecomes 198.51.100.9What the far end and its return route see

Тиймээс өөр эх сурвалжтай хоёр pool-д үнэхээр өөр хүснэгт хэрэгтэй бөгөөд загвар зөв байна. Дээрх хүснэгтийн үгүйсгэж буй зүйл бол холын сайт юу хүлээн авсныг хараад дүрмийг түүнээс гаргаж авах богино зам юм.

Gateway-ээс хийсэн туршилт нь pool-ын туршилт биш

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

Клиентийг ойролцоолохын оронд дуурай. Маршрутын хайлтаас шууд асууж болно, эх сурвалж ба оролтын интерфейс өгч:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

Давуу эрх, файл дахь байрлал биш

Дүрмүүдийг давуу эрхийн өсөх дарааллаар үнэлдэг бөгөөд чухал нь тоо, таны бичсэн дараалал биш. local хүснэгт давуу эрх 0 дээр, main хүснэгт 32766 дээр, анхдагч дүрэм 32767 дээр байдаг, тиймээс анхдагч давуу эрхээр нэмсэн дүрэм жагсаалтын төгсгөлд ойртож, бараг бүх зүйлд ялагдана.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

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

Бүрэн бус хүснэгт рүү заасан тохирох дүрэм нь нөгөө урхи. Хэрэв 201 хүснэгтэд анхдагч маршрут байгаа ч хүрэх газар руу маршрут байхгүй бол пакет хаягдах эсвэл буруу газар илгээгдэх бөгөөд дүрэм тусгаарлагдсан байдлаар бүрэн зөв харагдана. Дүрмийг биш, хүснэгтийг унш. Дүрэм бол заагч, хоосон хүснэгт бол юу ч биш рүү заагч.

Буцах зам байх ёстой хэвээр

Эх сурвалжийн бодлого гарах гарцыг сонгоно. Энэ нь буцах зам үүсгэхгүй. Хэрэв хоёр дахь pool түншийн туннелээр гарвал түнш 172.31.8.0/24-т хэрхэн хүрэхийг мэдэх ёстой, эсвэл gateway руу буцах маршрутаар, эсвэл өөрөө аль хэдийн мэддэг хөрвүүлсэн хаягуудыг хүлээн авч.

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

Юу ч сонгосон, түүнийгээ pool-ын тодорхойлолтын хажууд бич. Зөвхөн хэн нэгний ойд оршиж буй буцах маршрут бол түнш галт хана солих хүртэл амьдарч, дараа нь дахин бүтээхэд нэг өдөр зарцуулагдах зүйл юм.

Бодлогод gateway-ийн өөрийн туннелийг бүү бари

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

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

ip-rule гарын авлагын хуудас сонгогч ба давуу эрхийн утга санааг баримтжуулдаг. Үүнийг pool бүрийн хайлтын туршилттай хослуулбал загвар шалгагдахуйц болно, энэ нь нэг жил тэсвэрлэх бодлогын маршрутлалт ба бүгд хүрэхээс айдаг маршрутлалтын ялгаа юм.

Холбоотой нийтлэлүүд