VPN konektita sed sen interreto? Trairu la kvar tavolojn

La kliento diras konektita, la retumilo turniĝas, kaj ĉiu retejo finiĝas per tempolimo. Tiu kombino estas ordinara kaj ne estas kontraŭdiro: konektita signifas, ke la tunelo intertraktis, kaj nenion pli. Nomresolvo, enkursigo kaj la propra eliro de la servilo malsukcesas ĉiu laŭ sia maniero, kaj ĉiu havas malsaman posedanton. Trairu la tavolojn laŭ ordo kaj haltu ĉe la unua, kiu malsukcesas.

Komencu per la reto, de kiu vi venis

Mallevu la tunelon per la propra malkonekta regilo de la kliento, poste provu du sendependajn HTTPS-retejojn se politiko permesas. Lasu senteman laboron fermita dum tiu testo. Se ankaŭ ordinara aliro malsukcesas, VPN ne estas la unua suspektato.

Rigardu la Wi-Fi-ligon, la enkursigilon kaj ĉiun portalpaĝon, kiu postulas ensaluton, antaŭ ol tuŝi la tunelon. Kill switch povas bloki trafikon dum vi estas malkonektita laŭ la dezajno, do sekvu ĝian dokumentitan testproceduron anstataŭ konkludi, ke la reto estas morta. Alia fidinda reto estas utila komparo, kaj nova VPN-eliro ne kompletigos eksvalidiĝintan hotelan ensaluton. Se la malferma reto funkcias kaj la tunelo ne, la reto estas senkulpigita kaj la sekva tavolo estas via.

Decidu, ĉu la fiasko estas nomresolvo

Skribu la erartekston, ĉar resolva fiasko, tempolimo kaj atestila averto ĉiu montras aliloken. La ŝablono por kapti frue estas gastnomo, kiun vi neniam vizitis, malsukcesanta dum aplikaĵo kun malferma sesio daŭras. Tiu ŝablono temas pri novaj serĉoj, ne pri tio, ĉu la tunelo portas pakaĵojn. Unu serĉo montras, kion la solvilo redonas, kaj ĝi daŭras sekundon. Provu ankaŭ duan nomon, por ke unu kaŝmemorita respondo aŭ unu rompita rikordo ne decidos la diagnozon.

nslookup example.com

Arbitra IP en HTTPS-adresa stango ne estas DNS-testo, ĉar la atestilo kaj la virtuala gastiganto kutime dependas de la nomo. Internaj nomoj eble bezonas la solvilon de la organizo anstataŭ publikan anstataŭaĵon, kaj retumilo kun propra sekura solvilo povas respondi alie ol la serĉo de la operaciumo. Kie la du malkonsentas, la solvilo de la retumilo estas tiu, kiun la uzanto spertas, kaj tiu distingo apartenas al la bileto.

Plena tunelo aŭ nur kompaniaj subretoj

Iuj profiloj ekzistas nur por atingi manplenon da kompaniaj subretoj; aliaj estas konstruitaj por porti ĉion kaj bezonas funkcian eliron malantaŭ si. Legu la dokumentitan celon antaŭ ol supozi, ke la indikilo kovras ĉiun aplikaĵon kaj ĉiun adresfamilion. Profilo de privata reto povas funkcii ĝuste kiel planite, dum la retumilo, kiu neniam devis uzi ĝin, ankoraŭ malsukcesas. Legu la enkursigan tabelon sen ŝanĝi ĝin, kaj inkluzivu IPv6, ĉar funkcianta IPv4-vojo diras nenion pri la alia familio.

Pli specifa vojo povas venki dum la defaŭlta vojo ankoraŭ ekzistas, kaj tial la tabelo devas esti legata, ne supozata. Konkuraj virtualaj adaptiloj ankaŭ povas posedi trafikon, kiun vi atendis aliloke, precipe post kiam dua VPN-kliento estis instalita kaj forgesita. Ne forigu la defaŭltan vojon kiel eksperimenton; tio transformas diagnozon en duan interrompon.

Unu malsukcesanta retejo inter funkciantaj estas problemo de tiu retejo, kaj ĝi ankaŭ pruvas, ke la tunelo portas trafikon. Haltoj, kiuj aperas nur ĉe grandaj transigoj, montras al pakaĵgrandeco anstataŭ al atingeblo.

Kiam la servilo neniam plusendas ion

Se ĉiu celo malsukcesas sur du aparatoj kaj du alirretoj, la tunelo estas supre kaj la eliro ne plusendas. Tiu parigo apartigas servilflankan fiaskon de unu aparato malĝuste agordita en unu loko. Sendu al la administranto la demandojn pri plusendo, NAT kaj revenvojo, ne ekrankopion de la indikilo.

Tiuj tri kovras plej multajn servilflankajn kaŭzojn, kaj la administranto devas respondi ilin. La paĝo pri solvado de OpenVPN-konektaj problemoj trairas la samajn demandojn de la servila flanko, do transdonu ĝin kun la bileto. Ekrankopio de verda indikilo respondas neniun el ili.

Traserĉu la klientan protokolon post ensaluto por fiaskoj aplikante vojojn, DNS-agordojn aŭ la virtualan adaptilon. Eraroj en tiu stadio montras al la aparato anstataŭ al la servilo. Eraro, kiu neniam aperas en la protokolo, estas same informa, ĉar ĝi movas la suspekton al la malproksima flanko.

Kontrolu unu tavolon samtempe

Post kiam vi ŝanĝis ion, rekonektiĝu kaj ripetu ĝuste la aplikaĵon, kiu malsukcesis. Unu paĝo, kiu ŝarĝiĝas, pruvas malpli ol ripetebla vojo al la rimedoj, por kiuj la profilo estis konstruita. Du komandoj apartigas resolvon de atingeblo, kaj la dua estas gastnom-specifa. Rulu la curl-linion ie ajn, poste rulu la enkursigan komandon, kiu kongruas kun la gastiganto antaŭ vi.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Se la numera peto funkcias kaj la nomo ne, restu ĉe DNS. Se neniu funkcias, komparu la enkursigan tabelon kun la atendata defaŭlto de la tunelo, kaj kontrolu la familion, kiun vi efektive testas. Se la vojo estas ĝusta kaj la peto ankoraŭ mortas ĉe la eliro, la restanta demando apartenas al la administranto, kaj la pruvoj, kiujn vi konservis, estas la bileto.