Portti 1194 on jo käytössä: kuka omistaa tämän OpenVPN-soketin?
Osoitteen jo käytössä -virhe kuuluu paikalliseen sidontaan. Vertaa kuljetusta, osoitetta ja nimiavaruutta ennen kuin vaihdat portteja tai pysäytät väärän prosessin.
Käynnistä sama palvelinprofiili kahdesti, ja toinen prosessi päättyy virheeseen, että osoite on jo käytössä portille 1194. Tavallisessa tapauksessa diagnostiikkakäynnistys loi ristiriidan, ja alkuperäinen instanssi palvelee asiakkaita edelleen täysin kunnolla. Tämä tarina selittää suuren osan näistä raporteista, ja se kannattaa tunnistaa ennen kuin mitään käynnistetään uudelleen. Se on myös halvin ratkaisuvaihtoehto.
Virhe kuvaa paikallista sidontaa eikä mitään sen ulkopuolelta. Se ei ole todiste siitä, että palveluntarjoaja estää portin, että asiakas lähetti väärän salasanan tai että varmenteiden ketju on rikki.
Lue tarkka sidontavirhe
Kaksi virhettä tästä perheestä tarkoittavat eri asioita, ja niiden sekoittaminen vie sinut väärälle kerrokselle. „Osoite on jo käytössä“ kertoo, että toinen soketti pitää pyytämääsi päätepistettä. „Osoite ei ole käytettävissä“ kertoo, että pyytämääsi osoitetta ei vielä ole tällä isännällä, mikä on valmiusongelma eikä kopio.
systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager
Kopioi virheen teksti ennen kuin muutat mitään, mukaan lukien sen mainitsema osoite ja portti. Palvelu, joka odottaa liittymän ilmestymistä, kirjaa toisen virheen toistuvasti ja sitoo sitten onnistuneesti, kun osoite on olemassa; palvelu, joka kirjaa ensimmäisen virheen, ei koskaan onnistu ennen kuin kopio on ratkaistu. Sen kirjaaminen, kumman näit, ei maksa mitään ja säästää hukkaan menneen liittymän etsinnän.
Luetteloi soketti, älä portti
Portin numero on puutteellinen luettelo. Päätepiste on kuljetus, osoiteperhe, paikallinen osoite ja portti, kaikki yhden verkon nimiavaruuden sisällä. UDP-kuuntelija ja TCP-kuuntelija samassa numerossa ovat eri soketteja, eivätkä kaksi prosessia samassa numerossa eri nimiavaruuksissa kohtaa koskaan.
ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'
Aja ensin kuljetus, jota profiili todella käyttää. Katso sitten paikallisen osoitteen saraketta pelkän numeron sijaan: jokeri-sidonta kattaa kaikki paikalliset osoitteet, joten toinen prosessi, joka pyytää yhtä tiettyä osoitetta, voi törmätä siihen, vaikka tulostetut merkkijonot eroaisivat. Soketin uudelleenkäyttöasetukset ja alustan säännöt ratkaisevat tarkan tuloksen, minkä vuoksi tämän pitäisi olla havainto eikä sääntö, jota sovellat jokaiseen käyttöönottoon.
Selvitä, mikä prosessi sen omistaa
Numeeriset päätepisteet ja prosessitiedot tunnistavat omistajan, kun käyttöoikeutesi sallivat sen, ja omistaja on se, mitä tarvitset, ei ohjelman nimi. Kaksi OpenVPN-prosessia voi ajaa eri profiileja, ja kuuntelijaa pitävä prosessi voi olla se, jota vähiten odotat.
sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194
Vertaa löytämääsi palvelunhallintaan, konttien ajonaikaiseen ympäristöön tai aiemmasta testistä jääneeseen päätteen prosessiin. Prosessin yksityiskohtien puuttuminen ei ole todiste siitä, että soketilla ei ole omistajaa; se tarkoittaa yleensä, että kysely ajettiin ilman riittävää lupaa. Samoin vain TCP:n lista ei poista UDP-ristiriitaa, joten tutki virheessä nimetty kuljetus. Pelkkä prosessin nimi ei koskaan kerro, mikä profiili ladattiin, ja profiili on se, joka ratkaisee päätepisteen.
Yksi omistaja vai kaksi suunniteltua instanssia
Jos käyttöönotto tarkoittaa yhtä palvelinta, pidä yksi elinkaaren omistaja ja lue kyseisen instanssin loki tai määritetty loki sen sijaan, että käynnistäisit toisen kopion sitä seuraamaan. Kun valvottu etualalla ajaminen on todella tarpeen, pysäytä hallittu instanssi tarkoituksellisesti ja ota ennen sitä huomioon asiakkaat, joita se palvelee.
Jos tarkoitetaan kahta instanssia, anna niille erilliset kuuntelijat ja erillinen kaikki muu: osoitealtaat, virtuaaliset liittymät, reitityskäytäntö ja kokoonpanon omistajuus. Pelkkä eri portti erottaa vain soketin, ja kaksi palvelinta kinastelee edelleen samasta altaasta ja samoista reiteistä.
Kolme oikotietä kannattaa nimetä, koska ne esiintyvät jokaisessa tätä virhettä koskevassa ketjussa. Älä tapa mielivaltaista PID:tä, joka näyttää syylliseltä. Älä ota soketin jakamista käyttöön viestin vaientamiseksi. Älä vaihda palvelinprofiilia asiakasmaiseen sitomattomaan kokoonpanoon, koska se saa sidontavirheen katoamaan; palvelimesta tulee saavuttamaton tavalla, jota on vaikeampi diagnosoida kuin alkuperäinen ristiriita.
Portin vaihtaminen on pätevä vastaus vain silloin, kun uusi kuuntelija on osa hyväksyttyä suunnittelua, joka sisältää välityssäännön ja asiakkaan päätepisteen. Jos niitä ei päivitetty, olet siirtänyt ristiriidan paikkaan, josta kukaan ei löydä sitä.
Varmista sidonta ennen kaikkea muuta
Rajallisen korjauksen jälkeen varmista, että tarkoitettu instanssi on aktiivinen, että sen kuuntelija näkyy odottamassasi kuljetuksessa ja että asiakas voi yhdistää. Onnistunut sidonta täydentää vain paikallisen soketin vaiheen; se ei todista mitään todennuksesta tai liikenteestä sen jälkeen, kun tunneli on pystyssä.
ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f
Jos soketti on olemassa ja asiakas epäonnistuu edelleen, jäljellä oleva ongelma on alavirrassa ja sidontavirhe on nyt historiaa. Juuri tämä erottelu on tarkan viestin ensin lukemisen koko pointti: yksi virhe, yksi kerros, yksi omistaja. Lue se niin, ja seuraava oire alkaa tunnetusta tilasta eikä arvauksesta.