Babala ng AF_INET ng OpenVPN: hindi nakakapinsalang fallback o bigong socket?
Ihiwalay ang AF_INET fallback sa susunod na pagkabigo sa paggawa ng socket: basahin ang eksaktong linya, pagkatapos suriin ang tagapakinig at ang susunod na error.
Dalawang linya ng log ng OpenVPN ang nagsisimula sa parehong mga salita, at isa lamang sa kanila ang nag-uulat ng problema. Could not determine IPv4/IPv6 protocol. Using AF_INET ay isang abiso ng fallback: iniwan ng profile na bukas ang pamilya ng address, kaya pumili ang daemon ng isa at nagpatuloy. Ang sangay ng pagkabigo ay nag-uulat na walang socket na nagawa at humihingi ng restart. Ang lahat pagkatapos ng karaniwang prefix ang naghihiwalay sa kanila, kaya basahin ang higit pa rito bago baguhin ang anuman.
Ano ang iniuulat ng abiso ng fallback
Tinatanggap ng OpenVPN ang tahasang pamilya sa pamamagitan ng proto udp4 o proto udp6, at tinatanggap ang proto udp kapag ang pamilya ay dapat makuha sa pag-start. Sa pangalawang kaso sinusuri ng daemon ang lokal na impormasyon ng pagbind at pumipili.
Kapag gumana ang pagkuha na iyon, sinasabi ng babala kung saang direksyon ito napunta at nagpapatuloy ang proseso sa paggawa ng socket. Ang isang server na may proto udp sa host na may dobleng stack ay madalas na napupunta sa IPv4 sa ganitong paraan. Wala sa landas na iyon ang error, at wala rin itong nagpapahiwatig ng pag-atake, nawawalang web server o tinanggihang account. Ang linya ay kapaki-pakinabang lamang dahil ang mga susunod na pagsusuri ay dapat ihambing sa pamilyang pinangalanan nito.
Ituring itong sagot sa isang tanong, hindi diagnosis. Sinasabi nito kung aling pamilya ang pinili ng prosesong ito, at wala tungkol sa kung bakit hindi makakonekta ang isang kliyente.
Ano ang hitsura ng sangay ng pagkabigo
Sa ibang pagkakataon sa parehong code ng socket may isang sangay kung saan wala talagang socket. Nilo-log nito ang mas maikling mensahe ng pamilya ng address at humihingi ng restart, dahil wala nang natitira upang ipagpatuloy. Ang mga panimulang salita ay tumutugma sa fallback; ang resulta ay hindi.
Ihiwalay sila sa kung ano ang kasunod. Kung patuloy na tumatakbo ang daemon at iniuulat ang tagapakinig nito, ang linya ay impormasyon. Kung ito ay lalabas o mag-restart sa isang loop, ang usapan ay tungkol na sa pagbind.
Ang natuklasan sa grep ay hindi rin pagkakakilanlan ng sangay. Lumilitaw ang parirala sa mga pinaikot na buod, sa mga nakatuping linya at sa mga siping log na ipinapaskil ng mga tao mula sa ikalawang kamay, kaya basahin ang mga kalapit na linya at ang pagkakasunod-sunod ng mga timestamp kaysa sa nag-iisang tugma.
Suriin ang tagapakinig sa halip na ang babala
Ang tumatakbong server ay direktang sumasagot sa tanong ng pamilya, nang walang hinuha mula sa teksto ng log.
ss -lunp | grep openvpn
ss -ltnp | grep openvpnItugma ang pamilya, address at port sa profile. Ang linyang 0.0.0.0:1194 ay IPv4 lamang, samantalang ang linyang [::]:1194 sa host na may dobleng stack ay maaaring tumanggap ng parehong pamilya depende sa setting na bindv6only. Kung sinasabi ng profile na udp at IPv4 ang socket, ang mga kliyenteng ang resolver ay nagbabalik lamang ng AAAA record ay mabibigo bago pa man mapag-usapan ang tunnel.
Pagkatapos ay subukan mula sa isang kliyenteng katulad ng iyong mga gumagamit: parehong landas ng resolver, parehong uri ng network. Ang lokal na koneksyon mula sa server ay napakaliit ng pinapatunayan tungkol sa trapikong dumadaan sa isang NAT device o sa firewall rule na isinulat para sa kabilang pamilya.
Kailan tama na pilitin ang isang pamilya
Ang pag-pin ng proto udp4 ay angkop sa deployment na IPv4 lamang: isang DNS name na A lamang, mga firewall rule para sa isang v4 address, mga kliyente sa likod ng mga operator na nagbibigay lamang ng v4 address. Inaalis nito ang kalabuan at ginagawang mahulaan ang susunod na set ng log lines.
Ang parehong argumento ay gumagana nang kabaligtaran para sa isang kapaligirang IPv6 muna, at ang udp6 sa harap ng client base na A lamang ay isang pagkagambalang ikaw mismo ang nagdulot. Ang pagpilit ng isang pamilya para lamang patahimikin ang isang hindi nakakapinsalang babala ay ang klasikong bersyon ng pagkakamaling ito, dahil binago mo kung sino ang makakakonekta kapalit ng isang mas tahimik na log.
Pumili batay sa mga endpoint at sa mga kliyenteng dapat makarating doon. Ang manwal ng OpenVPN 2.6 ay nagdodokumento ng mga anyo ng transport, at ang mensahe ay output ng pagpiling iyon, hindi input.
Panatilihing makitid ang tala
Isulat ang eksaktong linya kasama ang timestamp nito, ang epektibong setting ng transport mula sa tumatakbong profile, ang socket ayon sa iniuulat ng kernel, at ang susunod na yugto na nabigo. Ang apat na bagay na iyon ay nilulutas ang halos lahat ng tanong na itinatampok ng mensahe, at wala sa kanila ang nangangailangan ng hula tungkol sa walang kaugnayang serbisyo. Nakakaligtas din sila sa isang paghahatid, na hindi ginagawa ng screenshot ng grep.
Ang mga mungkahi ng package na kasama ng babalang ito ay walang kaugnayan hanggang sa may error na magpangalan ng nawawalang executable.
Kung talagang nawawala ang ifconfig, sinasabi ito ng daemon sa pangalan kapag tinawag ito ng script, at iyon ay karapat-dapat sa sariling pagsisiyasat. Ang linyang AF_INET at ang nawawalang utility ay magkaibang pagkabigo, at ang pag-install ng mga bagay upang makita kung nagbabago ang babala ay ang paraan kung paano nagiging magulo ang isang malinis na host.