Bakit ang UDP na sagot ng OpenVPN ay lumalabas mula sa maling address

Isang kliyente ng OpenVPN ang tumatawag sa isang address, sumasagot ang server mula sa iba, at hindi kailanman bumabangon ang tunnel. Ipinapakita ng log ng server na dumarating ang packet at ipinapakita ng isang capture na lumalabas ang sagot, kaya ang kliyente ang sinisisi. Sa isang host na may maraming interface, o maraming address sa isang interface, hindi lang talaga nagkakasundo ang dalawang panig kung aling address ang ginagamit. Wasto ang sagot sa antas ng IP, gayunpaman maraming kliyente ang nagtatapon ng datagram na ang pinagmulan ay hindi ang address na kanilang kinontak.

Ano ang nakikita ng kliyente kapag nagbago ang pinagmulan

Ang isang UDP socket na hindi nakatali sa isang partikular na lokal na address ay walang fixed na pinagmulan, kaya pumipili ang kernel ng isa kapag nagpapadala. Ang pagpiling iyon ay nagmumula sa paghahanap ng ruta patungo sa address ng kliyente, at ang pinagmulan ay nagiging address ng interface na pinipili ng paghahanap. Sa isang makina na may isang interface, hindi nakikita ang pagpili; sa isang host na may address ng pamamahala, pampublikong address at pangalawang address sa parehong network card, nakadepende ito sa mga sukatan ng ruta at patakaran. Ginagawa ng routing na batay sa patakaran ang pagkakaiba nang mas malamang sa halip na mas mababa, dahil ang isang tuntunin ay maaaring pumili ng upstream link na hindi naabot ng kliyente. Sapat na ang isang default na ruta na natutunan mula sa isang provider kasama ng tuntunin ng pinagmulan na tumuturo sa iba.

Ang mga kliyenteng nagsasala ng mga sagot, at ang pagsubaybay ng koneksyon na umaasa sa eksaktong apat at pinagmulan, ay itatapon ang sagot nang walang kapaki-pakinabang na mensahe. Pagkatapos ay nagtatapos ang oras ng tunnel na parang walang dumating, at iyon ang dahilan kung bakit ito ay napagkakamalang problema sa firewall sa panig ng kliyente. Ang isang capture na kinuha lamang sa server ay nagpapatunay sa pagkakamali sa halip na ipaliwanag ito, dahil talagang lumalabas ang sagot. Ihambing ang pinagmulan ng sagot sa address na tinawagan ng kliyente bago baguhin ang anupaman.

Ano ang talagang ginagawa ng opsyong multihome

Ang direktiba ay isinusulat bilang multihome sa isang configuration file at bilang --multihome sa command line, at pinapasagot nito ang isang UDP server mula sa address na naabot ng packet ng kliyente. Ipinapasa ng kernel ang orihinal na patutunguhang address bilang karagdagang datos sa pagtanggap, at ginagamit ng OpenVPN ang halagang iyon bilang pinagmulan ng sagot. Kaya ang isang server na nakikinig sa isang pangkalahatang address, local 0.0.0.0 para sa IPv4 o ang katumbas nito sa IPv6, ay kumikilos na parang naabot ng bawat kliyente ang isang nakalaang tagapakinig. Ang mga kliyenteng pumasok sa pampublikong address ay tumatanggap ng mga sagot mula sa pampublikong address, at ang mga kliyente sa panloob na address ay tumatanggap mula roon. Wala nang iba pang gumagalaw sa landas ng packet: ang ruta, ang mga tuntunin ng filter at ang configuration ng tunnel ay nananatiling eksaktong tulad ng dati.

Ang huling katangiang ito ang dahilan kung bakit ligtas idagdag ang opsyon sa isang server na gumagana sa ibang aspekto, at ito rin ang dahilan kung bakit hindi nito maayos ang isang filter na nagpapahintulot lamang ng isang address. Kailangan pa ring tanggapin ang packet sa landas na tinatahak nito, kaya binabago ng pagwawasto ng pinagmulan ang pinanggalingan ng sagot at wala nang iba. Para sa UDP lamang ito: ang isang tagapakinig ng TCP ay walang problemang ito sa parehong anyo, dahil ang koneksyon ay kinikilala ng apat at hindi ng address ng pinagmulan ng sagot.

Kailan ang fixed na lokal na address ang maling default

