Kāpēc OpenVPN profils mājās strādā, bet viesnīcā neizdodas

Biroja Wi-Fi un viesnīcas istaba vienam un tam pašam klēpjdatoram var dot divus ļoti atšķirīgus tīklus, un profils starp tiem par to neko nezina. Tas, kas strādā mājās, pieņem piekāpīgu augšupējo savienojumu, strādājošu vārdu atrisināšanu un vietēju apakštīklu, kas nesaduras ar neko, ko tunelis pārvadā. Katrs no šiem pieņēmumiem var neizdoties atsevišķi.

Noderīgs veids, kā to atkļūdot, ir uztvert tīklu kā četrus atsevišķus faktus un pēc tam pārbaudīt tos pēc kārtas. Minēšana par profilu vispirms parasti rada izmaiņas, kas neko nelabo un aizsedz pierādījumus.

Četri tīkla fakti mainās starp vietām

Pirmais fakts ir, vai vietējais tīkls vispār ļauj jums iziet ārā. Pievienošanās portāls ielaiž ierīci pieteikšanās lapā un bloķē visu pārējo, līdz šī lapa ir pabeigta, kas nozīmē, ka tunelis nevar sākties, lai cik pareizs būtu profils.

Otrais ir vārdu atrisināšana. Portāls, kas pārtver DNS, atbild uz katru vaicājumu ar savu adresi, tāpēc VPN resursdatora nosaukums tiek atrisināts uz portālu, un klients mēģina veidot tuneli uz tīmekļa lapu.

Trešais ir transporta filtrēšana. Tīkli, kas grib atļaut tikai pārlūkošanu, laiž cauri TCP 443 uz patvaļīgiem galamērķiem un nomet gandrīz visu pārējo, tostarp UDP.

Ceturtais ir adresācija. Vietējais apakštīkls var pārklāties ar tīklu aiz tuneļa, vai arī augšupējais savienojums var vispār nesniegt lietojamu IPv4 ceļu.

Vārdu atrisināšana un pievienošanās portāls

Aizstājiet profilā resursdatora nosaukumu ar servera skaitlisko adresi un mēģiniet vēlreiz. Ja IP savienojas, bet nosaukums ne, vaina ir vārdu atrisināšanā, un pats profils ir kārtībā.

Atveriet pārlūku un pamēģiniet parastu HTTP lapu, pirms aiztiecat VPN. Novirzīšana uz pieteikšanās lapu nozīmē, ka portāls vēl gaida; pabeidziet to un pēc tam pievienojieties vēlreiz. Daudzas viesnīcas arī pārtrauc sesiju pēc dažām stundām, kas izskatās kā pārtraukums dienas vidū, nevis pieteikšanās problēma.

Ja arī skaitliskā adrese neizdodas, vārdu atrisināšana nav izskaidrojums, tāpēc pārejiet pie transporta. Saglabājiet adresi, ko pārbaudījāt, jo tā nākamajai pārbaudei pateiks, vai paketes vispār pameta mašīnu.

Transporta filtrēšana: vispirms UDP, TCP 443 kā rezerve

OpenVPN plūsma pa UDP 1194 neizskatās pēc nekā, ko viesnīcas ugunsmūris atpazītu, tāpēc tā tiek nomesta bez kļūdas. Klients mēģina vēlreiz, līdz beidzas tā taimauts, un lietotājs redz savienojumu, kas nekad neveidojas, nevis atteikumu. Ugunsmūri, kas tā uzvedas, reti kur redzamā vietā reģistrē nomešanu. Atteikuma neesamība pati par sevi ir pavediens.

TCP 443 ir uzticamā rezerve, jo tīkls to nevar atšķirt no parasta HTTPS. Izmantojiet operatora TCP profilu, ja tāds ir, jo arī serverim jāklausās šajā transportā un portā; mainot tikai klientu, rodas cita veida kļūme. Ja TCP profila nav, jautājiet operatoram, nevis izgudrojiet to, rediģējot portu. Arī servera pusei jāpiekrīt, un neatbilstība atkal izskatās kā ugunsmūra problēma.

Gaidiet veiktspējas izmaksas. TCP TCP iekšienē pastiprina atkārtotas pārraides zudumiem pakļautā savienojumā, tāpēc strādājošs TCP tunelis pārslogotā viesnīcas tīklā tomēr var šķist lēns. Tas ir maiņa pret sasniedzamību, nevis defekts, kam jāseko.

Adrešu sadursmes un augšupējie savienojumi bez IPv4

Tunelis var izveidoties un tomēr neko nepārvadāt. Ja vietējais LAN un attāls tīkls dala prefiksu, piemēram, 192.168.1.0/24, klients uzskata attālo resursdatoru par tieši pieslēgtu un sūta paketi uz vietējo saiti, nevis tuneli. Simptoms ir veiksmīgs savienojums ar vienu nesasniedzamu apakštīklu, ko viegli nepareizi nolasīt kā maršruta problēmu servera pusē.

Pastāvīgais risinājums ir pārvietot attālo LAN uz neparastu privātu diapazonu. Tāda diapazona izvēle, ko mājās neviens neizmanto, piemēram, 10.42.0.0/24, novērš problēmu katrai nākamajai vietai, nevis tikai vienai. Vietējais apietais risinājums ir izvairīties no tās viesnīcas, hotspota vai maršrutētāja, kas nemaz nav risinājums.

Mobilie augšupējie savienojumi pievieno divus variantus. Operatora līmeņa NAT nozīmē, ka ienākošie savienojumi nenonāk, kas ir svarīgi, ja mitināt serveri, bet ne izejošam klientam. APN, kas konfigurēts tikai ar IPv6 un NAT64 tulkošanu, var likt neizdoties klientam, kurš pieprasa īstu IPv4 ceļu, un parastais līdzeklis ir mainīt APN protokolu uz IPv4 vai dubulto steku.

Simptomi pēc tuneļa pacelšanas

Tunelis, kas savienojas un pēc tam apklust, parasti ir keepalive vai MTU problēma, nevis bloķēts ports. Savienojums, kas pārtrūkst pēc fiksēta minūšu skaita, norāda uz keepalive vai atkārtotas pārrunāšanas taimeri. Iestatiet klientu zondēt savu partneri un restartēties, kad atbildes apstājas, un pārbaudiet mazāku tuneļa MTU, ja pingi izdodas, bet lieli pārsūtījumi iestrēgst.

Pirms lūdzat palīdzību, pierakstiet trīs lietas: adresi, ko mēģinājāt, un vai tā atbildēja, transportu un portu, ko izmantojāt, un neizdevušā tīkla vietējo apakštīklu. Kopā tie atdala vārdu atrisināšanu no transporta filtrēšanas un no adrešu sadursmes, un tie ir cēloņi, kas iztur saskari ar pierādījumiem.