VPN-portti hiljaa? Kuuntelija, sidontaosoite vai isäntäkoneen palomuuri

VPN ei vastaa portillaan mitään, ja kaksi mahdollista syytä vaativat vastakkaiset korjaukset: joko mikään prosessi ei avannut socketia tai socket on olemassa ja jokin koneiden välissä pysäyttää paketit. Yksi komento ratkaisee tämän kysymyksen ensimmäisen puoliskon, siksi se tulee ennen kuin mihinkään palomuurisääntöön kosketaan. Alla oleva järjestys poistaa yhden selityksen vaiheelta sen sijaan että lisäisi uuden arvauksen. Juuri kahden välillä arvaaminen muuttaa kymmenen minuutin diagnoosin koko illaksi.

Oleta, että voit kirjautua palvelimelle ja että asiakas on oikea profiili eikä skanneri. Molemmat oletukset ovat tärkeitä, koska yleinen luotain ei voi vastata protokollakohtaiseen kysymykseen.

Onko socketia ylipäätään olemassa

Aloita siitä, mitä palvelu itse kertoo itsestään: nousiko se ja, hyödyllisempää, mikä oli sen ensimmäinen käynnistysvirhe. Jäsennyksen epäonnistuminen, puuttuva avain tai sidontavirhe estävät kuuntelijaa syntymästä lainkaan, ja prosessi voi poistua niin hiljaa, että tilannerivi luetaan monitulkintaisesti. Yksikkö, joka ilmoittaa olevansa aktiivinen, ei ole yksinään todiste, koska pääprosessi voi olla elossa samalla kun portin sitonut komponentti on jo luovuttanut.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Sockets-luettelo on se tosiasia, jonka varassa muu diagnoosi lepää. Lue paikallisen osoitteen sarake eikä vain porttia, koska juuri siinä sarakkeessa loopback-sidonnat ja väärän rajapinnan sidonnat näkyvät. Kuuntelija, joka on olemassa osoitteessa 127.0.0.1, toimii moitteettomasti ja on silti näkymätön kannettavallesi.

Millä osoitteella ja osoiteperheellä socket vastaa

Kaksi virhettä näyttävät asiakkaan puolelta samoilta ja selittävät suurimman osan "ei tavoitettavissa" -raporteista. Loopback-osoitteeseen sidottu palvelin ei koskaan ota vastaan liikennettä toisesta koneesta, ja vain IPv4-osoitteeseen sidottu palvelin ei koskaan vastaa asiakkaalle, joka valitsee saman isännän IPv6-osoitteen. Vertaa socket-taulukon osoitetta osoitteeseen, jonka asiakas todella valitsee, merkki merkiltä, ennen kuin oletat mitään käytännöistä.

Luettelon rajaaminen yhteen porttiin pitää sen luettavana, kun isäntä ajaa useita palveluita. sport-suodatin ottaa portin yhdessä testaamasi kuljetuksen kanssa:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Protokollasarake muuttaa koko vastauksen

Socket-taulukko indeksoituu sekä protokollan että portin mukaan, ja ne ovat kaksi erillistä merkintää. Palvelu, joka vastaa TCP:hen portissa 1194, ei kerro mitään siitä, kuunteleeko jokin UDP-portissa 1194, ja asiakas käyttää aina vain toista niistä. Varmista, minkä kuljetuksen palvelimen kokoonpano valitsee ja minkä asiakasprofiili lähettää, ja etsi sitten juuri se rivi.

UDP:ssä on toinen käänne: todentamaton luotain ei ole virhe, johon palvelun täytyy vastata. Skannaus, joka ilmoittaa portin hiljaiseksi, on mitannut palvelun harkintaa, ei sen saatavuutta, joten testaa oikealla asiakkaalla ja profiililla.

Yksi yritys, kolme paikkaa katsoa

Tee hyväksytystä asiakkaasta täsmälleen yksi yritys ja kirjaa aika sekunnin tarkkuudella. Lue sitten kolme lähdettä tuolle aikaikkunalle: palveluntarjoajan verkkosääntö tai konsoli, isännän palomuurilaskurit tai loki ja palvelun oma loki. Kertatekeminen tekee kolmesta kertomuksesta vertailukelpoisia, ja se maksaa vähemmän kuin yrityksen toistaminen, jonka aikaleimaa kukaan ei kirjannut.

Kaksi lopputulosta osoittavat vastakkaisiin suuntiin. Jos yksikään paketti ei saavuttanut isäntää, polku pudottaa sen ja kuuntelija on merkityksetön. Jos paketti saapui socketiin ja palvelu hylkäsi sen, polku on kunnossa ja vastaus on protokollassa, salauksessa tai tunnuksissa. Portin avaaminen palvelulle, joka on jo hyväksynyt yhteyden, tekee seuraavasta diagnoosista vaikeampaa, ei helpompaa.

Nimeä vaihe ennen kuin muutat sääntöä

Alkava neuvottelu ja epäonnistuva todennus ovat yksi vika, ja tunneli, joka muodostuu samalla kun välitys jumittuu, on täysin toinen. Vaiheen nimeäminen ensin pitää korjauksen kapeana: tunnusongelmaa ei korjata palomuurisäännöllä eikä datapolun ongelmaa uudelleenkäynnistyksellä.

Käytä kapeinta diagnoosia, joka vastaa kysymykseen. Tilapäinen pakettien tarkkailu yhdellä portilla järjestelmänvalvojan valvonnassa on järkevä väline; koko palomuurin sammuttaminen ei ole, koska tulosta on mahdotonta kohdistaa. ss:n dokumentaatio kattaa yllä käytetyt suodattimet, ja se on halvempi ensiaskel kuin mikään kaappaus. Kirjaa, kumman kahdesta haarasta todistit, ja seuraava tapaus alkaa tunnetusta vastauksesta.