OpenVPN wurket thús mar net yn ien netwurk: UDP of TCP?

Itselde profyl ferbynt thús en bliuwt hingjen op in hotel-, kampús- of filiaalnetwurk. De oanmeldgegevens binne net feroare, dus de nijsgjirrige fariabele is it paad: wat der mei de pakketten bart foardat OpenVPN se lêst. Fjouwer mooglike oarsaken fergelykje yn ’e folchoarder wêryn’t se te testen binne is better as rieden oer sertifikaten. Elk lit in oar spoar efter, en it spoar is wat se skiedt.

Hokker stadium mislearre is, seit hokker fergeliking fan belang is

It klantloch registrearret al hoe fier’t jo kamen. In rigel dy’t seit dat de ûnderhanneling oer de TLS-kaai net binnen de tiid barde, betsjut dat in earste pakket fuortgie en neat brûkber weromkaam, wat op it paad wiist. In sertifikaatôfwizing liket hiel oars: in antwurd komt oan, en dan neamt in spesifike ferifikaasjeflater de reden. Tink oan ’e lêste rigel foar de werhellus, want dat is de wearde dy’t jo tusken netwurken fergelykje.

Meitsje in opname wylst jo werhelje, net dêrnei. Op ’e klant lit tcpdump -ni any udp port 1194 sjen oft der hielendal in antwurd weromkomt. Werhelje it op ’e WAN-ynterface fan in tsjinner dy’t jo beheare, wat sjen lit oft dy pakketten hielendal it fiere ein berikke.

Iensidich ferkear is it meast brûkbere resultaat dat hjir beskikber is, want it feroaret in tuskenskoftige klacht yn in rjochting om te ûndersykjen. Bewarje de opnamebestannen, want it folgjende rapport oer itselde probleem is makliker te sluten mei bewiis as mei in beskriuwing.

UDP-filtern tsjin in sletten poarte

In protte tagongsnetwurken fine oanhâldend UDP fertocht, en guon providers binne it dermei iens. In sletten poarte makket deselde stilte fan ’e klantkant. It ferskil is selektyfens: in filter is geneigd om kieskeurich te wêzen oer hokker bestimmingen of poarten it loslit, wylst in sletten poarte alles wegeret dat op dy iene poarte rjochte is.

In TCP-profyl op poarte 443 is de gewoane oplossing, want it liket op in gewoane HTTPS-stream en giet troch de measte captive-portalen en útgongsfilters. Twa betingsten moatte jilde. De tsjinner moat harkje mei proto tcp-server en de klant moat oerienkomme mei proto tcp-client, en de operator moat dat alternatyf einpunt publisearje. In wurkjend UDP-profyl oerskriuwe om TCP 443 te bewearen helpt neat as oan ’e oare kant nimmen harket.

In sletten poarte is in konfiguraasjeprobleem, net in sensuerprobleem. In tsjinner efter in thúsrûter hat ferstjoering fan syn UDP-poarte nedich, en de fjoerwâl fan ’e rûter moat it tastean. As de poarte nea tastien wie, mislearret elke klant by de ûnderhanneling likefolle wat de oanmeldgegevens binne, en de flater folget de tsjinner yn stee fan it netwurk.

Aldere protokollen fergelykje min op dizze as. PPTP hat TCP 1723 plus GRE nedich, en GRE is IP-protokol 47 yn stee fan in poarte, dus gjin gewoane poartferstjoering drukt dat út.

As it de switch is dy’t pakketten lit falle

In beheard switch kin de tunnel mei opsetsin falle litte. Guon HPE- en Aruba-modellen hawwe in UDP-oerstreamingsbeskermingskontrôle, soms oantsjutten as Prevent UDP Blat Attack, yn har seksje foar avansearre befeiliging. As dy kontrôle aktyf is, antwurdet in tsjinner efter de switch neat en rint elke klant op deselde wize op ’e tiid. It útskeakelje en de rinnende konfiguraasje bewarje is de hiele reparaasje, mar pas neidat jo fêststeld hawwe dat de switch echt op it paad sit.

Tsjinbewiis is wat in switch-fal skiedt fan in providerblokkade. Lês de ynterface-tellers en it oerstreamingsbeskermingsloch foardat jo in ticket by de ISP iepenje. Konsuminterûters mei DoS- of oerstreamingsbeskerming falle op deselde manier, en itselde jildt foar elke tuskenbak mei in koarte UDP-rêsttiid. In hânskudden dat nea foltôge wurdt wiist op in fal, wylst in tunnel dy’t nei minuten stilte stjert op ’e tiid wiist.

Skriuw elk apparaat tusken de klant en de tsjinner op foardat jo in profyl feroarje. In reparaasje op ’e ferkearde laach liket goed oant it folgjende netwurk. Dy list fertelt de folgjende yngenieur ek wêr’t er sjen moat sûnder it hiele ûndersyk te werheljen.

In adresoerlaap dy’t op in DNS-flater liket

In tagongsnetwurk nûmere binnen 10.0.0.0/8 kin de tunnelpool oerlaapje, en de resolver wennet meastentiids yn dy pool. As in laptop in adres lykas 10.184.178.50 mei in /8-masker op Wi-Fi krijt, is elke 10.x-bestimming per definysje lokaal. Pakketten foar 10.4.0.1 geane dan nei it LAN, de tunnel bliuwt oan, en namme-oplossing mislearret.

ip addr lit de oerlaap yn ien eachopslach sjen, en ip route get 10.4.0.1 lit sjen wêr’t it pakket echt besoarge wurde soe. Om’t it sichtbere symptoom in resolverflater is, oerlibbet dit gefal faak ferskate rûnen fan DNS-feroarings.

Nûmerje de pool op ’e nij of hâld dat tagongsnetwurk bûten it berik. Gjin ynstelling oan ’e klantkant herstelt fan in oerlaap.

Kieze tusken in TCP-fallback en in paadreparaasje

Kies de TCP-fallback as jo it paad net beheare en brûkers hjoed wurkje moatte, en akseptearje de kosten: TCP binnen TCP gedraacht him min op ferlieslike ferbiningen, en de fallback hat in harker nedich dy’t jo beheare. Kies de paadreparaasje as de blokkade op ynfrastruktuer sit dy’t jo besitte, want in fjoerwâlregel is goedkeaper as in twadde harker. Hoe dan ek, gean de lagen yn folchoarder troch: ferbining, bûtenste transport, ûnderhanneling, ynterne routing. It stadium dat op dat netwurk mislearre is it iennichste feit dat fan belang is.

Registrearje it resultaat per netwurk yn stee fan per brûker. It folgjende rapport oer deselde flater begjint dan by in bekend stadium yn stee fan by in sertifikaatteory. Dy registraasje is ek wat in permaninte twadde harker rjochtfeardiget, as dy ea nedich is.