Ang mga kahilingang i-route ang VPN sa ikalawang uplink ay naglalarawan ng hindi bababa sa dalawang magkaibang gawain, at ang patakarang nag-aayos ng isa ay hindi hinahawakan ang isa. Sa unang gawain, lumilipat ang naka-encrypt na transportasyon sa pagitan ng dalawang dulo patungo sa ibang address ng WAN. Sa pangalawa, lumalabas ang na-decrypt na daloy ng aplikasyon ng konektadong gumagamit patungo sa ibang susunod na hop. Pareho silang lehitimo, parehong gumagamit ng routing, at bawat isa ay nangangailangan ng tugma sa isang packet na umiiral sa puntong ginagawa ang desisyon. Sundan ang mga pagsusuri sa ibaba sa pagkakasunod-sunod, dahil ang una ang nagtatakda kung aling packet ang dapat pangalanan ng mga susunod na patakaran.

Pangalanan ang dalawang usapan

Isipin ang isang malayuang manggagawa na konektado sa isang gateway ng opisina, na nagbubukas ng HTTPS papunta sa isang panloob na server ng aplikasyon. May dalawang malayang usapan sa kawad, at may magkaibang address ang mga ito sa bawat dulo. Ang panlabas na usapan ay dumadaan sa pagitan ng dalawang dulo ng VPN: mula sa address ng gateway patungo sa address ng peer, sa protocol at port na napagkasunduan ng deployment. Ang panloob na usapan ay mula sa address na ibinigay sa kliyente patungo sa address ng server ng aplikasyon sa port 443.

Ang port ng destinasyon ng aplikasyon ay hindi ang port ng transportasyon ng VPN, at walang dami ng patakaran sa TCP 443 ang makakagalaw ng tunnel. Gayundin, ang patakarang nagre-redirect ng address ng transportasyon ng peer ay walang sinasabi tungkol sa kung saan pumupunta ang HTTP request ng gumagamit na iyon pagkatapos ng decryption. Isulat ang dalawang usapan kasama ang kanilang tunay na address bago hawakan ang isang patakaran, dahil ang karamihan ng kalituhan sa larangang ito ay nagmumula sa pagpapangalan ng isa at pag-configure ng isa pa.

Hanapin kung saan talaga nakikita ng inyong patakaran ang packet

Ang tugma ay dapat suriin sa chain at namespace kung saan ang packet ay nasa anyong inilarawan ninyo. Ang patakarang nakakabit sa LAN ingress ay nakikita ang panloob na packet, hindi naka-encrypt, bago ito i-route patungo sa tunnel. Ang patakarang inilapat sa trapikong nalilikha nang lokal ay nakikita ang mga packet na nililikha mismo ng gateway, at hindi nito awtomatikong sinasaklaw ang trapikong ipinapasa lang ng gateway. Ang naka-encapsulate na output ay pangatlong kaso na naman, karaniwang hinahawakan sa interface na nagdadala ng tunnel at hindi sa panig ng LAN.

Ito ang dahilan kung bakit ang parehong piraso ng configuration ay kumikilos nang iba sa dalawang plataporma: magkaiba ang mga punto ng pagkakabit, at ang policy hook ng isang vendor ay maaaring nasa bago o pagkatapos ng hakbang ng encryption. Basahin ang landas ng packet para sa partikular na produkto sa halip na ipagpalagay ang pagkakasunod-sunod mula sa diagram ng ibang vendor.

Kumpirmahin ang transportasyong napagkasunduan

Para sa IPsec na naka-encapsulate sa UDP, RFC 3948 inilalagay ang ESP sa loob ng UDP at gumagamit ng markang hindi ESP upang manatiling nakikilala ang IKE sa pinagsasaluhang port. Ang plain ESP ay isang protocol ng IP, hindi port ng TCP o UDP, kaya ang patakaran ng firewall na isinulat sa numero ng port ay hindi ito tutugma sa anumang paraan. Ang pagkakaibang ito ang nagtatakda kung ang inyong WAN policy ay nangangailangan ng patakaran sa UDP, patakaran sa protocol, o pareho.

Ang mga napagkasunduang halaga ay nananaig sa mga naaalala. Basahin ang kasalukuyang port at address ng asosasyon mula sa device sa halip na magdagdag ng TCP 4500 o lumang port ng vendor para sa anumang pagkakataon, na humuhuli ng walang kaugnayang trapiko at nagtatakip sa tunay na suliranin sa pag-uuri.

Suriin ang daan pabalik bago magpakabigkis

Ang tagumpay pakanluran ay nagpapatunay ng kalahati ng isang disenyo. Ang packet na bumabalik patungo sa pool ng malalayong kliyente ay hindi na nakikita sa ilalim ng address ng kliyente kapag pinalitan ito ng encapsulation: ang panlabas na destinasyon ay ang address ng transportasyon ng peer. Kung ang ikalawang uplink ay umaabot sa peer na iyon sa ibang carrier, maaaring hindi sumang-ayon ang translation at filtering nito sa una, at ang asosasyon ay maaaring kailanganing itayong muli sa halip na ilipat.

Ang estado ng network address translation ang karaniwang biktima ng pagpalit ng WAN. Itala ang napiling uplink, ang inaasahang panlabas na source address, ang translation na ginagamit at ang abot ng peer pabalik dito, pagkatapos ay panatilihing abot ang transportasyon nang hindi ito ipinapadala sa tunnel na dinadala nito.

I-verify ang parehong layer gamit ang dalawang capture

Ang isang capture sa interface ng WAN at isa sa loob ng tunnel ay mas mabilis na nagtatapos sa tanong kaysa anumang paghahambing ng configuration. Patakbuhin ang mga ito mula sa gateway habang ang isang aprubadong kliyente ay gumagawa ng isang kahilingan, at itago ang parehong file.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Ang unang capture ay dapat magpakita ng panlabas na usapan na lumalabas sa interface na nilayon ninyo, kasama ang inaasahang source address. Ang pangalawa ay dapat magpakita ng panloob na usapan nang isang beses, hindi nadoble, na ang address ng kliyente ang pinagmulan at ang server ng aplikasyon ang destinasyon. Kinukumpirma ng paghahanap ng ruta kung aling table ang gagamitin ng router para sa pares na pinagmulan at destinasyon, at doon karaniwang lumilitaw ang pagkakamali sa patakaran. Kung alinman sa mga capture ay hindi lumitaw, ang punto ng desisyon ay nasa ibang lugar at hindi kung saan ikinabit ang patakaran, at ang pagwawasto ay naroon at hindi sa mas malawak na tugma.

Kaugnay na mga artikulo