VPN-poort stil? Listener, bindadres of firewall van de host

De VPN antwoordt niets op zijn poort, en de twee mogelijke oorzaken vragen om tegengestelde reparaties: ofwel heeft geen enkel proces de socket geopend, ofwel bestaat de socket en houdt iets tussen de machines de pakketten tegen. Eén commando beslecht de eerste helft van die vraag, daarom hoort het vóór elke firewallregel. De volgorde hieronder haalt per stap één verklaring weg in plaats van nog een vermoeden toe te voegen. Juist het gokken tussen de twee maakt van een diagnose van tien minuten een hele avond.

Ga ervan uit dat je op de server kunt inloggen en dat de client een echt profiel is en geen scanner. Beide aannames tellen, want een algemene probe kan een protocolspecifieke vraag niet beantwoorden.

Bestaat de socket überhaupt

Begin met wat de dienst over zichzelf zegt: of hij opkwam en, nuttiger, wat de eerste opstartfout was. Een parsefout, een ontbrekende sleutel of een bindfout verhindert dat de listener ooit bestaat, en het proces kan zo stil eindigen dat een statusregel dubbelzinnig leest. Een unit die actief meldt is op zichzelf geen bewijs, want het hoofdproces kan leven terwijl de component die de poort moest binden al heeft opgegeven.

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

De socketlijst is het feit waarop de rest van de diagnose rust. Lees de kolom van het lokale adres en niet alleen de poort, want in die kolom verschijnen loopback-binds en binds op de verkeerde interface. Een listener die op 127.0.0.1 bestaat draait perfect en blijft toch onzichtbaar voor je laptop.

Op welk adres en welke familie de socket antwoordt

Twee fouten zien er vanaf de client hetzelfde uit en verklaren de meeste meldingen "niet bereikbaar". Een server die aan het loopbackadres is gebonden, accepteert nooit verkeer van een andere machine, en een server die alleen aan een IPv4-adres is gebonden, antwoordt nooit een client die het IPv6-adres van dezelfde host kiest. Vergelijk het adres in de sockettabel teken voor teken met het adres dat de client werkelijk kiest, voordat je iets over beleid aanneemt.

De lijst tot één poort beperken houdt hem leesbaar wanneer de host meerdere diensten draait. Het sport-filter neemt de poort samen met het transport dat je test:

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

De protocolkolom verandert het hele antwoord

De sockettabel sleutelt op protocol én op poort, en dat zijn twee onafhankelijke regels. Een dienst die op 1194 TCP antwoordt, zegt niets over of er iets op UDP 1194 luistert, en de client gebruikt altijd maar één van beide. Controleer welk transport de serverconfiguratie kiest en welke het clientprofiel stuurt, en zoek dan precies die regel.

UDP heeft een tweede kneep: een niet-geauthenticeerde probe is geen fout die de dienst moet beantwoorden. Een scan die de poort als stil meldt, heeft de terughoudendheid van de dienst gemeten, niet zijn beschikbaarheid, dus test met de echte client en het echte profiel.

Eén poging, drie plekken om te kijken

Doe vanaf een goedgekeurde client precies één poging en noteer de tijd tot op de seconde. Lees daarna drie bronnen voor dat venster: de netwerkregel of console van de provider, de firewallellers of het log van de host, en het eigen log van de dienst. Het één keer doen maakt de drie verslagen vergelijkbaar, en het kost minder dan een poging herhalen waarvan niemand de tijdstempel noteerde.

De twee uitkomsten wijzen in tegengestelde richtingen. Als er geen pakket de host bereikte, laat het pad het vallen en is de listener irrelevant. Als het pakket bij de socket aankwam en de dienst het weigerde, is het pad in orde en ligt het antwoord in protocol, cryptografie of inloggegevens. Een poort openen voor een dienst die al een verbinding heeft geaccepteerd, maakt de volgende diagnose moeilijker, niet makkelijker.

Noem de fase voordat je een regel wijzigt

Een onderhandeling die begint en een authenticatie die faalt is één storing, en een tunnel die tot stand komt terwijl de doorsturing stokt is een heel andere. De fase eerst benoemen houdt de reparatie smal: een probleem met inloggegevens los je niet op met een firewallregel, en een probleem met het datapad niet met een herstart.

Gebruik de smalste diagnose die de vraag beantwoordt. Een tijdelijke pakketobservatie op één poort, onder beheer van een administrator, is een redelijk instrument; de hele firewall uitschakelen niet, omdat het resultaat dan niet meer toe te schrijven is. De ss-documentatie behandelt de hierboven gebruikte filters, en dat is een goedkopere eerste stap dan welke capture dan ook. Noteer welke van de twee takken je hebt bewezen, en de volgende keer begint bij een bekend antwoord.