Netgear OpenVPN: TUN och TAP lyssnar på olika portar

En telefon ansluter till routerns VPN utan klagomål, och en bärbar dator som använder en profil från samma nedladdningssida tar timeout. Inget med certifikaten ändrades mellan de två försöken, eftersom den bärbara datorn aldrig nådde punkten där certifikat spelar roll. Routern publicerar separata lyssnare för TUN och TAP, och en fungerande profil måste välja den som hör till dess egen enhetstyp.

Att avgöra vilket av tre möjliga fel som ska jagas är hela arbetet här: porten, enhetstypen eller förhandlingen av datakanalens chiffer.

Tre saker som måste stämma

Enhetstypen, profilens gränssnittsrad och lyssnarporten utgör ett val, inte tre. En profil som deklarerar dev tun och riktar sig mot TAP-lyssnaren kan inte slutföra sessionen, och det omvända misslyckas på samma sätt. För din modell och firmware, läs porten från routerns egen VPN-sida i stället för från en guide, eftersom numren flyttar sig mellan byggen. Skriv modell och firmwareversion bredvid numret så att nästa person kan verifiera det.

Rapporter från fältet nämner ett par som 12973 för TUN och 12974 för TAP på en firmware, och ett annat nummer på en annan. Läs dem som bevis på att byggen skiljer sig, inte som konstanter att kopiera. Profilen behöver sedan värdnamnet som passar avståndet: routerns dynamiska DNS-namn i stället för en WAN-adress som kommer att ändras.

Efter att ha rättat porten och gränssnittsraden ser profilen ut som en vanlig klientkonfiguration med en remote-rad och en dev-rad. Om de två inte stämmer ger ingen mängd upprepningar en session.

Läs loggen i den ordning den skrivs ut

En OpenVPN-klient rapporterar händelser i den ordning de inträffar, så den sista raden före tystnaden anger lagret som ska undersökas. När körningen slutar på TLS Error: TLS key negotiation failed, eller bara väntar på ett första svar och ger upp, skedde certifikatjämförelsen aldrig. Det pekar på nåbarhet, på lyssnaren eller på en port utan något bakom. Inget av detta repareras genom att byta ut CA-filen.

En körning som når VERIFY OK och sedan misslyckas ligger helt någon annanstans, med sina egna orsaker. Att skilja de två utfallen åt innan filer rörs förhindrar den klassiska omvägen genom certifikatbuntar som aldrig tillfrågades. När handskakningen är klar men tunneln inte kommer upp, titta på chifferförhandlingen i stället för nåbarhet.

Lägg till chifferlistan som en modern klient förväntar sig

Nyare OpenVPN-klienter vägrar äldre standardvärden som konsumentfirmware fortfarande erbjuder, och symptomet är ett förhandlingsfel direkt efter en lyckad handskakning. Rättelsen är en profilrad som namnger vad klienten accepterar: ställ in data-ciphers på AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 och AES-128-CBC i den ordningen. Varje algoritm som routern inte implementerar väljs helt enkelt aldrig, så en längre lista kostar inget annat än en något längre förhandling.

Att lista chiffer lär inte routern ett som den inte har. Om förhandlingen fortfarande misslyckas, kontrollera om routerns sida har en egen chifferinställning och om den inställningen innehåller minst en post som klienten accepterar. Två listor utan gemensam medlem ger exakt samma fel som en felaktig port, därför förtjänar båda ändarna en titt.

Importera en gång i stället för att redigera kopior för hand

Import av den rättade filen i NetworkManager undviker en mapp full av något olika profiler: nmcli connection import type openvpn file client.ovpn, och ta sedan upp den vid namn. Behåll den importerade profilen som den enda kopia du redigerar, och radera dubbletterna som samlas från upprepade nedladdningar.

Testa sedan utifrån LAN. Att ansluta från samma nätverk bevisar väldigt lite, eftersom trafiken kanske inte alls går genom tunneln. Bekräfta att en begäran faktiskt lämnar via routern, inte bara att klienten visar ett anslutet tillstånd.

Bestäm vad du ska göra med varningar

Konsumentfirmware präglar vanligtvis sin egen certifikatmyndighet, och klienter klagar på verifieringen på sätt som firmware inte kan undertrycka. Bedöm om det klagomålet spelar roll för det du skyddar i stället för att behandla varje varning som fatal, och stäng inte av verifieringen globalt för att tysta ett enda meddelande. En varning du har bedömt är en dokumenterad risk; en verifieringsinställning du har inaktiverat är en odokumenterad.

När firmware inte erbjuder något stött sätt att rätta en varning som verkligen spelar roll talar den luckan för att vara värd för VPN:et någon annanstans. Valet mellan att reparera profilen, acceptera varningen och flytta slutpunkten är ett beslut om hur mycket du litar på det certifikatet. Fatta det medvetet och skriv ned vilket alternativ du valde, i stället för att klicka genom dialoger tills ikonen blir grön.