DNS pwynt terfyn AWS Client VPN: pam nad yw pinio'r IP a ddatryswyd yn gweithio

Yr wythnos diwethaf rhoddodd dig +short un cyfeiriad i chi ar gyfer enw'r pwynt terfyn yn eich proffil AWS Client VPN, a chysylltodd y twnnel. Yr wythnos hon mae'r un proffil yn sefyll ar 'Connecting' ar eich gliniadur tra bo copi heb ei gyffwrdd cydweithiwr yn dal i weithio. Ni rwystrwyd dim ac ni ddaeth y dystysgrif i ben. Mae rhywun wedi disodli enw gwesteiwr y pwynt terfyn gyda'r cyfeiriad a ddatryswyd hwnnw, ac nid yw'r gwasanaeth yn ateb yno mwyach. Yr enw a allforiwyd yw'r rhan a adeiladwyd i oroesi'r newid hwnnw.

Efallai nad enw yn eich proffil yw'r enw sy'n cael ei ymholi

Mae proffiliau a allforir o Client VPN yn aml yn cario remote-random-hostname. Gyda'r opsiwn hwnnw ymlaen, mae'r cleient yn adeiladu label tafladwy, yn ei uno ag enw'r pwynt terfyn gyda dot, ac yn datrys yr enw cyfun. Mae cofnod wildcard ar barth y pwynt terfyn yn ateb unrhyw label, a dyna pam mae rhagddodiad dychmygol yn dal i ddatrys a pham mae'r tric yn aros yn anweledig pan geisiwch atgynhyrchu'r ymholiad â llaw.

Felly pan fyddwch yn gludo enw'r pwynt terfyn i derfynell ac yn cael ateb, rydych wedi datrys enw gwahanol i'r un y mae'r cleient yn ei ddefnyddio wrth gysylltu. Nid diffyg i'w gywiro yn y proffil yw'r anghysondeb hwnnw. Mae'r label yn cael ei ailgynhyrchu'n fwriadol: mae'r opsiwn yn atal cachau rhag cadw ateb hen ffasiwn, ac ni fydd byth yn adnabod eich peiriant na'ch sesiwn.

Rwyf wedi taro'r achos cydnawsedd lle mae cleient yn anwybyddu'r opsiwn yn llwyr. Mae AWS yn dogfennu'r ateb: cadwch enw gwirioneddol y pwynt terfyn ac ychwanegwch linyn ar hap a dot o'i flaen, gan ei drin fel patrwm enwi yn hytrach na gwerth i'w gludo. Mae defnyddio hynny ar gleient hen yn rhesymol; nid yw caledu'r llinyn rhagddodiadol fel y pwynt terfyn.

Pam na all ateb a gedwir fod yn gywir

Mae AWS yn rheoli cyfeiriadau pwynt terfyn Client VPN ac maent yn newid dros amser, ac mae'r ddogfen arferion gorau yn dweud hynny'n blwmp. Mae ateb a gofnodwyd yn snapshyn o un datrysiad. Mae proffil sy'n ei galedu yn dod yn broffil wedi'i anelu at westai sydd wedi'i ddatgomisiynu cyn gynted ag y bydd'r gwasanaeth yn symud, ac anaml y mae'r methiant yn edrych fel DNS: cewch seibiant cysylltu neu handshake wedi stopio, felly mae pobl yn erlid llwybr a thystysgrifau.

Mae'r un ateb yn /etc/hosts yn etifeddu'r un dyddiad dod i ben gyda phroblem ychwanegol. Mae cofnod hosts yn goroesi ailgychwyn, ailsaibio ac atgyweiriadau 'ailosod y cleient', felly mae'r methiant yn dychwelyd bob tro y bydd'r cyfeiriad yn symud. Gwelais un yn eistedd yn ddiniwed am wythnosau, yna'n cymryd pob peiriant a'i cludai allan o'r gêm tra oedd gosodiadau newydd yn cysylltu'n normal. Y rhaniad hwnnw, un grŵp yn methu a grŵp arall yn iawn ar yr un cyfrif, yw'r cliw rhataf a gewch.

Cwmpaswch y hap-drefnu'n gywir hefyd. Mae'n digwydd fesul ymgais i gysylltu. Nid yw twnnel sefydledig yn ail-ddatrys ei bwynt terfyn, nid yw'n newid gweinyddwyr ganol sesiwn, ac nid yw ceisiadau unigol y cymhwysiad yn dewis gwesteiwr VPN newydd bob un. Dim ond yr ymgais nesaf sy'n datrys eto, a dyna pam nad yw sesiwn sy'n gweithio trwy'r prynhawn yn dweud dim am fore yfory.

Beth mae'r gwasanaeth yn ei wirio pan ddaw'r twnnel i fyny

Mae Client VPN yn mynnu bod y cyfeiriad rydych wedi cysylltu ag ef yn cyd-fynd â chyfeiriad a ddatryswyd ar gyfer enw DNS y pwynt terfyn. Mae'r un gofyniad hwnnw'n esbonio sawl methiant sy'n edrych yn ddigyswllt: cofnod DNS addasedig yn pwyntio i rywle arall, frontend addasedig sy'n anfon ymlaen i gyfeiriad gwirioneddol y pwynt terfyn, a phroffil wedi'i ailysgrifennu i gyfeiriad crai. Mae AWS yn dogfennu'r trefniant cofnod addasedig a blaenyrru fel methiant gyda chleientiaid diweddar AWS. Mae'r gwiriad yn gul; nid yw'n ddyfarniad bod pob alias wedi'i wahardd.

