VPN blokita en reto nur por la retejo? Laboru la tavolojn

Retumilo funkcias, tunelo mortas. Legu la tempajn fazojn de curl, testu la prokurilon, kontrolu ĉu 443 vere permesiĝas, poste kaptu kion lasis la maŝino.

Kampusa aŭ hotela reto, kie la retumilo funkcias kaj ĉiu tunelo mortas, ne estas unu problemo, sed kvar stakitaj. La vojo eble permesas nur TCP 443, eble postulas aŭtentigitan prokurilon, eble inspektas la manpremon, kaj eble simple malpermesas malproksiman aliron per politiko. Prilabori ilin laŭ ordo malhelpas vin aĉeti novan klienton por ripari retan regulon. La manlibro sube daŭras ĉirkaŭ dek minutojn kaj finiĝas per skriba respondo pri tio, kiu tavolo rifuzis vin.

Pruvu, kiu tavolo rifuzas la konekton

Ne komencu per la VPN-kliento. Komencu per ordinara HTTPS-peto al la sama gastiganto kaj legu la tempajn fazojn, ĉar la fazo, kiu malsukcesas, diras al vi, kiu aparato respondecas:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Neniu respondo kaj neniu connect-tempo signifas, ke TCP neniam kompletiĝis, do fajromuro, prokurila postulo aŭ malĝusta celo estas en ludo. connect-tempo sen tls-tempo signifas, ke io en la mezo akceptis la konekton kaj poste haltigis la manpremon, kaj tiel aspektas inspektanta prokurilo el la klienta flanko.

Nun inspektu la atestilon, kiun vi fakte ricevas. Ĝi estas la plej rapida maniero ekscii, ĉu vi parolas kun la servilo aŭ kun meza skatolo, kiu resubskribis la seancon:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Legu la eldonistan linion. Via propra CA signifas, ke vi atingis la servon; entreprena aŭ aparata eldonisto signifas, ke filtrilo finis la konekton kaj decidas, kio sekvas. Registru ambaŭ eligojn kun tempstampo, ĉar la sama test antaŭ unu horo en la gastreta reto povas doni alian respondon.

Prokuril-konscia kliento ŝanĝas la unuan paketon, ne la politikon

Se la reto postulas CONNECT tra aŭtentigita prokurilo, la VPN-kliento devas scii pri tio, alie ĝi provos malfermi konekton al adreso, kiun ĝi ne povas enkursigi. Testu la prokurilon aparte de la kliento, por ke malsukceso havu unu klarigon:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

La unua komando pruvas, ke la prokurilo portos la celon. La dua petas, ke la kliento uzu TCP sur 443, la sola transporto, kiun plej multaj nur-retaj vojoj entute plusendas. Se la unua komando sukcesas kaj la dua ankoraŭ malsukcesas, la prokurilo ne estas la baro.

Iuj klientoj legas la prokurilon de la operaciumo anstataŭ anstataŭigo, kaj iuj legas neniun. Kontrolu la dokumentaron de la aplikaĵo mem antaŭ ol supozi, ke sistema agordo validas. Kliento, kiu solvas la finpunkton per solvilo, kiun la prokurilo ne servas, ankaŭ malsukcesos ĉi tie, kaj tial DNS-ŝanĝo povas aspekti kiel riparo, kiam ĝi estas nur ĉirkaŭvojo.

Rimarku ankaŭ la direktan ŝablonon dum vi estas ĉe ĝi. Filtrita reto povas respondi al detekta gastiganto-nomo de vendisto per io propra, kio ŝanĝas, kiun prokurilan profilon la kliento elektas. Ne konstruu procezon ĉirkaŭ tiu kaprico. Ĝi varias laŭ loko, ŝanĝiĝas sen anonco, kaj ĝi ne estas io, kion vi povas subteni por iu alia.

Pordo 443 estas atingebla, ne permesita

