Kial OpenVPN-profilo funkcias hejme sed malsukcesas en hotelo

Oficeja Wi-Fi kaj hotela ĉambro povas doni al la sama tekkomputilo du tute malsamajn retojn, kaj la profilo inter ili scias nenion pri tio. Tio, kio funkcias hejme, supozas permeseman suprenligon, funkciantan nomrekon kaj lokan subreton, kiu ne kolizias kun io, kion la tunelo portas. Ĉiu el ĉi tiuj supozoj povas malsukcesi sendepende.

La utila maniero sencimigi ĉi tion estas trakti la reton kiel kvar apartajn faktojn, poste provi ilin laŭvice. Diveni pri la profilo unue kutime produktas ŝanĝon, kiu riparas nenion kaj kaŝas la pruvojn.

Kvar retaj faktoj ŝanĝiĝas inter lokoj

La unua fakto estas, ĉu la loka reto entute lasas vin eliri. Kapta portalo enlasas aparaton al ensaluta paĝo kaj blokas ĉion alian ĝis tiu paĝo finiĝos, kio signifas, ke la tunelo ne povas ekfunkcii, kiom ajn ĝusta la profilo estas.

La dua estas nomreko. Portalo, kiu interkaptas DNS, respondas al ĉiu demando per sia propra adreso, do la VPN-gastignomo solviĝas al la portalo kaj la kliento provas konstrui tunelon al retpaĝo.

La tria estas transporta filtrado. Retoj, kiuj volas permesi nur retumadon, pasas TCP 443 al arbitraj celoj kaj forĵetas preskaŭ ĉion alian, inkluzive UDP.

La kvara estas adresado. La loka subreto povas interkovriĝi kun reto malantaŭ la tunelo, aŭ la suprenligo povas entute ne doni uzeblan IPv4-vojon.

Nomreko kaj la kapta portalo

Anstataŭigu la gastignomon en la profilo per la numera adreso de la servilo kaj provu denove. Se la IP konektiĝas kaj la nomo ne, la kulpo estas de nomreko, kaj la profilo mem estas en ordo.

Malfermu retumilon kaj provu ordinaran HTTP-paĝon antaŭ ol tuŝi la VPN. Alidirektado al ensaluta paĝo signifas, ke la portalo ankoraŭ atendas; finu ĝin, poste rekonektiĝu. Multaj hoteloj ankaŭ lasas la seancon eksvalidiĝi post kelkaj horoj, kio aspektas kiel tagmeza malkonekto prefere ol ensaluta problemo.

Se la numera adreso ankaŭ malsukcesas, nomreko ne estas la klarigo, do transiru al la transporto. Konservu la adreson, kiun vi testis, ĉar ĝi diras al la sekva kontrolo, ĉu la pakoj entute forlasis la maŝinon.

Transporta filtrado: unue UDP, TCP 443 kiel rezervo

Fluo de OpenVPN super UDP 1194 aspektas kiel nenio, kion hotela fajroŝirmilo rekonas, do ĝi estas forĵetata sen eraro. La kliento reprovas ĝis ĝia tempolimo finiĝas, kaj la uzanto vidas konekton, kiu neniam establiĝas, anstataŭ rifuzon. Fajroŝirmiloj, kiuj tiel kondutas, malofte protokolas la forĵeton ie, kie vi povas vidi ĝin. La manko de rifuzo mem estas la indico.

TCP 443 estas la fidinda rezervo, ĉar la reto ne povas distingi ĝin de ordinara HTTPS. Uzu la TCP-profilon de la funkciigisto, kiam ĝi ekzistas, ĉar ankaŭ la servilo devas aŭskulti sur tiu transporto kaj pordo; ŝanĝi nur la klienton produktas alian specon de fiasko. Se neniu TCP-profillo ekzistas, demandu la funkciigiston anstataŭ elpensi unu per redaktado de la pordo. La servila flanko devas konsenti, kaj malkongruo aspektas denove kiel fajroŝirmila problemo.

Atendu prezon en rendimento. TCP ene de TCP plifortigas retransmetojn sur perda ligo, do funkcianta TCP-tunelo povas ankoraŭ ŝajni malrapida sur kongestita hotela reto. Tio estas interŝanĝo por atingeblo, ne difekto por ĉasi.

Adresaj kolizioj kaj suprenligoj sen IPv4

Tunelo povas establiĝi kaj tamen porti nenion. Kiam la loka LAN kaj fora reto kunhavas prefikson kiel 192.168.1.0/24, la kliento konsideras la foran gastiganton rekte konektita kaj sendas la paketon al la loka ligo anstataŭ la tunelo. La simptomo estas sukcesa konekto kun unu neatingebla subreto, kio facile mistakseblas kiel servila voja problemo.

La konstanta riparo estas movi la foran LAN al nekutima privata gamo. Elekti gamon, kiun neniu uzas hejme, ekzemple 10.42.0.0/24, malhelpas la problemon por ĉiu estonta loko anstataŭ por unu. La loka provizora solvo estas eviti tiun hotelon, hotspot-on aŭ enkursigilon, kio tute ne estas solvo.

Movaj suprenligoj aldonas du variantojn. NAT ĉe la funkciigisto signifas, ke envenantaj konektoj ne alvenas, kio gravas se vi gastigas servilon sed ne por eliranta kliento. APN agordita nur kun IPv6 kaj NAT64-tradukado povas fiaski je kliento, kiu insistas pri vera IPv4-vojo, kaj la kutima rimedo estas ŝanĝi la APN-protokolon al IPv4 aŭ duobla stako.

Simptomoj post kiam la tunelo staras

Tunelo, kiu konektiĝas kaj poste silentas, kutime estas keepalive- aŭ MTU-problemo, ne blokita pordo. Konekto, kiu falas post fiksa nombro da minutoj, montras al keepalive- aŭ renegoca tempigilo. Agordu la klienton sondi sian partneron kaj restartigi, kiam respondoj ĉesas, kaj testu pli malgrandan tunelan MTU, se pingoj sukcesas dum grandaj transigoj haltas.

Antaŭ ol peti helpon, notu tri aferojn: la adreson, kiun vi provis, kaj ĉu ĝi respondis, la transporton kaj pordon, kiujn vi uzis, kaj la lokan subreton de la reto, kiu malsukcesis. Kune ili apartigas nomrekon de transporta filtrado kaj de adresa kolizio, kiuj estas la kaŭzoj, kiuj travivas kontakton kun pruvoj.