Bago kunin ang opsyon, tingnan kung ang server ay nagtatali ng isang partikular na lokal na address, dahil ang nakataling tagapakinig ay laging sumasagot mula sa address na iyon. Tama ito para sa isang deployment na may isang interface at mali sa sandaling legal na gumamit ang mga kliyente ng higit sa isang address. Kung ang pagtali ay sinadya, magpasya kung dapat tumanggap ng trapiko ang server sa mga karagdagang address. Ang pagtanggal ng pagtali ay nagdaragdag ng pagkakalantad, kaya ang mga pinapayagang interface at pinagmulang network ay dapat ipatupad ng serbisyo at ng filter, hindi lamang ng address ng pagtali.

Ang sanggunian ng OpenVPN ay nililimitahan ang opsyon sa mga server ng UDP, binabanggit ang karagdagang pagpoproseso sa landas ng packet, at itinatala kung aling mga platform ang sumusuporta nito. Kumpirmahin ito sa naka-install na release bago magplano batay doon. Kung saan hindi ito sinusuportahan, ang alternatibo ay italì ang partikular na address o ayusin ang rutang pabalik, at pareho itong mas makitid na pagbabago kaysa sa tila sa unang tingin. Ang pakikinig sa pangkalahatang address ay may mga kahihinatnan din lampas sa mga sagot: ang isang server sa lahat ng address ay maaabot mula sa bawat network kung saan nakakabit ang host, at maaaring hindi iyon ang pagkakalantad na inaasahan ng sinuman.

Patunayan ang pinagmulan ng sagot mula sa labas

Subukan mula sa labas ng server, at itala ang eksaktong address at transport na ginamit ng kliyente bago kunin ang anumang bagay. Ang tatlong pagsubok sa ibaba ay sumasagot sa tatlong magkakaibang tanong, at mahalaga ang pagkakasunod-sunod.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Ipinapakita ng capture ang address ng pinagmulan sa sagot, at ito ang katotohanang pinagbabatayan ng buong artikulo. Ipinapakita ng listahan ng socket kung ano talaga ang itinali ng server, dahil ang pangkalahatan at partikular na tagapakinig ay magkamukha sa isang configuration file at magkaiba ang kilos sa network. Ipinapakita ng paghahanap ng ruta ang pinagmulang pipiliin ng kernel para sa daloy na iyon, at ipinapaliwanag nito ang capture bago mo baguhin ang anuman. Ulitin ang tatlo para sa IPv4 at IPv6 nang hiwalay, dahil magkaibang tagapakinig at magkaibang paghahanap ang mga ito, at ang pangkalahatang entry para sa isang pamilya ay walang sinasabi tungkol sa isa.

Ang routing, pagtuklas at pagsasala ay nananatiling hiwalay

Ang pagpapanatili ng pinagmulan ng sagot ay hindi nag-iinstall ng palabas na ruta, hindi nag-a-update ng dynamic na DNS, at hindi nagpapahintulot sa isang pamilya ng address na tanggapin ang isa pa. Sa isang server na may maraming upstream link, ang rutang pabalik para sa bawat pinagmulan ay dapat sadyang pagkasunduan, kung hindi ay lumalabas ang mga sagot sa isang interface na hindi kailanman pinayagan ng filter ng kliyente. Gayundin, ang bagong address pagkatapos ng pagbabago ng prefix ay dapat makarating sa mga kliyente sa pamamagitan ng pagtuklas at ng sinusuportahang daloy ng muling pagkonekta, hindi sa pamamagitan ng lumang record.

Iwanan ang mga pagsusuri ng pagkakakilanlan ng server at ang pagpapatunay ng sertipiko nang eksaktong tulad ng naroon, dahil ang binagong address ay hindi nagbibigay-katwiran sa pagtanggap ng hindi na-verify na kapares. Kung ang sagot ay lumalabas na ngayon mula sa inaasahang pinagmulan at nabibigo pa rin ang tunnel, ituring na lutas ang problema sa pinagmulan at magpatuloy. Ang susunod na mapapansing error ay kabilang sa routing, pagsasala o pagpapatunay, at ang muling pagbabago ng tagapakinig ay hindi ito maaabot. Isulat ang pinagmulan ng sagot sa tiket sa tabi ng address na tinawagan ng kliyente, upang masuri ng susunod na tao ang parehong katotohanan sa isang utos.