MULTI: maling source address mula sa kliyente: kaninong address iyon?
Hindi tugma ang panloob na pinagmulan sa kliyenteng naghatid nito. Itugma ito sa isang pagtatalaga ng tunnel, isang LAN sa likod ng kliyente, o isang dobleng pagkakakilanlan.
Nagpi-print ang log ng server ng MULTI: bad source address from client, itinatapon ang packet, at nananatiling konektado ang session. Ang kombinasyong iyon ay nakakalito sa mga taong nagbabasa ng mensahe bilang kabiguan sa pagpapatotoo. Hindi ito ganoon: nagpatotoo ang kliyente, at ang packet na dumating ay may dalang panloob na source address na hindi maiugnay ng server sa instance ng kliyenteng iyon. Nangyayari ang pagsusuri bago ang paghahatid, kaya mukhang malusog ang tunnel habang walang kapaki-pakinabang na dumadaan dito.
Ano ang inihahambing ng server bago ang paghahatid
Para sa bawat packet na dumarating mula sa isang kliyente, tinitingnan ng server sa user space ang source address sa loob ng tunnel at tinatanong ang panloob na kalagayan ng routing kung kaninong kliyente ang address na iyon. Kung ibang instance ang may-ari, o wala talagang may-ari, itinatapon ang packet at inilalabas ang babala.
Ang karaniwang paghahatid sa pamamagitan ng interface ng tunnel ay hindi kailanman nangyayari.
Ipinapaliwanag ng pagkakasunod-sunod na iyon ang isang detalyeng nakakalito: hindi gumagalaw ang mga counter ng firewall ng host, dahil hindi kailanman umabot ang packet sa firewall. Walang binabago ang pagsasaayos ng reverse-path filtering sa host dito, dahil nangyari ang pagtanggi sa sariling tseke ng pagkakaugnay ng daemon. Basahin ang mensahe bilang pahayag tungkol sa pagmamay-ari, pagkatapos ay alamin kung alin sa tatlong sitwasyon ang gumawa nito.
Tatlong pinagmulan ng panloob na address na hindi tugma
Maaaring nagpapadala ang kliyente mula sa address na hindi naitalaga sa kanya, mula sa network na walang nagpahayag na kanya, o mula sa kopya ng pagkakakilanlang may may-ari na. Pareho ang log line na ginagawa ng tatlo. Naiiba sila sa kung ano ang kailangan mong baguhin. Magsimula sa address at sa kasalukuyang listahan ng pagtatalaga, at hayaang piliin ng dalawang katotohanang iyon ang kaso.
Kailangan ng dalawang katotohanan para maiba sila: ang tinanggihang address sa log, at ang mga pagtatalagang itinuturing ng server na kasalukuyan. Ang pangalawa ay makukuha mula sa view ng status o pamamahala ng tumatakbong instance, at iyon lamang ang awtoridad na sulit konsultahin, dahil ang configuration file ay nagtatala ng intensyon at hindi ang kasalukuyang kalagayan.
Itala ang dalawa bago baguhin ang anuman, pagkatapos ay uriin. Ang screenshot na kinuha pagkatapos ay hindi talaan ng kalagayang gumawa ng babala. Itago rin ang timestamp, dahil gumagalaw ang mga pagtatalaga sa pagitan ng mga session.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
Ang LAN sa likod ng kliyente at iroute
Kapag ang isang site client ay nagru-ruta ng sarili nitong pribadong network, dapat ipahayag na pag-aari ng kliyente ang network na iyon. Ginagawa iyon ng file na partikular sa kliyente na may entry na iroute, at pinapangalanan ng entry ang prefix na pinapayagang dalhin ng kliyente.
Ang rutang kernel na nagtuturo ng parehong prefix sa tunnel ay hiwalay na pangangailangan, at walang binabago ang pagdaragdag nito sa panloob na pagmamay-ari ng daemon.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Tiyakin na tugma ang epektibong pagkakakilanlan sa pangalan ng file, dahil ang hindi pagtugma ay nangangahulugang hindi kailanman naglo-load ang file at ang sintomas ay katulad ng nawawalang entry. Huwag magdagdag ng malawak na iroute para patahimikin ang babala, dahil ginagawa nitong awtorisado ang hindi inaasahang pinagmulan nang hindi sinasagot kung bakit ito ipinadala ng kliyente. Idinodokumento ng manwal ng OpenVPN 2.6 ang iroute, duplicate-cn at pagmamapa ng pagkakakilanlan bilang hiwalay na kontrol.
Parehong pagkakakilanlan sa dalawang makina
Ang profile na kinopya sa pangalawang laptop ay may dalang parehong certificate at parehong common name. Depende sa mga setting ng server, maaaring palitan ng mas bagong koneksyon ang mas luma, at ang instance na may pagmamay-ari ang nananalo sa tseke ng pagkakaugnay.
Ginagawa nitong mukhang pabagu-bago ang sira at lumilitaw lamang kapag gising ang dalawang device.
Ang pagpayag sa dobleng common name ay nagpapahintulot sa dalawa na kumonekta, ngunit hindi nagbibigay sa kanila ng independiyenteng static na address o independiyenteng pagmamay-ari. Kung kailangang magkasama ang dalawang device, irehistro sila nang hiwalay upang magkaroon ang bawat isa ng sariling pagkakakilanlan at sariling pagtatalaga. Ang pagturing sa setting ng duplicate bilang pagkukumpuni ng babalang ito ay nag-iiwan ng misteryo at nagdaragdag ng isa pa.
Patunayan na nagbago ang pagkakaugnay
Ilapat ang pagwawasto sa pamamagitan ng may-ari ng configuration, pagkatapos ay ikonekta muli ang apektadong kliyente upang ma-load ang bagong patakaran.
Ulitin ang parehong daloy at tiyakin ang tatlong bagay: ang panloob na pinagmulan ng packet, ang instance ng kliyenteng iniuugnay ng server dito, at ang pag-uugali ng destinasyon pagkatapos.
Kung tumigil ang babala ngunit nabibigo pa rin ang application, lumipat ang problema sa halip na nawala. Ang pagpapasa, mga patakaran ng firewall at ang daan pabalik ay hiwalay na yugto, at ang pagpasa sa tseke ng pagkakaugnay ay nangangahulugan lamang na pinayagang umalis ng tunnel ang packet.