Tahimik ang port ng VPN? Listener, bind address, o firewall ng host

Walang sinasagot ang VPN sa port nito, at ang dalawang posibleng dahilan ay nangangailangan ng magkasalungat na pag-aayos: alinman walang prosesong nagbukas ng socket, o may socket at may isang bagay sa pagitan ng mga makina na humaharang sa mga packet. Isang utos lang ang nagtatakda sa unang kalahati ng tanong na iyon, kaya nauuna ito bago hawakan ang anumang tuntunin ng firewall. Ang pagkakasunod-sunod sa ibaba ay nag-aalis ng isang paliwanag bawat hakbang sa halip na magdagdag ng isa pang haka. Ang paghula sa pagitan ng dalawa ang gumagawa ng sampung minutong diagnosis na maging buong gabi.

Ipagpalagay na makakapasok ka sa server at ang kliyente ay tunay na profile at hindi scanner. Mahalaga ang dalawang palagay, dahil hindi kayang sagutin ng pangkalahatang probe ang tanong na partikular sa protocol.

Umiiral ba ang socket

Simulan sa sinasabi ng serbisyo tungkol sa sarili nito: kung umakyat ito at, mas kapaki-pakinabang, ano ang una nitong error sa pagsisimula. Ang pagkabigo sa pag-parse, nawawalang key, o error sa pag-bind ay humahadlang sa listener na umiral, at ang proseso ay maaaring lumabas nang tahimik kaya ang linya ng estado ay binabasa nang malabo. Ang unit na nag-uulat na aktibo ay hindi sapat na patunay sa sarili nito, dahil ang pangunahing proseso ay maaaring buhay habang ang bahaging dapat mag-bind ng port ay sumuko na.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Ang listahan ng socket ang katotohanang pinagbabatayan ng natitirang diagnosis. Basahin ang kolum ng lokal na address at hindi lamang ang port, dahil sa kolum na iyon lumilitaw ang mga bind sa loopback at mga bind sa maling interface. Ang listener na umiiral sa 127.0.0.1 ay gumagana nang perpekto at hindi pa rin nakikita ng iyong laptop.

Sa aling address at pamilya sumasagot ang socket

Dalawang pagkakamali ang magkapareho ang hitsura mula sa kliyente at nagpapaliwanag sa karamihan ng ulat na "hindi maabot". Ang server na nakatali sa loopback address ay hindi kailanman tumatanggap ng trapiko mula sa ibang makina, at ang server na nakatali lamang sa isang IPv4 address ay hindi kailanman sumasagot sa kliyenteng tumatawag sa IPv6 address ng parehong host. Ihambing ang address sa talahanayan ng socket sa address na aktuwal na tinatawag ng kliyente, titik sa titik, bago magpalagay ng anuman tungkol sa patakaran.

Ang paglimita ng listahan sa isang port ay nagpapanatili nitong madaling basahin kapag maraming serbisyo ang pinapatakbo ng host. Kinukuha ng sport filter ang port kasama ng transport na sinusubukan mo:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Binabago ng kolum ng protocol ang buong sagot

Ang talahanayan ng socket ay naka-index sa protocol gayundin sa port, at dalawang independiyenteng entry ang mga ito. Ang serbisyong sumasagot sa TCP sa 1194 ay walang sinasabi tungkol sa kung may nakikinig sa UDP 1194, at isa lamang sa dalawa ang gagamitin ng kliyente. Tiyakin kung aling transport ang pinipili ng configuration ng server at alin ang ipinapadala ng profile ng kliyente, pagkatapos hanapin ang eksaktong linyang iyon.

May ikalawang tiklop ang UDP: ang hindi awtentikadong probe ay hindi error na kailangang sagutin ng serbisyo. Ang scan na nag-uulat na tahimik ang port ay sumukat sa pagpipigil ng serbisyo, hindi sa availability nito, kaya subukan gamit ang tunay na kliyente at profile.

Isang pagtatangka, tatlong lugar na titingnan

Mula sa awtorisadong kliyente, gumawa ng eksaktong isang pagtatangka at isulat ang oras hanggang sa segundo. Pagkatapos basahin ang tatlong pinagmulan para sa yugtong iyon: ang network rule o console ng provider, ang mga counter o log ng firewall ng host, at ang sariling log ng serbisyo. Ang paggawa nito nang isang beses ang nagpapagaya sa tatlong salaysay na maihahambing, at mas mura ito kaysa sa pag-ulit ng pagtatangkang walang nakapagtala ng timestamp.

Ang dalawang kinalabasan ay tumuturo sa magkasalungat na direksyon. Kung walang packet na umabot sa host, itinatapon ito ng ruta at walang kaugnayan ang listener. Kung umabot ang packet sa socket at tinanggihan ito ng serbisyo, maayos ang ruta at nasa protocol, kriptograpiya, o kredensyal ang sagot. Ang pagbubukas ng port para sa serbisyong tumanggap na ng koneksyon ay nagpapahirap sa susunod na diagnosis, hindi nagpapagaan.

Pangalanan ang yugto bago mo baguhin ang isang tuntunin

Ang negosasyong nagsisimula at ang awtentikasyong nabibigo ay isang pagkabigo, at ang tunnel na nabubuo habang nagsisikip ang pagpapasa ay ganap na iba. Ang pagpangalan muna sa yugto ay nagpapanatili ng pag-aayos na makitid: ang problema sa kredensyal ay hindi naaayos ng tuntunin ng firewall, at ang problema sa landas ng data ay hindi naaayos ng restart.

Gamitin ang pinakamakitid na diagnosis na sumasagot sa tanong. Ang pansamantalang pagmamasid ng packet sa isang port, sa ilalim ng kontrol ng administrator, ay makatwirang instrumento; ang pag-disable sa buong firewall ay hindi, dahil nagiging imposibleng iugnay ang resulta. Sinasaklaw ng dokumentasyon ng ss ang mga filter na ginamit sa itaas, at mas murang unang hakbang ito kaysa sa anumang capture. Itala kung alin sa dalawang sangay ang napatunayan mo, at ang susunod na pagkakataon ay magsisimula sa kilalang sagot.