Zakaj delujoč VPN vseeno poteče na odgovoru
To, da zahteva doseže zasebni strežnik, je le polovica izmenjave. Njen odgovor mora najti odjemalca tunela skozi predvidena prehod, pot ali prevod.
Zahteva prispe, strežnik jo zabeleži, odjemalec pa še vedno poroča o poteku časa. Ta kombinacija pomeni, da odgovor ni našel poti nazaj, in to je ena redkih okvar, ki jo lahko potrdite z obeh koncev hkrati. Izvedite preverjanja po vrsti in ustavite se, ko katero od njih ne uspe.
Začnite s tem, kam je zahteva prispela
Preden pregledate karkoli drugega, potrdite, da je paket dosegel storitev. Zapis v dnevniku na strani strežnika, števec povezav ali dovoljeno zajemanje na oddaljenem koncu vsi odgovarjajo na isto vprašanje, njihova odsotnost pa vas pošlje nazaj k tunelu, ne naprej k odgovoru. To je preverjanje, ki ločuje težavo s posredovanjem od težave s povratno potjo.
Če zahteva nikoli ni prispela, se ustavite tukaj. Tema je tunel, usmerjanje do zasebne predpone ali pravilo dostopa, pot odgovora pa še ni pomembna. Zapišite tudi naslov vira, ki ga je videl strežnik. To je bodisi naslov iz bazena, ki ga je dobil odjemalec, bodisi preveden naslov, in ta razlika določa, katero od poznejših preverjanj velja.
Odgovor potrebuje pot do bazena
Odjemalec oddaljenega dostopa običajno prejme naslov iz bazena, zasebno omrežje pa potrebuje pot nazaj v ta bazen. Strežnik, katerega privzeta pot kaže na njegov lastni prehod, paket preda temu prehodu, ki nima pojma, kje je bazen, zato odgovor tam umre. Odjemalec vidi potek časa, ker se ni vrnilo nič, tega pa ni mogoče ločiti od zahteve, ki nikoli ni odšla.
Preverite pot, ki jo strežnik izbere za naslov odjemalca, ne poti, ki jo uporablja za svojo podmrežo. Ta dva iskanja lahko dasta različna odgovora, in tu šteje drugi. Prevod je alternativna zasnova in spreminja, kaj strežnik vidi. Lahko poenostavi povratno pot in tudi odstrani prvotni naslov odjemalca iz dnevnikov strežnika, kar vpliva na vsako pravilo ali poročilo, zgrajeno na tem polju.
Primerjajte zajemanje na strežniku z zajemanjem na prehodu
Primerjajte, kaj zapusti strežnik, s tem, kaj prispe na prehod. Zajemanje na izhodnem vmesniku strežnika in zajemanje na prehodu tunela odgovarjata na različni polovici vprašanja, vrzel med njima pa pokaže mesto izgube.
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 |
Zahteva, ki jo ustvari prehod sam, je slaba zamenjava za preizkus z odjemalca, ker izvira z drugega naslova in naleti na druga pravila. Zato sta lahko uspešen ping s prehoda in neuspešna zahteva z odjemalca resnična hkrati.
Ko je na poti več usmerjevalnikov, preverite vsakega, ki potrebuje pot do bazena. Zasnova od lokacije do lokacije pogosto zahteva, da je oddaljena predpona znana na več kot eni napravi, prehod sam pa mora posredovati med tunelom in lokalnim omrežjem; opombe strongSwan o posredovanju pokrivajo stran sysctl in požarnega zidu.
Zapišite bazen, predpono in odgovornega
V opombo spadajo štiri dejstva: bazen, ki ga je prejel odjemalec, zasebna predpona, ki jo je potreboval, usmerjevalnik, odgovoren za odgovor, in pravilo prevoda, če obstaja. Z njimi je poznejša sprememba prehoda primerjava in ne preiskava.
Nato znova preizkusite z običajnim odjemalcem in resničnim računom aplikacije. Razširitev pravic aplikacije ne more popraviti povratne poti paketa, sprememba računa med to diagnostiko pa bo zmedla naslednjo primerjavo. Če se zasnova opira na prevod, ga dokumentirajte tam, kjer berejo dnevnike strežnika. Kdor v revizijski sledi vidi neznan naslov vira, ne bi smel znova odkrivati preslikave iz zahtevka.