Addasydd OpenVPN ar Windows yn fflapio? Gwirio am IP ddyblyg
Mae addasydd Windows sy'n fflapio yn aml yn wrthdaro cyfeiriad, nid nam gyrrwr. Darllenwch ddigwyddiadau 4198 a 4199, canfyddwch yr ail berchennog, yna pinio cyfeiriadau unigryw.
Ar Windows, nid yw addasydd OpenVPN sy'n cymryd cyfeiriad, yn ei ollwng ac yn ailadrodd hynny bob ychydig eiliadau fel arfer yn nam DHCP. Gorchmynnir i'r addasydd ddefnyddio cyfeiriad y mae rhywbeth arall eisoes yn ateb drosto, felly mae Windows yn ei farcio'n andefnyddiadwy ac mae'r cleient yn dechrau eto. Mae log y cleient yn aros yn dawel oherwydd bod y gwrthdaro'n cael ei ddatrys oddi tano, y tu mewn i stac rhwydwaith y system weithredu ei hun.
Mae'r gwahaniaeth hwnnw'n bwysig, oherwydd bydd pob cam datrys problemau sy'n anelu at ffurfweddiad y tiwnel yn methu cyfeiriad dyblyg ar ochr y gweinydd.
Dechreuwch gyda log digwyddiadau Windows, nid log y cleient
Mae Windows yn cofnodi gwrthdaro cyfeiriadau yn y log System, gyda IDau digwyddiad 4198 a 4199. Mae'r cyntaf yn adrodd am wrthdaro a ganfuwyd ar gyfer cyfeiriad, mae'r ail yn adrodd na allai rhyngwyneb ddefnyddio'r cyfeiriad y cafodd ei ffurfweddu ag ef. Nid yw'r un ohonynt yn sôn am OpenVPN, a dyna'n union pam mae'n hawdd eu hanwybyddu.
Tynnwch y digwyddiadau diweddar a chymharu eu stampiau amser â chylch adnewyddu'r addasydd: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Mae gwrthdaro bob pymtheg eiliad yn cyd-fynd â chleient sy'n ailgeisio'r un cyfeiriad yn erbyn perchennog sy'n parhau i ateb drosto. Mae un gwrthdaro ar amser cysylltu yn awgrymu gwrthdrawiad unwaith yn unig. Beth bynnag, y cwestiwn nesaf yw pwy arall sydd â'r cyfeiriad.
Mae tri threfniant yn rhoi dau westai ar un cyfeiriad
Gofynnwch i'r gweinydd pwy y mae'n credu sydd â'r cyfeiriad, yna gofynnwch i'r rhwydwaith pwy sy'n ateb drosto. Mae grep -H ifconfig-push /etc/openvpn/ccd/* yn rhestru pob cyfeiriad tiwnel sydd wedi'i binio a'r dystysgrif y mae'n perthyn iddi. Mae ip -4 neigh show dev tap0 yn dangos yr hyn y mae'r bont wedi'i ddysgu ar yr ail haen. Mae cymharu'r ddwy restr yn canfod y rhan fwyaf o'r dyblygiadau mewn llai na munud.
Mae tri threfniant yn esbonio bron pob un: mae cofnod client-config-dir yn pinio un cyfeiriad ar gyfer dwy dystysgrif, mae segment tap wedi'i bontio'n rhoi cyfeiriad i beiriant y mae gwestai arall eisoes yn ei feddu'n statig, neu mae ffeil les stale yn dychwelyd cyfeiriad y mae cleient sy'n dal i fod wedi cysylltu yn credu ei fod yn berchen arno. Y trydydd achos yw'r mwyaf llechwraidd, oherwydd mae ifconfig-pool-persist yn ailddefnyddio cyfeiriadau'n fwriadol ar gyfer cleientiaid hysbys.
Gwnewch y cyfeiriad yn unigryw yn lle rasio amdano
Mae trefn cychwyn yn penderfynu pwy sy'n ennill heddiw yn unig, felly triniwch unrhyw atgyweiriad sy'n seiliedig ar y dilyniant ailgychwyn fel un dros dro. Rhowch linell ifconfig-push ei hun i bob cleient, neu ddyrannu cyfeiriadau statig o ystod nad oes unrhyw ryngwyneb pont na gweinydd yn ei chyffwrdd. Archwiliwch y rhestr cleientiaid am enwau cyffredin dyblyg hefyd, oherwydd mae duplicate-cn yn caniatáu i ddau sesiwn rannu un hunaniaeth ac felly un cyfeiriad wedi'i binio. Os oes angen cyfeiriad sefydlog ar ddyfais bontio mewn gwirionedd, symudwch hi i'w is-rwyd ei hun neu ei chadw o'r pwll mewn man y mae'r gweinydd yn ei gofnodi.
Dilewch y ffeil persist dim ond ar ôl i chi wybod pa lesiadau sydd ganddi, neu bydd yr ailgysylltiad nesaf yn dosbarthu'r un cyfeiriadau eto.
Ailgychwynnwch yn y drefn iawn a chadarnhau un perchennog fesul cyfeiriad
Cymhwyswch y newid ar y gweinydd yn gyntaf, yna ailgysylltu'r cleientiaid, fel bod pob cyfranogwr yn cofrestru yn erbyn y pwll wedi'i gywiro. Mae ailgychwyn cleientiaid yn gyntaf yn eu gadael â chyfeiriadau y mae'r gweinydd yn dal i gredu sydd wedi'u cymryd. Ar ôl yr ailgychwyn, darllenwch y ffeil statws a chadarnhau bod pob enw cyffredin yn ymddangos unwaith gydag un cyfeiriad. Mae dau gofnod ar gyfer un enw yn golygu na chaeodd hen sesiwn erioed, nid bod y pwll wedi torri.
Os nad yw cleient yn dal i allu cadw ei gyfeiriad, gwiriwch a oes rhyngwyneb pont ar yr un gwestai yn ei gario. Bydd pont sydd wedi etifeddu cyfeiriad oddi wrth ddyfais gwerthwr yn ateb ARP drosto hyd yn oed pan fydd gweinydd y VPN eisoes wedi rhoi'r cyfeiriad hwnnw i gleient.
Gwyliwch drwy gylch adnewyddu llawn cyn cau'r tocyn
Nid yw un darlleniad glân yn profi dim. Gwyliwch yr addasydd am o leiaf ddeng munud a gorfodi ailgysylltiad yn y canol: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Dylai'r cyfeiriad oroesi'r ailgysylltiad ac aros mewn cyflwr a ffefrir.
Yna ailgynhaliwch y cwestiwn digwyddiadau o'r cam cyntaf a chadarnhau nad yw'n dychwelyd dim byd newydd. Mae log tawel ar draws ailgysylltiad yn dystiolaeth bod y gwrthdaro wedi mynd, tra nad yw log tawel ar ôl un cysylltiad yn golygu ond nad yw'r ras wedi digwydd eto. Yn olaf, profwch yr adnodd y mae'r tiwnel yn bodoli ar ei gyfer, oherwydd gall pont a gollodd ei chyfeiriad dorri llwybr gwerthwr tra bod y VPN ei hun yn edrych yn iach.
Cofnodwch ystod y pwll, pob cyfeiriad wedi'i binio a'r gwestai sy'n berchen arno yng nodiadau'r gweinydd. Yna bydd y gwrthdrawiad nesaf yn cymryd munudau i'w sylwi yn lle prynhawn i'w ailddarganfod.