Hoekom 'n OpenVPN-profiel by die huis werk maar in 'n hotel misluk

Kantoor-Wi-Fi en 'n hotelkamer kan dieselfde skootrekenaar twee heel verskillende netwerke gee, en die profiel tussenin weet niks daarvan nie. Wat by die huis werk, veronderstel 'n toegeeflike opwaartse skakel, werkende naamresolusie en 'n plaaslike subnet wat nie bots met enigiets wat die tonnel vervoer nie. Elke veronderstelling kan onafhanklik misluk.

Die nuttige manier om dit te ontfout, is om die netwerk as vier afsonderlike feite te behandel en dit dan in volgorde te toets. Om eerste aan die profiel te raai, lewer gewoonlik 'n verandering op wat niks regmaak nie en die bewyse verduister.

Vier netwerkfeite verander tussen liggings

Die eerste feit is of die plaaslike netwerk jou hoegenaamd deurlaat. 'n Aanmeldportaal laat 'n toestel by 'n aanmeldbladsy in en blokkeer alles anders tot daardie bladsy voltooi is, wat beteken die tonnel kan nie begin nie, maak nie saak hoe korrek die profiel is nie.

Die tweede is naamresolusie. 'n Portaal wat DNS onderskep, antwoord elke navraag met sy eie adres, sodat die VPN-gasheernaam na die portaal resolusie kry en die kliënt 'n tonnel na 'n webblad probeer bou.

Die derde is vervoerfiltrering. Netwerke wat net blaai wil toelaat, laat TCP 443 na willekeurige bestemmings deur en laat byna alles anders val, insluitend UDP.

Die vierde is adressering. Die plaaslike subnet kan oorvleuel met 'n netwerk agter die tonnel, of die opwaartse skakel kan hoegenaamd geen bruikbare IPv4-pad bied nie.

Resolusie en die aanmeldportaal

Vervang die gasheernaam in die profiel met die bediener se numeriese adres en probeer weer. As die IP verbind en die naam nie, is resolusie die fout, en die profiel self is in orde.

Maak 'n blaaier oop en probeer 'n gewone HTTP-bladsy voordat jy aan die VPN raak. 'n Herleiding na 'n aanmeldbladsy beteken die portaal hang nog; voltooi dit en verbind dan weer. Baie hotelle laat ook die sessie na 'n paar uur verval, wat soos 'n middagonderbreking lyk eerder as 'n aanmeldprobleem.

As die numeriese adres ook misluk, is resolusie nie die verklaring nie, so skuif na die vervoer. Hou die adres wat jy getoets het, want dit sê vir die volgende toets of pakkette die masjien hoegenaamd verlaat het.

Vervoerfiltrering: UDP eerste, TCP 443 as terugval

’n Vloei met OpenVPN oor UDP 1194 lyk soos niks wat ’n hotellbrandmuur herken nie, so dit word sonder fout laat val. Die kliënt probeer weer tot sy tydsverloop verstryk, en die gebruiker sien ’n verbinding wat nooit tot stand kom nie eerder as ’n weiering. Brandmure wat so optree, teken die val selde ergens aan waar jy dit kan sien. Die afwesigheid van ’n weiering is self die leidraad.

TCP 443 is die betroubare terugval, want die netwerk kan dit nie van gewone HTTPS onderskei nie. Gebruik die operateur se TCP-profiel wanneer een bestaan, aangesien die bediener ook op daardie vervoer en poort moet luister; om net die kliënt te verander, lewer ’n ander soort mislukking. As geen TCP-profiel bestaan nie, vra die operateur eerder as om een uit te dink deur die poort te redigeer. Die bedienerkant moet saamstem, en ’n wanaanpassing lyk weer net soos ’n brandmuurprobleem.

Verwag ’n werkverrigtingkoste. TCP binne TCP versterk herversendings op ’n verliesryke skakel, so ’n TCP-tonnel wat werk, kan op ’n oorvol hotelnetwerk steeds traag voel. Dit is ’n ruil vir bereikbaarheid, nie ’n fout om na te jaag nie.

Adresbotsings en opwaartse skakels sonder IPv4

’n Tonnel kan tot stand kom en steeds niks vervoer nie. Wanneer die plaaslike LAN en ’n afgeleë netwerk ’n voorvoegsel soos 192.168.1.0/24 deel, beskou die kliënt die afgeleë gasheer as direk verbind en stuur die pakket na die plaaslike skakel in plaas van die tonnel. Die simptoom is ’n suksesvolle verbinding met een onbereikbare subnet, wat maklik verkeerd gelees word as ’n roeteprobleem aan die bedienerkant.

Die permanente oplossing is om die afgeleë LAN na ’n ongewone private reeks te skuif. Om ’n reeks te kies wat niemand by die huis gebruik nie, soos 10.42.0.0/24, voorkom die probleem vir elke toekomstige ligging in plaas van net een. Die plaaslike noodoplossing is om daardie hotel, hotspot of router te vermy, wat glad nie ’n oplossing is nie.

Mobiele opwaartse skakels voeg twee variasies by. NAT op die draervlak beteken inkomende verbindings kom nie aan nie, wat saak maak as jy ’n bediener huisves, maar nie vir ’n uitgaande kliënt nie. ’n APN wat as slegs-IPv6 met NAT64-vertaling opgestel is, kan ’n kliënt laat misluk wat op ’n werklike IPv4-pad aandring, en die gebruiklike oplossing is om die APN-protokol na IPv4 of dubbele stapel te verander.

Simptome nadat die tonnel op is

’n Tonnel wat verbind en dan stil word is gewoonlik ’n keepalive- of MTU-probleem, nie ’n geblokkeerde poort nie. ’n Verbinding wat na ’n vaste aantal minute val, dui op ’n keepalive- of heronderhandelingstydhouer. Stel die kliënt om sy eweknie te peil en weer te begin wanneer antwoorde ophou, en toets ’n kleiner tonnel-MTU as pings slaag terwyl groot oordragte vassteek.

Voordat jy om hulp vra, skryf drie dinge neer: die adres wat jy probeer het en of dit geantwoord het, die vervoer en poort wat jy gebruik het, en die plaaslike subnet van die netwerk wat misluk het. Saam skei hulle naamresolusie van vervoerfiltrering van ’n adresbotsing, wat die oorsake is wat kontak met bewyse oorleef.