OpenVPN-sovitin pätkii Windowsissa? Tarkista kaksois-IP

Windowsissa OpenVPN-sovitin, joka ottaa osoitteen, pudottaa sen ja toistaa tämän muutaman sekunnin välein, ei yleensä ole DHCP-vika. Sovittimelle sanotaan, että sen pitää käyttää osoitetta, johon jokin muu jo vastaa, joten Windows merkitsee sen käyttökelvottomaksi ja asiakas aloittaa alusta. Asiakkaan loki pysyy hiljaisena, koska konflikti ratkaistaan sen alapuolella, käyttöjärjestelmän omassa verkkopinossa.

Tämä ero on tärkeä, koska jokainen tunnelin kokoonpanoon kohdistuva vianetsintävaihe jättää huomaamatta palvelinpuolen kaksoisosoitteen.

Aloita Windowsin tapahtumalokista, älä asiakkaan lokista

Windows kirjaa osoitekonfliktit järjestelmälokiin tapahtumatunnuksilla 4198 ja 4199. Ensimmäinen ilmoittaa osoitteelle havaitusta konfliktista, toinen ilmoittaa, ettei liitäntä voinut käyttää osoitetta, jolla se oli määritetty. Kumpikaan ei mainitse OpenVPN:ää, ja juuri siksi ne on helppo jättää huomaamatta.

Hae viimeisimmät tapahtumat ja vertaa niiden aikaleimoja sovittimen uusimissykliin: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikti viidentoista sekunnin välein vastaa asiakasta, joka yrittää samaa osoitetta uudelleen omistajalta, joka vastaa siihen edelleen. Yksittäinen konflikti yhteydenottohetkellä viittaa pikemminkin kertaluontoiseen törmäykseen. Kummassakin tapauksessa seuraava kysymys on, kuka muu pitää osoitetta.

Kolme järjestelyä laittaa kaksi isäntää yhdelle osoitteelle

Kysy palvelimelta, kenen se uskoo pitävän osoitetta, ja kysy sitten verkolta, kuka siihen vastaa. grep -H ifconfig-push /etc/openvpn/ccd/* luettelee jokaisen kiinnitetyn tunneliosoitteen ja sertifikaatin, johon se kuuluu. ip -4 neigh show dev tap0 näyttää, mitä silta on oppinut toisella kerroksella. Näiden kahden luettelon vertaaminen löytää useimmat kaksoiskappaleet alle minuutissa.

Kolme järjestelyä selittää lähes kaikki: client-config-dir-merkintä kiinnittää yhden osoitteen kahdelle sertifikaatille, sillattu tap-segmentti antaa koneelle osoitteen, joka toisella isännällä on jo staattisesti, tai vanhentunut vuokratiedosto palauttaa osoitteen, jonka vielä yhdistetty asiakas uskoo omistavansa. Kolmas tapaus on ovelin, koska ifconfig-pool-persist käyttää osoitteita tarkoituksella uudelleen tunnetuille asiakkaille.

Tee osoitteesta yksilöllinen sen sijaan että kilpailisit siitä

Käynnistysjärjestys ratkaisee vain, kuka voittaa tänään, joten kohtele mitä tahansa uudelleenkäynnistysjärjestykseen perustuvaa korjausta väliaikaisena. Anna jokaiselle asiakkaalle oma ifconfig-push-rivinsä tai varaa staattiset osoitteet alueelta, johon mikään silta- tai palvelinliitäntä ei koske. Tarkista asiakasluettelosta myös kaksoiskappaleet yhteisissä nimissä, koska duplicate-cn sallii kahden istunnon jakaa yhden identiteetin ja siten yhden kiinnitetyn osoitteen. Jos sillatulla laitteella todella tarvitsee kiinteän osoitteen, siirrä se omaan aliverkkoonsa tai varaa se altaasta paikassa, jonka palvelin tallentaa.

Poista persist-tiedosto vasta kun tiedät, mitkä vuokraukset se sisältää, muuten seuraava uudelleenyhteys jakaa samat osoitteet uudelleen.

Käynnistä uudelleen oikeassa järjestyksessä ja vahvista yksi omistaja osoitetta kohden

Tee muutos ensin palvelimelle ja yhdistä sitten asiakkaat uudelleen, jotta jokainen osallistuja rekisteröityy korjattuun altaaseen. Jos käynnistät asiakkaat ensin uudelleen, ne jäävät osoitteisiin, joita palvelin pitää yhä varattuina. Uudelleenkäynnistyksen jälkeen lue tilatiedosto ja vahvista, että jokainen yhteinen nimi esiintyy kerran yhdellä osoitteella. Kaksi merkintää yhdelle nimelle tarkoittaa, että vanha istunto ei koskaan sulkeutunut, ei että allas on rikki.

Jos asiakas ei edelleenkään pysty pitämään osoitettaan, tarkista, kantaisiko sitä saman isännän siltaliitäntä. Silta, joka on perinyt osoitteen laitevalmistajan laitteelta, vastaa siihen ARP:llä, vaikka VPN-palvelin olisi jo antanut osoitteen asiakkaalle.

Seuraa täyden uusimissyklin ajan ennen kuin suljet tiketin

Yksi puhdas lukema ei todista mitään. Seuraa sovitinta vähintään kymmenen minuuttia ja pakota uudelleenyhteys keskellä: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Osoitteen pitäisi kestää uudelleenyhteys ja pysyä suositellussa tilassa.

Aja sitten ensimmäisen vaiheen tapahtumakysely uudelleen ja vahvista, ettei se palauta mitään uutta. Hiljainen loki uudelleenyhteyden yli on todiste siitä, että konflikti on poissa, kun taas hiljainen loki yhden yhteyden jälkeen tarkoittaa vain, ettei kilpailua ole vielä tapahtunut. Testaa lopuksi resurssi, jonka vuoksi tunneli on olemassa, sillä osoitteensa menettänyt silta voi rikkoa toimittajan polun, vaikka VPN itse näyttää terveeltä.

Kirjaa altaan alue, jokainen kiinnitetty osoite ja sen omistava isäntä palvelimen muistiinpanoihin. Silloin seuraava törmäys huomataan minuuteissa sen sijaan, että sen uudelleen löytämiseen kuluisi koko iltapäivä.