Bakit Pinuputol ng Ruta ng Buong Tunnel ang Server na Nagdadala Nito

I-on ang buong tunnel at ang bawat destinasyon ay pag-aari na ngayon ng VPN interface, kasama ang makina na nagtatapos nito. Ang mga panlabas na pakete na nagdadala ng tunnel ay naka-address sa makinang iyon, kaya ang ruta sa huli ay kumakain ng transportasyong nakasalalay ito. Isang karagdagang partikular na ruta ang lumulutas nito, at sulit intindihin ang dahilan. Kung wala ang dahilang iyon, ibabalik ng susunod na muling pagtatayo ang depekto.

Isang rutang kumakain ng sarili nitong transportasyon

Binabalot ng encapsulation ang bawat pakete sa pangalawang header. Ang panlabas ay naka-address mula sa lokal na pisikal na address patungo sa pampublikong address ng server, at kailangan nitong tumawid sa pisikal na link bago pa man umiral ang anumang tunnel.

Ngayon hayaang piliin ng paghahanap sa pampublikong address na iyon ang tunnel. Upang maipadala ang pakete, kailangang i-encapsulate ito ng makina, na nangangailangan ng ruta patungo sa parehong address, at ibinabalik nito ang tunnel. Dalawang paraan ang ginagawa ng mga kliyente. Ang maingat ay tumatangging i-install ang default na ruta at nag-uulat ng error, habang ang hindi gaanong maingat ay nag-uulat ng tagumpay at pagkatapos ay walang inililipat. Ang tahimik na pagkabigo ang kumakain ng isang hapon.

Ang tugma ng pinakamahabang prefix ang nagpapasya sa paghahanap bago tingnan ang anumang sukatan, kaya ang rutang may isang address ay lumalampas sa bawat default na ruta sa makina. Iyon ang buong mekanismo sa likod ng pag-aayos.

I-install ang eksepsiyon bago ang default

Gumawa ng rutang may isang address para sa server, gamit ang pisikal na gateway bilang susunod na hop, bago gumalaw ang default na ruta. Mahalaga ang pagkakasunod-sunod: ang pag-install nito mamaya ay nangangahulugang mabubuhay ka sa sirang tunnel habang nagta-type.

Ginagawa ito ng karamihan ng kliyente nang hindi pinapakiusapan. OpenVPN hinahanap ang malayong address at ipinipin ito bago isulat muli ang default na gateway, at ang opsyon nitong route-delay ay para sa mga plataporma kung saan nag-uunahan ang pagkakasunod-sunod na iyon. Ang wg-quick ay pumapasok sa ganap na ibang daan, sa pamamagitan ng pagmamarka ng mga pakete at pagsangguni sa isang tuntunin ng patakaran sa halip na magdagdag ng eksepsiyon. Iba't ibang mekanismo, iisang pangangailangan: kailangang makatakas ang panlabas na pakete mula sa tunnel na nilikha nito.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Ang output ng paghahanap ang pagsubok sa pagtanggap. Kailangan nitong pangalanan ang pisikal na aparato at ang pisikal na susunod na hop. Ang aparatong tunnel sa sagot na iyon ay nangangahulugang kulang ang eksepsiyon, o inilagay ito pagkatapos ng isang bagay na humihigit dito.

Ang salamin sa server

Ang parehong bitag ay naghihintay sa kabilang panig, baliktad. Bigyan ang server ng default na ruta sa ibang tunnel, o itulak ito ng rutang sumasaklaw sa mga pampublikong address ng mga kliyente, at ang mga sagot nito ay magkakaroon ng ugali ng maling direksyon.

Isipin ang isang kliyenteng kumokonekta at nagpapadala ng kahilingan. Ang sagot ay naka-address sa pampublikong address ng kliyenteng iyon, na tugma na ngayon sa isang rutang tunnel, kaya lumalabas ito sa ibang interface dala ang pinagmulang hindi kailanman pinili ng kliyente. Maaaring matanggap ng kliyente ang paketeng iyon at itapon pa rin ito, dahil walang nag-uugnay nito sa kahilingang ipinadala niya. Magsimula sa desisyon sa routing ng server sa halip na sa timeout ng kliyente, dahil isa lamang sa kanila ang nagpapakita ng tunay na pagpili.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

May tatlong pag-aayos at hindi sila pantay. Ang pag-pin ng serbisyo sa pisikal na address, o ang pagsasalin ng pinagmulan, parehong itinatago ang desisyon sa routing sa halip na itama ito. Ang pagpapadala ng trapikong sagot para sa pool ng tunnel sa pamamagitan ng nakalaang talahanayan ay nag-aayos ng sanhi, at ang dalawa pa ay katanggap-tanggap lamang habang nakapirme ang disenyo ng routing.

Mga eksepsiyong patuloy na ninanakaw ng tunnel

Kakaunting gawain ang nangangailangan ng bukas na internet kahit pag-aari ng tunnel ang default na ruta, at bawat isa ay nangangailangan ng sariling eksepsiyon. Ang dynamic na DNS updater ang kadalasang unang nasisira.

Nire-resolve nito ang provider, nagbubukas ng koneksyon, at natuklasan nitong dumadaan ang sarili nitong mga pakete sa isang tunnel na nagbago ang address ilang segundo lang ang nakalipas, kaya nabigo ang update o nai-publish ang maling address. Tatlong labasan: i-pin ang provider gamit ang host route sa pisikal na gateway, patakbuhin ang update bago umangat ang tunnel, o bigyan ang updater ng talahanayan ng patakarang hindi kailanman hinahawakan ng tunnel. Ang pag-sync ng oras ay may parehong pagkakalantad sa aparatong nagbu-boot na walang resolver, at ang mga endpoint ng pagpapatunay ng sertipiko ay kabilang sa listahan sa parehong dahilan.

Ang eksepsiyong walang nakasulat ay eksepsiyong tahimik na ibabagsak ng susunod na muling pagtatayo.

Patunayan ito pagkatapos ng muling pagkonekta, hindi bago

Subukan ang tatlong destinasyon, hindi isa: ang dulo, isang pribadong address sa likod ng tunnel, at isang pampublikong address sa kabila. Ang isang matagumpay na paghahanap ay halos walang sinasabi tungkol sa dalawa pa.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Pagkatapos, i-restart ang koneksyon, dahil ang kliyenteng muling bumubuo ng talahanayan nito kapag muling kumonekta ay itatapon ang rutang kinakamay mong ini-type. Kung may kill switch, tiyakin na pinapayagan ang dulo, kung hindi ay hindi na makakabalik ang tunnel pagkatapos ng pagbabago sa network at magmumukhang pagkawala ang sintomas. Itabi ang eksepsiyon sa profile o sa unit file sa halip na sa kasaysayan ng shell, upang muling likhain ito ng muling pagkonekta sa halip na burahin.