Nid yw'n rheol gyffredinol am brotocolau VPN chwaith. Mae remote rhifiadol yn hollol ddilys mewn defnydd OpenVPN cyffredin, ac mae llawer ohonynt yn gweithio felly. Daw'r cyfyngiad o'r trefniant rheoledig, nid o'r protocol oddi tano.

Sy'n gwneud ymlacio gwiriad tystysgrif yn atgyrchiad anghywir. Os bydd proffil yn methu ar ôl cyfnewid cyfeiriad, mae analluogi gwirio gweinydd yn symud y gwall yn hytrach na thrwsio'r datrysiad neu'r gofyniad cydweddu cyfeiriad, ac yn gadael cleient a fydd yn ymddiried yn unrhyw beth. Cadwch y CA a allforiwyd, gwirio gweinydd a gosodiadau cyd-ddilysu yn union fel y daethant.

Rhestrau caniatáu, allbwn a DNS preifat yw tri phroblem ar wahân

Mae rheol tân mur sy'n rhaid caniatáu cyrchfan cyn i liniadur gysylltu yn ymwneud â'r gwrandäwr allanol. Rhowch enw'r pwynt terfyn, y cludiant a'r porth wedi'i ffurfweddu i berchennog y rhwydwaith, yna gofynnwch a all eu rheolaeth ddilyn ymddygiad DNS y gwasanaeth. Mae rheol sy'n dal un cyfeiriad a gofnodwyd yn snapshyn â dyddiad dod i ben heb ei ysgrifennu. Os mai dim ond cyrchfannau anghyfnewidiol y mae'r rheolaeth yn eu derbyn, setlwch y bwlch hwnnw cyn ei gyflwyno yn hytrach na chaledu ateb yn dawel.

Mae gan bartner sydd angen cyfeiriad ffynhonnell sefydlog ar gyfer ceisiadau a wneir ar ôl i'r twnnel godi ofyniad gwahanol: allbwn. Mae'r hyn y mae gwefan yn ei weld yn dibynnu ar lwybr y cymhwysiad a pholisi twnnel hollt, nid ar y cyfeiriad y cysylltodd y cleient ag ef. Efallai na fydd traffig twnnel hollt yn cyffwrdd AWS o gwbl.

Mae DNS preifat y tu mewn i'r twnnel yn drydedd haen. Mae'r datryswr a roddir i gleientiaid yn ateb enwau mewnol ar ôl cysylltu; ni all ddatrys y pwynt terfyn cyhoeddus cyn bod y twnnel yn bodoli. Mae methiant datrys y pwynt terfyn a methiant datrys cymhwysiad mewnol yn digwydd ar wahanol gamau, ac mae eu cymysgu yn eich anfon i'r log anghywir.

Mae teulu cyfeiriadau yn perthyn i'r un rhestr. Nid yw ateb IPv4 yn dweud dim am lwybr a ganiateir i bwynt terfyn IPv6 neu ddau stac, felly nid yw snapshyn a gymerwyd mewn un teulu yn dystiolaeth i'r llall.

Gwiriwch gysylltiad heb binio unrhyw beth

Dechreuwch o'r proffil fel y'i hallforiwyd a darllenwch beth mae'n ei ofyn mewn gwirionedd:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Yna cymharwch dri pheth: enw'r pwynt terfyn sydd gan y proffil, y cyfeiriad y mae'r cleient yn ei adrodd ar gyfer ymgais newydd, a'r hyn y mae'r enw'n datrys iddo ar hyn o bryd. Nid yw enw sy'n datrys yn profi dim ond bod y cofnod yn ateb; mae cludiant a dilysu ar wahân, ac nid oes rhaid i'r pwynt terfyn ateb ping. Log y cleient ei hun yw'r unig ffynhonnell ar gyfer yr eitem ganol, felly cofnodwch ef yn ystod yr ymgais yn hytrach nag ar ôl hynny.

Mae cyfeiriad sy'n ateb heddiw yn dystiolaeth am heddiw; yr enw yw'r peth y mae'r gwasanaeth yn ei gadw'n ddilys. Cofnodwch yr arsylwad, anfonwch ef at pwy bynnag sy'n berchen ar y pwynt terfyn, a gadewch i'r proffil bwyntio at yr enw.

Dau arferiad i'w gollwng: analluogi gwiriadau tystysgrif i fynd heibio handshake wedi stopio, a pheli labeli o flaen enw'r pwynt terfyn gan obeithio y bydd un yn glynu. Mae label yn datrys drwy'r cofnod wildcard neu mae'r broblem yn rhywle arall. Os yw proffil wedi'i ffurfweddu'n gywir yn dal i fethu, anfonwch yr ymholiad manwl a'r digwyddiad cysylltu, nid enw gwesteiwr hwy.

Cyn i chi gau'r mater: mae'r proffil yn dal i gario enw'r pwynt terfyn a allforiwyd, nid oes ffeil hosts yn pinio'r cyfeiriad, mae remote yn log y cleient yn cyd-fynd â datrysiad cyfredol, ac mae'r rheol tân mur yn enwi'r pwynt terfyn yn hytrach na chyfeiriad. Dyna hefyd y cyflwr i'w drosglwyddo i'r person nesaf.