Kumokonekta ang OpenVPN ngunit walang dumadaloy: hanapin ang layer kung saan bumabagsak ang packet

OpenVPN ay nagsasabing konektado at walang trapikong gumagalaw, isang pangungusap na sumasaklaw sa hindi bababa sa limang walang kaugnayang sira. Ang pag-edit ng mga tuntunin ng firewall bago mo malaman kung aling layer ang nabigo ay nagpaparami ng hindi alam at nag-iiwan ng gulo sa susunod na inhinyero. Magtrabaho sa halip mula sa proseso palabas, dahil bawat hakbang sa ibaba ay nililinis ang isang yugto o pinapaliit kung saan namamatay ang packet. Mahalaga ang pagkakasunod-sunod dito: ang pagkuha na ginawa bago mo malaman kung aling address ang nakatali ay magpapatunay ng isang bagay, hindi lang ang kailangan mo.

Ang socket ay nakatali o hindi

Isang serbisyong nag-uulat ng aktibo ay maaari pa ring nakatali sa isang address o transport na hindi mo kailanman sinadya. Tanungin ang socket mismo: ss -lunp ay naglilista ng mga listener ng UDP at ss -ltnp ay naglilista ng TCP, at ang column na sulit basahin ay ang lokal na address, hindi ang estado.

Ang walang laman na sagot ay karaniwang nangangahulugan ng isa sa tatlo: umalis ang proseso pagkatapos magsimula, nag-load ito ng ibang configuration file, o nakikinig ito sa ibang address kaysa sa tinatawagan.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Ang direktiba na local ay nagtatakda ng listener sa isang address, kaya ang client na patungo sa ibang lugar sa parehong host ay tinatanggihan habang ang serbisyo mula sa labas ay mukhang malusog pa rin. Ang pangalan ng instance ay maaari ring tumuro sa file na hindi mo kailanman na-edit, na nangyayari sa mga host na nagpapatakbo ng dalawang profile nang magkatabi.

Hulihin ang panlabas na packet, hindi ang tunnel

I-filter sa pisikal na interface at tunay na port, na may sarili mong interface na pinalitan: tcpdump -ni eth0 udp port 1194. Ang mga papalabas na packet na walang bumabalik ay tumuturo sa nasa itaas: pag-filter ng provider, isang NAT device, o isang malayong address na hindi ang iniisip mo. Ang katahimikan sa magkabilang direksyon ay tumuturo sa routing ng client o lokal na firewall. Ang mga sagot na dumarating nang walang pag-unlad ng tunnel ay tumuturo sa control channel, ibig sabihin ay hindi tugma ang key o cipher, hindi sa pag-filter.

Hulihin ang magkabilang direksyon at panatilihing maikli ang file. Inililibing ng mahabang pagkuha ang kawili-wiling tatlong segundo, at ang sagot ay halos palaging nasa unang palitan.

Mga counter muna, trace lamang kapag nagsisinungaling sila

Magsimula sa mga counter, dahil wala silang gastos. Alinman sa nft list ruleset o iptables -L -n -v ang sumasagot sa tanging tanong na mahalaga dito: tumugma ba ang tuntunin? Ang pagkakasunod-sunod ang nagpapasya ng resulta, dahil ang unang tugma ang nananalo, kaya ang malawak na DROP bago ang mas huling ACCEPT ay iniiwan ang ACCEPT na iyon na patay at kaya ang pagdaragdag ng tuntunin ay napakabihirang mag-ayos ng anuman.

Ang pagmamay-ari ay nagpapadapa rin ng mga tao. Ini-uugnay ng kernel ang mga packet na nabuo nang lokal sa prosesong nagbukas ng socket, at ang OpenVPN ay karaniwang tumatakbo bilang root, kaya ang tuntuning nakatali sa ordinaryong user ID ay hindi kailanman nakikita ang trapiko ng tunnel mismo. Suriin ang UID ng may-ari bago magpasya na mali ang tuntunin.

Lamang kapag nananatiling malabo ang mga counter ay sulit ang log sa ingay, at kahit noon ay para lamang sa makitid na bahagi: isang tuntunin ng iptables na naglilimita ng bilis at naglalagay ng prefix sa mga linya nito, o isang tuntunin ng nftables na may meta nftrace set 1 habang tumatakbo ang nft monitor trace. Pinapangalanan ng trace ang chain at tuntuning tumanggap o nagtapon ng packet. Pagkatapos ay alisin ang pareho at ilayo ang pag-log ng payload.

Suriin din ang transport. Ang serbisyo ng firewall na limitado sa TCP ay walang sinasabi tungkol sa listener ng UDP sa numerong iyon, kaya ang tuntuning tamang binasa ay maaari pa ring magtapon ng bawat packet.

Routing at ang daan pabalik

Ang packet na tinanggap ngunit nawawala pa rin ay kailangang suriin ang landas ng patutunguhan. Ang ip route get ay nag-uulat ng rutang pinili para sa isang address, at ang pag-filter ng reverse path ay maaaring magtapon ng sagot na dumarating sa interface na hinding-hindi pipiliin ng pangunahing talahanayan. Ang sintomas ay mukhang eksaktong pagtapon ng firewall, kaya ang pagsusuring ito ay nauuna sa isa pang tuntunin ng NAT.

Sa gateway, suriin ang pagpapasa at ang forward chain sa halip na ang input chain. Pagkatapos ay tiyakin na alam ng malayong panig kung paano maabot ang source address, dahil ang gumaganang palabas na landas na walang bumabalik ay katahimikan sa parehong kaso.

Ano ang dapat sabihin ng tala

Para sa bawat pagbabago, itala ang yugtong sinubukan, ang ebidensyang binasa at ang halaga ng counter sa magkabilang panig nito. Ang talang iyon ang gumagawa sa "gumagana ito ngayon" na mabubuhay sa susunod na pagsusuri.

Dalawang shortcut ang nagpapanatiling tapat ng tala. Ang packet na hindi kailanman umalis sa host ay hindi maaaring itinapon ng tuntunin sa ibang lugar, gaano man kahikayat ang hitsura ng configuration ng malayong panig. Ang packet na lumabas at bumalik ay naglilipat ng tanong sa itaas ng network layer, kung saan ang mga counter ng firewall ay wala nang masasabi sa iyo.