Wêrom in OpenVPN-profyl thús wurket mar yn in hotel mislearret

Kantoar-Wi-Fi en in hotelkeamer kinne deselde laptop twa hiel ferskillende netwurken jaan, en it profyl dertusken wit dêr neat fan. Wat thús wurket, ferûnderstelt in tolerante opgeande ferbining, wurkjende nameresolúsje en in pleatslik subnet dat net botst mei wat de tunnel ferfiert. Eltse fan dy oannames kin apart mislearje.

De nuttige manier om dit te debuggen is it netwurk as fjouwer aparte feiten te behanneljen en se dan yn folchoarder te testen. Earst oan it profyl riede jout meastentiids in feroaring dy't neat reparearret en it bewiis ferberget.

Fjouwer netwurkfeiten feroarje tusken lokaasjes

It earste feit is oft it pleatslike netwurk jo hielendal nei bûten lit. In oanmeldportaal lit in apparaat op in oanmeldside ta en blokkearret al it oare oant dy side klear is, wat betsjuttet dat de tunnel net begjinne kin, hoe korrekt it profyl ek is.

It twadde is nameresolúsje. In portaal dat DNS ûnderskept, antwurdet elke fraach mei syn eigen adres, sadat de VPN-hostnamme nei it portaal resolvet en de klant besiket in tunnel nei in webside te bouwen.

It tredde is ferfiersfiltering. Netwurken dy't allinne browsen tastean wolle, litte TCP 443 nei willekeurige bestimmingen troch en smite hast al it oare fuort, ynklusyf UDP.

It fjirde is adressearring. It pleatslike subnet kin oerlaapje mei in netwurk efter de tunnel, of de opgeande ferbining biedt hielendal gjin brûkbere IPv4-rûte.

Nameresolúsje en it oanmeldportaal

Ferfange de hostnamme yn it profyl troch it numerike adres fan 'e tsjinner en probearje it opnij. As de IP ferbynt en de namme net, is nameresolúsje de skuld, en it profyl sels is yn oarder.

Iepenje in browser en probearje in gewoane HTTP-side foar't jo de VPN oanreitsje. In trochferwizing nei in oanmeldside betsjuttet dat it portaal noch wachtet; meitsje it klear en ferbynje jo dan opnij. In protte hotels ferrinne de sesje ek nei in pear oeren, wat as in middeisûnderbrekking liket ynstee fan in oanmeldprobleem.

As it numerike adres ek mislearret, is nameresolúsje net de ferklearring, dus gean oer nei it ferfier. Hâld it adres dat jo teste, want it fertelt de folgjende kontrôle oft pakketten de masine hielendal ferlitten hawwe.

Ferfiersfiltering: earst UDP, TCP 443 as efterfal

In OpenVPN-stream oer UDP 1194 liket op neat dat in hotelfirewall werkennt, dus wurdt er sûnder flater fuortsmiten. De klant besiket opnij oant syn tiidferrin ferrint, en de brûker sjocht in ferbining dy't nea ta stân komt ynstee fan in wegering. Firewalls dy't sa dogge, logge it fuortsmiten selden earne wêr't jo it sjen kinne. It ûntbrekken fan in wegering is sels de oanwizing.

TCP 443 is it betroubere efterfal, want it netwurk kin it net fan gewoane HTTPS ûnderskiede. Brûk it TCP-profyl fan 'e operator as dat bestiet, om't de tsjinner ek op dat ferfier en dy poarte harkje moat; allinne de klant feroarje jout in oar soart mislearring. As der gjin TCP-profyl is, freegje de operator ynstee fan ien te betinken troch de poarte te bewurkjen. De tsjinnerkant moat it iens wêze, en in misferhâlding liket wer as in firewallprobleem.

Ferwachtsje in prestaasjepriis. TCP yn TCP fersterket weromstjoeringen op in ferbining mei ferlies, dus in TCP-tunnel dy't wurket kin op in drok hotellnetwurk noch stadich fiele. Dat is in ruil foar berikberens, net in flater om efteroan te gean.

Adresbotsingen en opgeande ferbiningen sûnder IPv4

In tunnel kin ta stân komme en dochs neat ferfiere. As it pleatslike LAN en in netwurk fier fuort in prefiks diele lykas 192.168.1.0/24, beskôget de klant de fiere host as direkt ferbûn en stjoert it pakket nei de pleatslike skeakel ynstee fan 'e tunnel. It symptoom is in slagge ferbining mei ien ûnberikber subnet, wat maklik ferkeard lêzen wurdt as in rûteprobleem oan 'e tsjinnerkant.

De bliuwende oplossing is it fiere LAN nei in ûngewoan privaat berik te ferpleatsen. In berik kieze dat nimmen thús brûkt, lykas 10.42.0.0/24, foarkomt it probleem foar elk takomstich lokaasje ynstee fan ien. De pleatslike omwei is dat hotel, hotspot of router mije, wat hielendal gjin oplossing is.

Mobyle opgeande ferbiningen foegje twa fariaasjes ta. NAT op operatörnivo betsjuttet dat ynkommende ferbiningen net oankomme, wat fan belang is as jo in tsjinner hostje mar net foar in útgeande klant. In APN ynsteld as allinne IPv6 mei NAT64-oersetting kin in klant mislearje litte dy't op in echte IPv4-rûte stiet, en it gewoane middel is it APN-protokol te feroarjen nei IPv4 of dûbele stapel.

Symptomen neidat de tunnel omheech is

In tunnel dy't ferbynt en dan stil wurdt is meastentiids in keepalive- of MTU-probleem, net in blokkearre poarte. In ferbining dy't nei in fêst oantal minuten falt, wiist op in keepalive- of werûnderhannelingstiidmeter. Set de klant om syn partner te probearjen en opnij te begjinnen as antwurden ophâlde, en test in lytsere tunnel-MTU as pings slagje wylst grutte oerdrachten fêst komme te sitten.

Foar't jo om help freegje, skriuw trije dingen op: it adres dat jo besocht hawwe en oft it antwurde, it ferfier en de poarte dy't jo brûkten, en it pleatslike subnet fan it netwurk dat mislearre. Tegearre skiede se nameresolúsje fan ferfiersfiltering en fan in adresbotsing, en dat binne de oarsaken dy't kontakt mei bewiis oerlibje.