OpenVPN ddim yn cysylltu ar Wi-Fi gwesty? Rhowch gynnig ar TCP 443
Mae proffil sy'n gweithio gartref ac yn tagu ar Wi-Fi gwesty neu gampws yn colli ei gludydd. Profwch y bloc, symudwch y gwrandawr i TCP 443, a gwybyddwch y gost.
Agorwch y cleient, pwyswch Connect a darllenwch y llinell statws yn lle'r deialog sy'n dilyn. Mae proffil sy'n tagu ar Connecting neu Waiting for server ar ôl rhwydwaith gwesty, campws neu symudol fel arfer wedi colli ei gludydd rywle ar y llwybr, nid ei gymwysterau. Y cam defnyddiol nesaf yw dysgu beth mae'r rhwydwaith honno'n ei gludo cyn i chi gyffwrdd â'r gweinydd. Peidiwch â newid dim nes bod yr un proffil wedi gweithio rywle arall.
Profwch o hotspot ffôn yn gyntaf. Os yw'r tiwnel yn codi yno, mae'r gweinydd, y dystysgrif a'r cyfrif i gyd yn iawn, a'r unig newidyn sy'n weddill yw'r rhwydwaith o'ch blaen.
Dechreuwch yn y cleient: darllenwch y llinell statws
Mae'r llinell statws yn dweud pa gam a fethodd. Mae cleient sy'n sownd ar Connecting yn dal i ddatrys y gwesteiwr neu'n agor y soced allanol; un sy'n cyrraedd Waiting for server mae ganddo lwybr ond dim ateb; un sy'n dilysu ac yna'n cwympo mae ganddo broblem hollol wahanol. Mae log y cleient a meysydd remote a proto y proffil ei hun yn dangos beth mae'r cleient yn ceisio'i wneud, ac mae --verb 4 ar gleient llinell orchymyn yn argraffu'r un manylion. Cymharu hynny â'r rhwydwaith o'ch blaen sy'n troi «mae'r VPN wedi'i rwystro» yn haeriad penodol.
Yna archwiliwch y rhwydwaith ag offer sydd gennych yn barod. Mae nc -vzu 203.0.113.10 1194 yn anfon datagram UDP, mae curl -v telnet://203.0.113.10:443 yn nodi a yw handshake TCP yn cwblhau, ac mae porwr sy'n llwytho tudalen HTTPS yn profi dim ond bod 443 allan yn cyrraedd y gwesteiwr unigol hwnnw. Mae profion bach yn ateb yr hyn na all y cleient VPN: pa borth a pha brotocol sy'n gadael y rhwydwaith hon o gwbl.
Mae tri ymddygiad rhwydwaith yn edrych yr un fath o'r cleient ac angen atebion gwahanol. Gall 443 allan fod yn agored, dim ond dirprwy a ganiateir, neu gall 443 gael ei ddanfon yn dryloyw i flwch archwilio na all ddarllen beth mae'n ei gludo. Mae'r cyntaf yn cael ei drwsio gan newid y proffil isod, yr ail gan osodiadau'r dirprwy, a gall y trydydd gwblhau handshake ac yna tagu pan fydd yr archwilydd yn penderfynu nad yw'n hoffi'r ffrwd. Gwybod pa un rydych yn ei wynebu yw'r gwahaniaeth rhwng newid deg munud a phrynhawn yn ailosod cleientiaid.
Symudwch y gwrandawr a'r proffil gyda'i gilydd
Ar ochr y gweinydd, gosodwch y gwrandawr i'r hyn y mae'r rhwydwaith yn ei ganiatáu: port 443 a proto tcp yng nghyfluniad y gweinydd, yna ailgychwynnwch y gwasanaeth a chadarnhewch y soced gyda ss -lntp. Ar ochr y cleient, rhaid i'r proffil gytuno, oherwydd mae'r cludydd a'r porth yn eistedd y tu allan i'r tiwnel: proto tcp a port 443 yn yr .ovpn, neu'r meysydd cyfatebol ar sgrin osodiadau'r ap. Mae proffil sy'n dal i anelu at UDP 1194 yn methu'n union fel o'r blaen, a'r demtasiwn yw beio mur tân sydd eisoes wedi'i drwsio. Os yw'r un gwesteiwr hefyd yn ateb HTTPS ar 443, ni all y ddau wrandawr rannu'r cyfeiriad a'r protocol hwnnw; rhowch ail gyfeiriad i'r VPN neu roi demultiplexer o'i flaen.
Dilynwch y cysylltiad cyntaf gyda tcpdump -ni any port 443 ar y ddau ben. Mae pecynnau sy'n gadael y cleient ac na chyrhaeddant byth yn golygu bod y rhwydwaith yn hidlo wedi'r cyfan, neu nad yw'r cyfeiriad yn y proffil yr un rydych yn ei dybio. Mae pecynnau sy'n cyrraedd heb ateb yn eich anfon yn ôl i log y gweinydd, lle mae anghysonddeb protocol yn ymddangos ar unwaith fel pecyn a fwriwyd.
Pan mai dim ond dirprwy sy'n gadael y rhwydwaith
Mae rhai rhwydweithiau gwestai yn caniatáu dim ond dirprwy HTTP, sy'n gyfyngiad gwahanol i borth caeedig ac yn eithrio mwy nag OpenVPN. Nid oes gan gleientiaid sy'n siarad PPTP, L2TP/IPsec neu IPsec noeth yn unig unrhyw ffordd drwyddo, oherwydd mae'r cynlluniau hynny'n disgwyl i'w protocol allanol gyrraedd y gweinydd yn uniongyrchol. Gall OpenVPN wneud, gyda http-proxy proxy.example.net 8080 ym mhroffil y cleient, ar yr amod bod y dirprwy'n caniatáu'r dull CONNECT i'ch porth. Mae dirprwy SOCKS yn haws fyth, oherwydd mae'n anfon y ffrwd ymlaen heb ofalu beth sydd y tu mewn iddi.
Lle nad oes gan y cleient gefnogaeth dirprwy, tiwnel SSH dros 443 yw'r hyn sy'n weddill fel arfer. Mae'n ychwanegu ail haen, ac efallai bod gan weithredwr y rhwydwaith farn amdano, felly triniwch ef fel pont ar gyfer un daith yn hytrach nag fel pensaernïaeth.
Prisiwch y gefnlen cyn ei chadw
Mae gan TCP o fewn TCP gost gyfarwydd. Pan fo'r cysylltiad allanol yn TCP a'r llwyth hefyd yn TCP, mae segment coll yn sbarduno ail-drosglwyddiad ar y ddwy haen, ac mae'r cysylltiad mewnol yn cilio rhag colled na all ei gweld. Mae pori yn goroesi hynny; mae sesiynau rhyngweithiol a galwadau yn ei deimlo. Cadwch y gwrandawr TCP 443 fel cefnlen ar gyfer rhwydweithiau sy'n ei fynnu, a gadewch UDP yn ddiofyn ar gyfer popeth sy'n dal i'w basio.
Cofnodwch y dewis yn enw'r proffil ac yn nodiadau'r cymorth: pa borth, pa brotocol a pha rwydwaith a'i sbardunodd. Yna gofynnwch i weinyddwr y rhwydwaith a yw'r porth hwnnw'n aros ar agor ar ôl yr adnewyddiad offer nesaf, oherwydd mae cefnlen sy'n diflannu'n dawel yn waeth na dim cefnlen o gwbl.