VPN-porten tyst? Lyssnare, bind-adress eller värdens brandvägg

En stoppad tjänst och ett brandväggsdrop kräver olika reparationer. Undersök den lokala socketen först och korrelera sedan ett auktoriserat externt försök med loggen.

VPN:et svarar ingenting på sin port, och de två möjliga orsakerna kräver motsatta reparationer: antingen öppnade ingen process socketen, eller så finns socketen och något mellan maskinerna stoppar paketen. Ett enda kommando avgör den första halvan av den frågan, därför hör det hemma före någon brandväggsregel. Ordningen nedan tar bort en förklaring per steg i stället för att lägga till ännu en gissning. Det är gissningen mellan de två som gör en tiominutersdiagnos till en hel kväll.

Anta att du kan logga in på servern och att klienten är en riktig profil och inte en skanner. Båda antagandena spelar roll, för en allmän sond kan inte svara på en protokollspecifik fråga.

Finns socketen överhuvudtaget

Börja med vad tjänsten säger om sig själv: om den kom upp och, mer användbart, vad dess första startfel var. Ett parsningsfel, en saknad nyckel eller ett bindfel hindrar lyssnaren från att uppstå, och processen kan avsluta så tyst att statusraden läses tvetydigt. En enhet som rapporterar aktiv är inte bevis i sig, för huvudprocessen kan leva medan komponenten som skulle binda porten redan har gett upp.

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

Socketlistan är det faktum som resten av diagnostiken vilar på. Läs kolumnen för den lokala adressen och inte bara porten, för det är i den kolumnen loopback-bindningar och bindningar till fel gränssnitt dyker upp. En lyssnare som finns på 127.0.0.1 körs perfekt och är fortfarande osynlig för din laptop.

Vilken adress och familj socketen svarar på

Två fel ser likadana ut från klienten och förklarar de flesta "inte nåbar"-rapporterna. En server bunden till loopback-adressen accepterar aldrig trafik från en annan maskin, och en server bunden endast till en IPv4-adress svarar aldrig en klient som ringer upp IPv6-adressen för samma värd. Jämför adressen i sockettabellen med adressen klienten faktiskt ringer upp, tecken för tecken, innan du antar något om policy.

Att begränsa listan till en port håller den läsbar när värden kör flera tjänster. sport-filtret tar porten tillsammans med transporten du testar:

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

Protokollkolumnen ändrar hela svaret

Sockettabellen indexeras både på protokoll och port, och det är två oberoende poster. En tjänst som svarar TCP på 1194 säger ingenting om huruvida något lyssnar på UDP 1194, och klienten använder alltid bara en av dem. Bekräfta vilken transport serverkonfigurationen väljer och vilken klientprofilen skickar, och leta sedan efter exakt den raden.

UDP har ett andra veck: en oautentiserad sond är inte ett fel som tjänsten måste svara på. En skanning som rapporterar porten som tyst har mätt tjänstens diskretion, inte dess tillgänglighet, så testa med den riktiga klienten och profilen.

Ett försök, tre ställen att titta på

Gör från en godkänd klient exakt ett försök och skriv ned tiden till sekunden. Läs sedan tre källor för det fönstret: leverantörens nätverksregel eller konsol, värdens brandväggsräknare eller logg och tjänstens egen logg. Att göra detta en gång är det som gör de tre berättelserna jämförbara, och det kostar mindre än att upprepa ett försök vars tidsstämpel ingen skrev ned.

De två utfallen pekar i motsatta riktningar. Om inget paket nådde värden släpper vägen det, och lyssnaren är irrelevant. Om paketet nådde socketen och tjänsten avvisade det är vägen i ordning och svaret ligger i protokoll, kryptografi eller inloggningsuppgifter. Att öppna en port för en tjänst som redan accepterat en anslutning gör nästa diagnos svårare, inte lättare.

Namnge fasen innan du ändrar en regel

Förhandling som börjar och autentisering som misslyckas är ett fel, och en tunnel som etableras medan vidarebefordran stannar är ett helt annat. Att namnge fasen först håller reparationen smal: ett problem med inloggningsuppgifter löses inte av en brandväggsregel, och ett problem med datavägen löses inte av en omstart.

Använd den smalaste diagnosen som svarar på frågan. En tillfällig paketobservation på en port, under en administratörs kontroll, är ett rimligt instrument; att stänga av hela brandväggen är det inte, eftersom resultatet blir omöjligt att tillskriva. ss-dokumentationen täcker filtren som används ovan, och det är ett billigare första steg än någon avlyssning. Anteckna vilken av de två grenarna du bevisade, och nästa förekomst börjar från ett känt svar.

Relaterade artiklar