Bakit nag-timeout pa rin sa tugon ang gumaganang VPN
Ang pagdating ng kahilingan sa isang pribadong server ay kalahati lamang ng palitan. Kailangang hanapin ng tugon nito ang kliyente ng tunnel sa pamamagitan ng inilaan na gateway, ruta o pagsasalin.
Dumarating ang kahilingan, nila-log ito ng server, at nag-uulat pa rin ng timeout ang kliyente. Ang kombinasyong iyon ay nangangahulugang hindi natagpuan ng tugon ang daan pabalik, at ito ay isa sa kaunting mga pagkasira na maaari mong kumpirmahin mula sa magkabilang dulo nang sabay. Gawin ang mga pagsusuri nang sunud-sunod at huminto kapag nabigo ang isa sa kanila.
Magsimula sa kung saan dumating ang kahilingan
Kumpirmahin na naabot ng packet ang serbisyo bago suriin ang anupamang iba. Ang tala sa log sa panig ng server, bilang ng koneksyon o pinahintulutang pagkuha sa malayong dulo ay sumasagot sa parehong tanong, at ang kawalan nito ay nagpapabalik sa iyo sa tunnel sa halip na sumulong sa tugon. Ito ang pagsusuring naghihiwalay ng problema sa pagpapasa mula sa problema sa daang pabalik.
Kung hindi kailanman dumating ang kahilingan, huminto dito. Ang tunnel, ang pagruruta patungo sa pribadong prefix o ang panuntunan sa pag-access ang paksa, at hindi pa nauugnay ang daan ng tugon. Itala rin ang address ng pinagmulan na nakita ng server. Ito ay alinman sa address ng pool na ibinigay sa kliyente o isang isinaling address, at ang pagkakaibang iyon ang nagtatakda kung alin sa mga susunod na pagsusuri ang naaangkop.
Kailangan ng tugon ng ruta patungo sa pool
Ang kliyente ng malayuang pag-access ay karaniwang tumatanggap ng address mula sa isang pool, at kailangan ng pribadong network ng rutang pabalik sa pool na iyon. Ang server na ang default na ruta ay tumuturo sa sarili nitong gateway ay nagbibigay ng packet sa gateway na iyon, na walang ideya kung nasaan ang pool, kaya namamatay ang tugon doon. Nakikita ng kliyente ang timeout dahil walang bumalik, at hindi iyon makikilala mula sa kahilingang hindi kailanman lumabas.
Suriin ang rutang pinipili ng server para sa address ng kliyente, hindi ang rutang ginagamit nito para sa sarili nitong subnet. Ang dalawang paghahanap na iyon ay maaaring magbigay ng magkaibang sagot, at ang pangalawa ang mahalaga dito. Ang pagsasalin ay ang alternatibong disenyo at binabago nito ang nakikita ng server. Mapapasimple nito ang isang daang pabalik, at inaalis din nito ang orihinal na address ng kliyente mula sa mga log ng server, na nakakaapekto sa anumang panuntunan o ulat na itinayo sa field na iyon.
Ihambing ang pagkuha sa server sa pagkuha sa gateway
Ihambing ang lumalabas sa server sa dumarating sa gateway. Ang pagkuha sa outbound interface ng server at pagkuha sa gateway ng tunnel ay sumasagot sa magkaibang kalahati ng tanong, at ang agwat sa pagitan ng mga ito ay nagtatakda kung saan nawala.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Ang kahilingang nilikha ng gateway mismo ay mahinang kapalit ng pagsubok mula sa kliyente, dahil nagmumula ito sa ibang address at nakakatagpo ng ibang panuntunan. Kaya nga ang matagumpay na ping mula sa gateway at ang nabigong kahilingan mula sa kliyente ay maaaring parehong totoo.
Kapag maraming router ang nasa daan, suriin ang bawat isa na nangangailangan ng ruta patungo sa pool. Ang disenyong site-to-site ay madalas na nangangailangan na ang malayong prefix ay kilala sa higit sa isang device, at ang gateway mismo ay dapat magpasa sa pagitan ng tunnel at ng LAN; ang mga tala ng strongSwan sa pagpapasa ay sumasaklaw sa panig ng sysctl at firewall niyon.
Itala ang pool, ang prefix at ang may pananagutan
Apat na katotohanan ang nabibilang sa tala: ang pool na natanggap ng kliyente, ang pribadong prefix na kailangan nito, ang router na may pananagutan sa tugon, at ang panuntunan sa pagsasalin kung mayroon. Sa mga ito, ang pagbabago ng gateway sa hinaharap ay paghahambing at hindi pagsisiyasat.
Pagkatapos ay subukan muli gamit ang ordinaryong kliyente at ang tunay na account ng application. Ang pagpapalawak ng mga pribilehiyo ng application ay hindi makakapag-ayos ng daang pabalik ng packet, at ang pagbabago ng account na ginawa sa diagnostic na ito ay magpapagulo sa susunod na paghahambing. Kung ang disenyo ay umaasa sa pagsasalin, idokumento ito kung saan binabasa ang mga log ng server. Ang taong nakakita ng hindi pamilyar na address ng pinagmulan sa audit trail ay hindi dapat kailangang tuklasin muli ang mapping mula sa isang ticket.