OpenVPN: local kumpara sa address ng tunnel, dalawang magkaibang socket

Tumanggi ang client na magsimula at nagrereklamo na hindi ito makapag-bind ng lokal na address, at ang halatang ayos ay tila itinuturo ito sa tunnel address na inaasahan nitong matanggap. Hindi iyon maaaring gumana, at sulit na maunawaan ang dahilan: bago umiral ang tunnel ay walang address sa loob, at ang socket na kumakausap sa server ay dapat na umiiral muna. Dalawang magkaibang address ang sangkot, at isa lamang sa kanila ang mapipili nang lokal.

Pinangalanan ng bind error ang isang lokal na address

Kapag iniulat ng OpenVPN na hindi ito makapag-bind ng lokal na address, tungkol ito sa transport socket: ang UDP o TCP endpoint na nagdadala ng naka-encrypt na koneksyon patungo sa peer.

Ang tahasang local directive ay humihiling sa daemon na i-bind ang socket na iyon sa isang partikular na lokal na address. Dapat umiiral ang address sa network namespace kung saan tumatakbo ang proseso, at dapat itong maitalaga sa sandaling magsimula ang client.

Ang pampublikong address na isinalin sa router o sa gilid ng cloud ay hindi lokal na address na maaaring i-bind ng daemon, kahit na iyon ang address na nakikita ng server. Ipinapaliwanag ng pagkakaibang ito kung bakit gumagana ang isang profile sa bahay at nabigo sa isang cloud instance. Ipinapaliwanag din nito kung bakit hindi tumutulong ang pagdaragdag ng pampublikong address sa isang loopback interface, dahil kukuha ang transport ng pinagmulan mula sa isang address na hindi maibabalik ng network. Basahin ang listahan ng interface bago i-edit ang profile.

Ano ang aktwal na pinipili ng local at remote

Pinangalanan ng remote ang peer na kakausapin. Ini-bind ng local ang malapit na dulo ng parehong socket. Hinahayaan ng nobind ang operating system na pumili ng lokal na address at port, kaya kadalasang gumagana ang mga client sa likod ng home router nang wala ang alinman sa dalawang directive.

Wala sa alinmang directive ang may kinalaman sa address sa loob ng tunnel.

Sa isang container o network namespace, pareho ang tuntunin na may mas makitid na hangganan: wala sa loob ang mga address ng host, kaya ang linyang local na kinopya mula sa host configuration ay nabigo sa ganap na ibang dahilan kaysa sa isang maling address.

ip -brief address show
ip route get 203.0.113.10

Ang address sa loob ay nagmumula sa server

Ang address sa loob ng tunnel ay pinag-uusapan o itinatalaga pagkatapos maitatag ang control channel. Sa isang dynamic pool, ang server ang nagpapasya nito sa oras ng pagkonekta, at sa client-specific configuration maaari itong nakapirmi sa bawat pagkakakilanlan.

Ang pagsulat ng local na may address sa loob ay hindi humihiling sa server na italaga ang address na iyon. Sa pinakamainam na kaso ay nabigo ang bind; sa pinakamasama, makakahanap ang client ng walang kaugnayang host address na may parehong halaga at gagamitin ito para sa transport.

Iba rin ang mga interface na dapat basahin. Inilalarawan ng mga parameter ng ifconfig at ng pool configuration ang loob, habang inilalarawan ng remote, local, proto at nobind ang labas. Ang paghihiwalay ng dalawang listahan ay nagpapaliwanag sa halos lahat ng nakalilitong halimbawang makikita mo sa isang forum. Iyon ang dahilan kung bakit dokumentado ng manual ng OpenVPN 2.6 ang mga ito sa magkakahiwalay na seksyon.

Ang bitag: isang buong tunnel na humuhuli sa sarili nitong transport

Kapag nakataas na ang tunnel at nagdadala ng default route, ang mga packet na nagpapanatili nito ay hindi dapat i-route papasok dito. Problema ito sa routing at hindi sa addressing, at hinahawakan ito ng daemon sa pamamagitan ng paglalagay ng mas tiyak na ruta patungo sa sariling address ng server sa pamamagitan ng orihinal na gateway.

Kung ikaw ay magpipirmi ng transport sa isang partikular na lokal na address at mamaya ay babaguhin ang landas na ginagamit ng address na iyon, maaaring mawala sa landas ang panlabas na koneksyon habang nananatiling naka-configure ang loob. Patuloy na nag-uulat ang tunnel na konektado dahil maayos ang loob. Ang transport lamang ang sira, kaya parang magkakasalungat ang mga log.

Ang mga sintomas ay mukhang isang tunnel na kumokonekta at nagyeyelo, o isang paulit-ulit na kumokonekta sa loop nang walang kapaki-pakinabang na error. Suriin ang ruta patungo sa address ng peer bago suriin ang anuman sa loob ng tunnel, at kumpirmahin na ang lokal na address na na-bind mo ay pag-aari pa rin ng interface na inaasahan mo.

Isang ugali na pumipigil sa pagkalito

Basahin ang bawat address sa isang profile at magpasya kung aling layer ito kabilang bago ito i-edit.

Kung pinangalanan nito ang malayong dulo ng transport o ini-bind ang malapit na dulo nito, ito ay panlabas na address at dapat umiiral bago magsimula. Kung inilalarawan nito ang nangyayari sa loob ng tunnel, nagmumula ito sa server o sa topology, at walang lokal na directive ang makapapalit dito.

Isulat ang dalawang listahan sa mga tala ng deployment sa tabi ng profile. Ang susunod na sesyon ng pag-troubleshoot ay magsisimula sa layer sa halip na sa isang hula.