proto udp vai tcp-client: kumpaa palvelimesi kuulee?

Viime kuussa toiminut profiili päättyy nyt aikakatkaisuun, ja joku ehdottaa proto udp-asetuksen vaihtamista proto tcp-client-asetukseksi. Joskus se on oikea liike, joskus se tuottaa asiakkaan, joka yhdistää porttiin, jossa mikään ei kuuntele, koska palvelinta ei koskaan määritetty toiselle kuljetukselle. Direktiivi kuvaa, miten sinun pääsi puhuu; se ei voi luoda kuuntelijaa toiseen päähän. Lue profiili ja palvelin yhdessä ennen kuin muutat kumpaakaan.

Lue kuljetus, jota valittu yhteys käyttää

Profiili voi sisältää useita remote-merkintöjä, ja jokainen voi nimetä oman kuljetuksensa. Asiakas käy ne läpi järjestyksessä, joten ensimmäisenä näkemäsi rivi ei välttämättä ole se, joka pätee.

Etsi merkintä, jota todella yritetään, ja lue sitten sen kuljetus. Järjestys on tärkeä, koska asiakas ei siirry seuraavaan hiljaa. Jotkin koontiversiot yrittävät seuraavaa merkintää vasta aikakatkaisun jälkeen, joten tiedoston lopussa oleva toimiva vaihtoehto saavutetaan sekunteja myöhemmin kuin odotat. Seuraa lokista, mitä päätepistettä yritetään, sen sijaan että olettaisit ensimmäisen rivin voittaneen.

Jos tiedostossa on yksi proto-rivi lähellä alkua ja useita remote-merkintöjä sen alla, kyseinen rivi on oletus jokaiselle remotelle, joka ei ohita sitä. Oletuksen paikallinen muokkaus ei tee mitään remotelle, joka nimeää oman kuljetuksensa.

grep -nE '^(remote|proto)\b' client.ovpn

UDP ja TCP eivät ole nopeusasetus

UDP lähettää datagrammeja rakentamatta järjestettyä virtaa, joten tunnelin oma liikenne ei kääriydy toisen luotettavan kuljetuksen sisään. TCP antaa sinulle reitin verkkojen läpi, jotka pudottavat tai estävät UDP:n, mutta hinnaksi tulee sisäkkäinen uudelleenlähetys, joka voi saada häviöisen linkin tuntumaan pahemmalta.

Se on saavutettavuuden vaihtokauppa, ei yleinen paremmuusjärjestys. Oikea valinta on se, jonka asiakkaan edessä oleva verkko sallii. Reitti, joka pudottaa UDP:n VPN-portissa, ei koskaan neuvottele, oli profiili miten hyvin tahansa kirjoitettu. Testaa reitti ja valitse sitten kuljetus.

Niiden välillä vain mittauksen perusteella valitseminen on virhe, koska vastaus riippuu siitä, mitä edessäsi oleva verkko sallii. Hotelli tai yrityksen välityspalvelin voi sallia lähtevän TCP:n portissa 443 eikä mitään muuta, minkä vuoksi tarjoajat tarjoavat kyseisen vaihtoehdon. Se on edelleen OpenVPN-yhteys kyseisessä portissa, ei HTTPS-istunto, vaikka portin numero olisikin tuttu.

Mitä tcp-client itse asiassa tarkoittaa

Asiakaspuolen direktiivi nimeää TCP-yhteyden aloittavan pään. Palvelinpuoli käyttää omaa kuuntelumuotoaan, ja asiakkaan sanan kopioiminen palvelimen asetukseen tuottaa kuuntelijan, joka odottaa tulevansa valituksi, ei sellaista joka hyväksyy.

Yhteensopivuus tarkoittaa, että kaksi päätä sopivat kuljetuksesta, ei että ne jakavat saman merkkijonon.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Kysy palvelimelta, mitä se kuuntelee, ennen kuin oletat profiilin olevan väärä. UDP-kuuntelija ei näy TCP-sokettien luettelossa, ja päinvastoin on myös totta, joten katso protokollakohtaista näkymää yleisen sijaan.

Kun profiili tuodaan, mutta se ei koskaan yhdistä

Heti aikakatkaisuun päättyvä tuotu profiili epäonnistuu yleensä ennen mitään todennusta. Paketti menee portille, jossa ei ole kuuntelijaa, tai verkko pudottaa sen hiljaa.

Testaa reitti yksinkertaisimmalla mahdollisella tavalla: yhdistä samaan isäntään ja porttiin sillä kuljetuksella, jonka profiili väittää, samasta verkosta kuin epäonnistuva asiakas.

Jos UDP-testi ei saa mitään ja TCP-testi yhdistää, palvelin tarjoaa toista kuljetusta ja profiili on yksinkertaisesti vanhentunut. Jos kumpikaan ei vastaa, ongelma on kuljetusvalintaa ylempänä eikä mikään profiilin muokkaus korjaa sitä. Näiden kahden tapauksen erottaminen vie minuutin ja säästää tunnin varmenteiden virheenkorjausta, joka ei koskaan ollut merkityksellistä.

Kirjoita toimiva kuljetus muistiin

Kun yhdistelmä toimii, kirjoita se muistiin palvelimen, portin ja protokollan kanssa ja merkitse, mistä verkosta sitä testattiin.

Muuten seuraava aikakatkaisuun törmäävä henkilö toistaa saman kokeen toiseen suuntaan ja mahdollisesti muuttaa palvelinta, joka oli kunnossa.

Jos tarjoaja julkaisee molemmat vaihtoehdot, säilytä molemmat tiedostot ja merkitse ne verkon mukaan, johon ne sopivat. Kaksi selkeästi nimettyä profiilia estävät asiakkaan kuljetuksen sekoittumisen vahingossa palvelimen kuuntelijaan, jota ei koskaan määritetty sille.