Kāpēc strādājošs VPN tomēr beidzas ar noildzi atbildē
Tas, ka pieprasījums sasniedz privātu serveri, ir tikai puse apmaiņas. Tā atbildei jāatrod tuneļa klients caur paredzēto vārteju, maršrutu vai tulkojumu.
Pieprasījums pienāk, serveris to ieraksta žurnālā, un klients joprojām ziņo par noildzi. Šāda kombinācija nozīmē, ka atbilde neatrada ceļu atpakaļ, un tas ir viens no nedaudzajiem bojājumiem, ko varat apstiprināt no abiem galiem vienlaikus. Veiciet pārbaudes pēc kārtas un apstājieties, kad kāda no tām neizdodas.
Sāciet ar to, kur pieprasījums pienāca
Pirms pārbaudāt jebko citu, apstipriniet, ka pakete sasniedza pakalpojumu. Žurnāla ieraksts servera pusē, savienojumu skaitītājs vai atļauta uztveršana tālajā galā visi atbild uz to pašu jautājumu, un to trūkums sūta jūs atpakaļ pie tuneļa, nevis uz priekšu pie atbildes. Šī ir pārbaude, kas atdala pārsūtīšanas problēmu no atgriešanās ceļa problēmas.
Ja pieprasījums nekad nepienāca, apstājieties šeit. Tunelis, maršrutēšana uz privāto prefiksu vai piekļuves noteikums ir tēma, un atbildes ceļš vēl nav būtisks. Pierakstiet arī avota adresi, ko serveris redzēja. Tā ir vai nu klientam piešķirtā baseina adrese, vai tulkota adrese, un šī atšķirība nosaka, kura no vēlākajām pārbaudēm attiecas.
Atbildei vajag maršrutu uz baseinu
Attālās piekļuves klients parasti saņem adresi no baseina, un privātajam tīklam vajag maršrutu atpakaļ uz šo baseinu. Serveris, kura noklusējuma maršruts rāda uz tā paša vārteju, nodod paketi šai vārtejai, kurai nav ne jausmas, kur atrodas baseins, tāpēc atbilde tur iet bojā. Klients redz noildzi, jo nekas neatgriezās, un to nevar atšķirt no pieprasījuma, kas nekad nav izgājis.
Pārbaudiet maršrutu, ko serveris izvēlas klienta adresei, nevis to, ko tas izmanto savam apakštīklam. Šie divi meklējumi var dot dažādas atbildes, un šeit svarīgs ir otrais. Tulkojums ir alternatīvais risinājums, un tas maina to, ko serveris redz. Tas var vienkāršot atgriešanās ceļu, un tas arī noņem sākotnējo klienta adresi no servera žurnāliem, kas ietekmē jebkuru noteikumu vai atskaiti, kas balstīta uz šo lauku.
Salīdziniet uztveršanu serverī ar uztveršanu vārtejā
Salīdziniet to, kas atstāj serveri, ar to, kas pienāk vārtejā. Uztveršana servera izejošajā saskarnē un uztveršana tuneļa vārtejā atbild uz dažādām jautājuma pusēm, un starpība starp tām norāda zuduma vietu.
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 |
Pašas vārtejas ģenerēts pieprasījums ir slikts klienta testa aizstājējs, jo tas nāk no citas adreses un sastopas ar citiem noteikumiem. Tāpēc veiksmīgs ping no vārtejas un neizdevies pieprasījums no klienta var būt patiesi abi vienlaikus.
Ja ceļā ir vairāki maršrutētāji, pārbaudiet katru, kuram vajag maršrutu uz baseinu. Vietnes-uz-vietni risinājums bieži prasa, lai attālais prefikss būtu zināms vairāk nekā vienā ierīcē, un pašai vārtejai jāpārsūta starp tuneli un lokālo tīklu; strongSwan pārsūtīšanas piezīmes aptver tā sysctl un ugunsmūra pusi.
Pierakstiet baseinu, prefiksu un atbildīgo
Piezīmē ietilpst četri fakti: baseins, ko klients saņēma, privātais prefikss, kas tam bija vajadzīgs, maršrutētājs, kas atbild par atbildi, un tulkojuma noteikums, ja tāds ir. Ar tiem vēlāka vārtejas maiņa ir salīdzinājums, nevis izmeklēšana.
Pēc tam pārbaudiet vēlreiz ar parastu klientu un īsto lietotnes kontu. Lietotnes tiesību paplašināšana nevar salabot paketes atgriešanās ceļu, un konta maiņa šīs diagnostikas laikā sajaucīs nākamo salīdzinājumu. Ja risinājums balstās uz tulkojumu, dokumentējiet to tur, kur lasa servera žurnālus. Tam, kas audita pēdās ierauga nepazīstamu avota adresi, nevajadzētu no jauna atklāt kartējumu no biļetes.