Dalawang address ng serbisyo sa isang kliyenteng OpenVPN: iroute at lo

Sumasagot ang aplikasyon sa address ng tunnel nito, at ang address na naidokumento mo para dito ay walang patutunguhan. Walang nagrereklamo sa log ng OpenVPN, lumilitaw na konektado ang peer, at eksaktong isang kliyente lang ang inililista ng hub. Ang puwang ay ang pangalawang address sa isang kliyente ay dalawang magkahiwalay na katotohanan: dapat itong pag-aari ng host, at dapat malaman ng hub kung aling peer ang nagmamay-ari nito. Asikasuhin ang isa nang wala ang isa at mamamatay ang trapiko sa hub o darating nang walang rutang pauwi.

Lokal ang alias, malayo ang pagmamay-ari

Napag-uusapan ang address ng tunnel, kaya natututunan ito ng magkabilang dulo sa handshake. Ang karagdagang address ng serbisyo ay hindi napag-uusapan, kaya hindi nagbabago ang anuman sa hub kapag idinagdag ito nang mag-isa. Maaaring pag-aari na ng kliyente ang address kaagad at ipapadala pa rin ng server ang trapikong iyon sa default nitong landas o itatapon ito. Dapat gumawa ng dalawang rekord, sa dalawang magkaibang lugar.

Sa kliyente, pag-aari ng host ang address, at ang loopback ang natural na tahanan ng pagkakakilanlan ng serbisyo na hindi dapat kailanman lumitaw sa pisikal na link. Sa hub, ang pagmamapa ng peer sa prefix ay hiwalay na deklarasyon na ang server lang ang nagbabasa. Wala sa dalawang rekord ang nangangahulugan ng isa pa.

Panatilihing hiwalay ang dalawang saklaw sa iyong mga tala. Ang mga address sa isang halimbawa ay mga halaga ng dokumentasyon, at ang pag-overlap sa mga ito sa totoong LAN ay ang pinakamabilis na paraan para magmukhang sira ang gumaganang setup.

Idagdag ang address sa kliyente nang permanente

Ilagay ang address ng serbisyo sa loopback na may prefix ng host, para ituring ito ng host bilang lokal na input at hindi bilang subnet na dapat abutin. Ginagawa ito ng ip address add 10.66.0.10/32 dev lo para sa isang address, at ang pag-uulit ng utos para sa pangalawang address ay nagmomodelo ng dalawang serbisyo.

Patakbuhin ito bilang isang beses na pagsubok, pagkatapos ilipat sa kung ano ang may-ari ng network configuration ng host, dahil nawawala ang dagdag sa runtime kapag nag-reboot at naiipon ang mga kopya sa pagitan ng mga muling pagkonekta. Ang isang systemd unit na inayos pagkatapos ng network ay isang opsyon, at ang network manager ng distribution ay isa pa. Anuman ang piliin mo, dapat umiral ang address bago mag-bind ang aplikasyon, kung hindi ay bubukas ang serbisyo sa maling socket. I-verify gamit ang ip address show dev lo pagkatapos ng reboot at hindi pagkatapos ng manu-manong utos.

Ang pag-bind ay hiwalay na desisyon sa pag-address. Ang aplikasyong nakikinig sa bawat address ay tumatanggap ng trapiko sa mga interface na hindi mo kailanman sinadya, kaya ituro ito sa partikular na address ng serbisyo. Pagkatapos, may tiyak na maipapares ang lokal na patakaran ng input.

Hilingin ito sa CCD file na talagang binabasa ng hub

Sa server, pumapasok ang deklarasyon ng pagmamay-ari sa file ng bawat kliyente na pinipili ng authenticated na karaniwang pangalan, sa loob ng direktoryong pinangalanan ng client-config-dir. Ang linya ay iroute 10.66.0.10 255.255.255.255, isa sa bawat address, at sinasabi nito sa server kung aling peer ang dapat tumanggap ng trapiko para sa destinasyong iyon.

Dalawang detalye ang tahimik na sumisira dito. Dapat tumugma ang pangalan ng file sa pangalan na talagang ginagamit ng server, na iba kapag nasa laro ang username-as-common-name. At iroute ay may bisa lamang sa TUN mode na may naka-configure na direktoryo ng configuration ng kliyente, kaya ang parehong linya ay walang ginagawa sa bridged deployment. Magdagdag ng mga linya sa umiiral na file sa halip na palitan ito, dahil maaaring may dalang fixed address o push options. Dinodokumento ng OpenVPN 2.6 reference ang direktoryo at ang direktiba ng pagmamay-ari.

Kailangan din ng kernel ng hub mismo ng landas patungo sa mga destinasyong iyon para makapasok ang trapikong lokal na nalikha sa proseso ng tunnel. Sinasaklaw ng route 10.66.0.10 255.255.255.255 sa configuration ng server ang trapikong pinanggagalingan ng server mismo, habang ang ibang kliyente ay nangangailangan ng push "route 10.66.0.10 255.255.255.255" para matutunan mismo ang destinasyon.

Nananatiling hiwalay ang routing at awtorisasyon. Sinasabi ng itinulak na ruta sa kliyente kung saan ipapadala ang mga packet at wala itong ibinibigay; kailangan pa ring tanggapin ng serbisyo ang tumatawag sa sarili nitong mga tuntunin.

Suriin ang patakaran ng input at ang landas ng tugon

Ang packet na naka-address sa alias ay dumarating sa host na may-ari bilang lokal na input, kaya ang tanong ay kung pinapayagan ng lokal na firewall ang pinagmulang iyon at port. Payagan ang partikular na port ng serbisyo mula sa saklaw ng pinagmulan ng VPN sa halip na buksan ang buong address.

Kailangan ng mga tugon ng landas pabalik sa tumatawag. Para sa tumatawag sa loob ng normal na pool ng tunnel, umiiral na ang landas na iyon dahil dinadala ito ng tunnel device. Ang tumatawag sa likod ng isa pang naka-routing na network ay nangangailangan din ng rutang pabalik ng network na iyon, at dito nawawalan ng packet ang mga asymmetric na setup.

Mag-ingat sa pangalawang listener sa parehong port na nakatali sa ibang address, dahil inihahatid ng kernel sa socket na tumutugma at mukhang random ang mga resulta. Suriin gamit ang ss -lntp at kumpirmahin na ang nakataling address ay ang alias ng serbisyo. Hindi kailangan ang source NAT dito, at ang pagdaragdag nito ay nagtatago ng pagkakakilanlan ng tumatawag na umaasa ang iyong mga log.

Subukan ang mga address at pagmamay-ari nang hiwalay

Subukan sa dalawang hakbang. Una, kumpirmahin na naaabot ng host na may-ari ang serbisyo sa alias nito mula sa sarili nito, na naghihiwalay ng mga problema sa binding at firewall mula sa routing. Pagkatapos, subukan mula sa tunay na tumatawag ng VPN gamit ang authentication ng aplikasyon mismo. Kapag pumasa ang una at nabigo ang pangalawa, ang nawawalang piraso ay nasa panig ng hub.

Suriin din ang mga failure mode na nabubuhay pagkatapos ng koneksyon: nananatiling nakatalaga ang alias kapag bumaba ang tunnel, at pinapanatili ng hub ang ruta nito kapag wala ang peer. Walang bagay na nag-iisa ang nagpapatunay na naaabot ang serbisyo, kaya nalalampasan ng two-step test ang isang ping mula sa laptop.