Routing ayon sa pinagmulan para sa dalawang pool ng VPN: ano ang pinalalampas ng iyong patakaran
Ang patakarang may anyong from ay tumutugma sa address ng kliyente bago ito muling isulat ng SNAT, at ang pagsubok mula sa gateway ay hindi tumutugma sa alinman. Patakbuhin ang paghahanap bawat pool at basahin ang mga prayoridad.
Dalawang pool ng kliyente, isang gateway, at ang plano ay mukhang trivial: ipinapadala ng isang patakaran ang unang pool sa mabilis na uplink, ipinapadala ng isa pa ang ikalawang pool sa tunnel ng kasosyo. Pagkatapos ay naroon na ang mga patakaran at lumalabas pa rin ang ikalawang pool sa default na ruta. Hindi sira ang patakaran. Ang pinagmulan ng packet ay hindi ang inaasahan ng may-akda sa sandali ng paghahanap, dahil nagaganap ang pagsasalin at paghahanap sa magkaibang punto sa paglalakbay ng iisang packet, at ang pagkakasunod-sunod ay kabaligtaran ng mental na diagram na iginuguhit ng karamihan.
Nagaganap ang paghahanap bago muling isulat ang pinagmulan
Para sa packet na ipinapasa mula sa kliyenteng VPN, nagsasagawa ang kernel ng takdang pagkakasunod-sunod. Dumarating ito sa interface ng tunnel, dumadaan sa prerouting kung saan naninirahan ang conntrack at DNAT, pagkatapos ay gagawin ang desisyon sa routing, pagkatapos ang pagpapasa, pagkatapos ang postrouting kung saan huling inilalapat ang SNAT. Ang patakarang may anyong from ay tinitingnan sa panahon ng desisyong iyon sa routing, ibig sabihin nakikita nito ang orihinal na address ng kliyente, hindi ang isinalin.
Kaya ang pagdaragdag ng patakarang masquerade ay hindi nagbabago kung aling patakaran sa patakaran ang tumutugma sa palabas na daloy. Ang nagbabago ay ang nakikita ng malayong dulo, at dahil dito kung aling daan pabalik ang umiiral. Dalawang magkaibang bunga ito, at lagi silang pinaghahalo ng mga review ng pagbabago. Paghiwalayin ang mga ito at kadalasang nagiging malinaw ang disenyo sa loob ng isang minuto.
Sa direksyon ng sagot lumilitaw ang isinaling address sa mga patakaran. Ang packet na bumabalik sa gateway ay nakatuon sa isinaling address, at kung mayroon kang mga patakaran sa patakaran batay sa destinasyon o sa interface na pinasukan nito, iyon ang halagang itatapat mo. Isang koneksyon, magkaibang pinagmulan ng katotohanan sa bawat direksyon.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Kaya ang dalawang pool na may magkaibang pinagmulan ay talagang nangangailangan ng magkaibang talahanayan, at tama ang disenyo. Ang hindi kasama ng talahanayan sa itaas ay ang shortcut ng pag-debug sa pamamagitan ng pagtingin sa natanggap ng malayong site at paghinuha ng patakaran mula roon.
Ang pagsubok mula sa gateway ay hindi pagsubok ng pool
Ang trapikong nililikha mismo ng gateway ay hindi kailanman dumadaan sa prerouting, dahil hindi ito dumating sa anumang interface. Dinadaan ito sa output path, na ang address ng gateway mismo ang pinagmulan, at ang patakarang from na batay sa hanay ng kliyente ay hindi tutugma. Bawat tiket sa larangang ito na nagsasabing gumagana ito mula sa kahon ngunit hindi mula sa kliyente ay pag-uulit ng gayunding katotohanan.
Gayahin ang kliyente sa halip na tantiyahin ito. Ang paghahanap sa routing ay maaaring tanungin nang direkta, na may pinagmulan at ingress interface na ibinigay:
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 201Patakbuhin ito nang isang beses bawat pool. Kung ibabalik ng dalawang utos ang parehong interface, hindi hinihiwalay ng mga patakaran ang mga pool, at ang dahilan ay alinman sa kulang na patakaran o patakarang may mas mataas na prayoridad na tumutugma sa pareho. Kung ibabalik nila ang magkaibang interface ngunit nabibigo pa rin ang kliyente, ang sira ay pagkatapos ng paghahanap at maaari mong ihinto ang pagtingin sa mga patakaran.
Prayoridad, hindi posisyon sa file
Ang mga patakaran ay sinusuri sa pataas na pagkakasunod-sunod ng prayoridad, at ang numero ang mahalaga, hindi ang pagkakasunod-sunod ng pag-type mo. Ang talahanayang local ay nasa prayoridad 0, ang talahanayang main sa 32766 at ang default na patakaran sa 32767, kaya ang patakarang idinagdag na may default na prayoridad ay lumalapag malapit sa dulo ng listahan at natatalo sa halos lahat.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Ang tahasang prayoridad ay nagpapakita ng nilalayong pagkakasunod-sunod sa file at sa review. Pinipigilan din nito ang karagdagang naidinagdag na tahimik na lumaktaw sa harap ng umiiral na patakaran, na siyang pinakakaraniwang dahilan kung bakit tumitigil sa paggana ang isang gumaganang patakaran pagkatapos ng walang kaugnayang pagbabago.
Ang tumutugmang patakaran na tumuturo sa hindi kumpletong talahanayan ay ang isa pang bitag. Kung ang talahanayan 201 ay may default na ruta ngunit walang ruta papunta sa destinasyon, itinatapon ang packet o ipinapadala sa maling lugar, at ang patakaran ay mukhang ganap na tama kapag nag-iisa. Basahin ang talahanayan, hindi lamang ang patakaran. Ang patakaran ay isang panturo, at ang walang laman na talahanayan ay panturo sa wala.
Kailangan pa ring umiral ang daan pabalik
Pinipili ng patakaran sa pinagmulan ang labasan. Hindi ito lumilikha ng daan pabalik. Kung ang ikalawang pool ay lumalabas sa tunnel ng kasosyo, dapat malaman ng kasosyo kung paano marating ang 172.31.8.0/24, alinman sa ruta pabalik sa gateway o sa pagtanggap ng isinaling address na alam na niya.
Ang pagpili sa pagitan ng dalawa ay desisyon sa disenyo na may nakikitang bunga. Ang pag-route pabalik ng hanay ng kliyente ay nagpapanatili ng pagkakakilanlan ng bawat kliyente sa kasosyo at nangangailangan na tanggapin niya ang iyong prefix. Itinatago ng pagsasalin ang pool sa likod ng isang address at nangangailangan na ang kasosyo ay tumanggap lamang ng address na iyon, kapalit ng hindi na magkasundo ang iyong log at ang kanya tungkol sa kung sino ang kumonekta.
Anuman ang piliin mo, isulat ito sa tabi ng depinisyon ng pool. Ang daang pabalik na umiiral lamang sa alaala ng isang tao ay eksaktong uri ng bagay na tumatagal hanggang baguhin ng kasosyo ang isang firewall, at pagkatapos ay tumatagal ng isang araw na muling buuin.
Huwag hulihin ang sariling tunnel ng gateway sa patakaran
Ang mga patakarang isinusulat mo para sa mga kliyente ay nalalapat din sa trapikong nililikha ng gateway, maliban kung ibubukod mo ito. Ang malawak na patakarang batay sa mark o sa output interface ay maaaring humuli sa sariling koneksyon ng gateway sa kasosyo, at pagkatapos ang tunnel na nagdadala ng patakaran ay ini-route ng patakaran. Nagdudulot ito ng loop o pagkaantala na mukhang sira ng provider.
Limitahan ang bawat patakaran nang kasing kitid ng pinapayagan ng disenyo: prefix ng pinagmulan, ingress interface at, kung sinusuportahan, mark na dala lamang ng mga packet ng kliyente. Pagkatapos ay subukan ang sariling koneksyon ng gateway pagkatapos ng bawat pagbabago ng patakaran, dahil ang sira ay sumasangguni sa sarili at hindi lumilitaw sa pagsubok mula sa kliyente.
Ang manual na pahina ng ip-rule ay nagdodokumento ng semantika ng tagapili at ng prayoridad. Pagsamahin ito sa pagsubok ng paghahanap bawat pool at nagiging masusuri ang disenyo, at iyon ang pagkakaiba ng routing sa patakarang tumatagal ng isang taon at ng isa na kinatatakutan ng lahat na hawakan.