proto udp of tcp-client: watter een hoor jou bediener?

'n Profiel wat verlede maand gewerk het, hou nou uit en iemand stel voor om proto udp na proto tcp-client te verander. Soms is dit die regte stap, en soms lewer dit 'n kliënt op wat aan 'n poort koppel waar niks luister nie, omdat die bediener nooit vir die ander transport opgestel is nie. Die richtlijn beskryf hoe jou kant praat; dit kan nie 'n luisteraar aan die ander kant skep nie. Lees die profiel en die bediener saam voordat jy enige van die twee verander.

Lees die transport wat die gekose verbinding gebruik

'n Profiel kan verskeie remote-inskrywings bevat, en elkeen kan sy eie transport noem. Die kliënt werk dit in volgorde deur, so die reël wat jy eerste sien, is nie noodwendig die een wat geld nie.

Vind die inskrywing wat werklik probeer word, en lees dan sy transport. Volgorde maak saak, want die kliënt val nie stilweg deur nie. Sommige boupakke probeer die volgende inskrywing eers ná 'n time-out, so 'n werkende alternatief onderaan die lêer word sekondes later bereik as wat jy verwag. Kyk in die log na die eindpunt wat probeer word eerder as om aan te neem dat die eerste reël gewen het.

As die lêer een proto-reël naby die bokant het en verskeie remote-inskrywings daaronder, is daardie reël die verstek vir enige remote wat dit nie oorheers nie. 'n Plaaslike wysiging aan die verstek doen niks vir 'n remote-inskrywing wat sy eie noem nie.

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

UDP en TCP is nie 'n spoedinstelling nie

UDP stuur datagramme sonder om 'n geordende stroom te bou, so die tonnel se eie verkeer word nie in 'n tweede betroubare transport toegedraai nie. TCP gee jou 'n pad deur netwerke wat UDP laat val of blokkeer, teen die koste van geneste herversending wat 'n verliesryke skakel erger kan laat voel.

Dit is 'n bereikbaarheidsruil, nie 'n universele ranglys nie. Die regte keuse is die een wat die netwerk voor die kliënt toelaat. 'n Pad wat UDP op die VPN-poort laat val, sal nooit onderhandel nie, hoe goed die profiel ook geskryf is. Toets die pad en kies dan die transport.

Om alleen op grond van 'n maatstaf tussen hulle te kies, is 'n fout, want die antwoord hang daarvan af wat die netwerk voor jou toelaat. 'n Hotel of 'n korporatiewe proxy mag uitgaande TCP op 443 toelaat en niks anders nie, en daarom bied verskaffers daardie variant aan. Dit bly 'n OpenVPN-verbinding op daardie poort, nie 'n HTTPS-sessie nie, selfs al is die poortnommer die bekende een.

Wat tcp-client eintlik beteken

Die kliëntkant-richtlijn noem die beginpunt van 'n TCP-verbinding. Die bedienerkant gebruik sy eie luistervorm, en om die kliënt se woord in 'n bedienerkonfigurasie te kopieer, lewer 'n luisteraar wat verwag om gebel te word eerder as een wat aanvaar.

Om te pas beteken die twee kante stem oor die transport ooreen, nie dat hulle dieselfde string deel nie.

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

Vra die bediener waarop dit luister voordat jy aanneem die profiel is verkeerd. 'n UDP-luisteraar verskyn nie in 'n TCP-soklysing nie, en die omgekeerde is ook waar, so kyk na die protokolspesifieke siening eerder as 'n algemene een.

Wanneer die profiel invoer maar nooit koppel nie

'n Ingevoerde profiel wat dadelik uitduur, misluk gewoonlik voor enige verifikasie. Die pakket gaan na 'n poort sonder 'n luisteraar, of die netwerk laat val dit stilweg.

Toets die pad op die eenvoudigste moontlike manier: koppel aan dieselfde gasheer en poort met die transport wat die profiel beweer, vanaf dieselfde netwerk as die kliënt wat misluk.

As 'n UDP-toets niks kry en 'n TCP-toets koppel, bied die bediener die ander transport aan en is die profiel bloot verouderd. As nie een reageer nie, is die probleem stroomop van die transportkeuse en geen wysiging aan die profiel sal dit regmaak nie. Om daardie twee gevalle te onderskei neem 'n minuut en spaar 'n uur se sertifikaatontfouting wat nooit relevant was nie.

Teken die werkende transport aan

Sodra 'n kombinasie werk, skryf dit neer met die bediener, poort en protokol, en let op vanaf watter netwerk dit getoets is.

Die volgende persoon wat 'n time-out tref, sal andersins dieselfde eksperiment in die ander rigting probeer, en moontlik 'n bediener verander wat heeltemal reg was.

As die verskaffer albei variante publiseer, hou albei lêers en etiketteer hulle volgens die netwerk waarvoor hulle geskik is. Twee duidelik benoemde profiele voorkom die toevallige vermenging van 'n kliënttransport met 'n bedienerluisteraar wat nooit daarvoor opgestel is nie.