Volvi tunelon en TLS sur 443 solvas atingeblon kaj nenion alian. Filtrilo, kiu kontrolas la pordon, pasigos ĝin; filtrilo, kiu prenas fingrospuron de la manpremo, ne, kaj ĉifrita klienta salutado kaŝas la servilan nomon nur kiam ambaŭ flankoj subtenas ĝin. Rulu la teston kaj eksciu, malantaŭ kia filtrilo vi estas, anstataŭ esperi.

Estas ankaŭ rendimenta kosto, kiun homoj malkovras poste. Fidinda transporto ene de fidinda transporto amplifas perdon, ĉar la interna stako resendas segmentojn, kiujn la ekstera jam resendis. Sur pura ligilo neniu rimarkas. Sur kongestita kampusa sendrata reto la tunelo fariĝas neuzebla ĝuste kiam vi bezonas ĝin, kaj la grafeo aspektas kiel paketa perdo, kvankam nenio estas intence forĵetata.

UDP kutime estas la unua viktimo, kaj indas konfirmi tion anstataŭ dedukti. Se WireGuard aŭ la implicita OpenVPN neniam kompletigas manpremon dum TCP 443 funkcias, la reto forĵetas UDP, kaj neniu kvanto da ŝlosila regenerado tion ŝanĝos:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Malplena manprema tempstampo apud samtavolano, kiu funkciis hieraŭ, estas la UDP-respondo. La du DNS-demandoj respondas alian demandon: se la loka solvilo kaj publika solvilo malkonsentas pri la finpunkta adreso, vi estas direktata kaj la transporta argumento estas la malĝusta.

Kontrolu, kio fakte lasis la maŝinon

Klientaj protokoloj priskribas, kion la kliento kredas. Kaptaĵo priskribas, kion la reto vidis, kaj la diferenco inter la du estas kie plej multaj el tiuj kazoj solviĝas:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Se vi vidas SYN-paketojn kaj neniun SYN-ACK, la blokado estas antaŭe kaj la kliento estas senkulpa. Se vi vidas kompletigitan manpremon al adreso, kiu ne estas la servila, vi parolas kun prokurilo aŭ interkaptilo. Se vi vidas nenion, kontrolu, ĉu vi kaptis sur la ĝusta interfaco antaŭ ol konkludi ion.

La konekta listo kaptas pli subtilan kazon: dua tunelo jam tenas la implicitan vojon. Du klientoj batalantaj pri la enkursiga tabelo produktas intermitajn fiaskojn, kiuj aspektas ĝuste kiel blokita reto, kaj la kaptaĵo montros trafikon elirantan tra interfaco, kiun vi ne atendis.

Malfaro, kaj la noto inda konservi

Malfaru la ŝanĝojn en la inversa ordo, en kiu vi faris ilin. Forigu la prokurilajn variablojn, haltigu la klienton, kiun vi lanĉis mane, kaj forigu ajnan vojan aŭ solvilan anstataŭigon, kiun vi aldonis:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Lasi mane lanĉitan klienton ruliĝi estas kiel tekkomputilo finas kun rompita reto ĉe la sekva oficeja vizito. Prokurilaj variabloj lasitaj en ŝela profilo rompas nerilatajn ilojn semajnojn poste, kaj la persono, kiu sencimigas ilin, ne kunligos la du eventojn.

Poste skribu kvar liniojn: la reto, la tempstampo, la fazo, kiu malsukcesis, kaj la eldonisto, kiun vi vidis. Vojo, kiu funkcias en unu kampuso kaj malsukcesas en la sekva, estas normala, kaj la sekva persono bezonas scii, ĉu la diferenco estis la prokurilo, la solvilo aŭ la filtrilo. Se la respondo estas, ke la reto malpermesas malproksiman aliron, haltu tie kaj petu de la administranto la subtenatan vojon anstataŭ porti ĉirkaŭvojon en politikon, kiun vi ne legis.

Rilataj artikoloj