Varför namnuppslag misslyckas över en routad OpenVPN-tunnel

En värd svarar på ping via adressen och misslyckas med varje sökning på namn. Tunneln är uppe och vägen finns, så den naturliga slutsatsen är att VPN:en är felkonfigurerad. En mer användbar slutsats är att sökningen aldrig var routbar: en routad tunnel bär unicast-IP, medan frågan var en broadcast som letade efter ett segment som inte finns på andra sidan. När lageravvikelsen är synlig sorterar lösningarna sig själva efter kostnad.

Myt: tunneln är trasig eftersom namn misslyckas

Symtomet är övertygande eftersom allt ovanför namflagret fungerar. Adresser routas, gränssnittet är uppe och motparten svarar på ping. Det som misslyckades är en upptäcktsmekanism som aldrig hade en väg över en punkt-till-punkt-förbindelse, och det är ett annat påstående än en trasig tunnel. Att skilja de två påståendena är det mesta av diagnosen.

Behandlas det som ett tunnelfel leder det till profiländringar som inte kan hjälpa. Att lägga till alternativ, byta kryptering eller installera om klienten lämnar broadcasten precis där den var.

Namnge mekanismen som misslyckades innan du namnger åtgärden. En sökning som använder broadcast behöver ett segment, medan en sökning som använder en resolver behöver en adress att fråga.

Vad TUN bär och inte bär

En TUN-enhet är ett IP-gränssnitt, och det är vad som gör den routbar. OpenVPN ger klienten en adress och en uppsättning rutter, och därifrån skickar klienten datagram till en motpart. Ingenting i den modellen skapar en delad förbindelse där varje värd hör varje ram.

Trafiken för upptäckt passar inte alls i den modellen. Äldre Windows-namnförfrågningar, SSDP-tillkännagivanden och mDNS-begäran skickas till alla på ett segment i stället för till en enda destination. En routad förbindelse har ingen «alla» att skicka till. Var och en av dessa mekanismer förutsätter ett delat medium.

Tunneln kan därför vara frisk medan upptäckten misslyckas helt. Det är den meningen man ska hålla fast vid när någon rapporterar att VPN:en ligger nere.

Bryggning fungerar genom att ta bort gränsen

En TAP-enhet bär ramar, och en brygga kopplar den till ett verkligt LAN-segment. Klienten har då en adress på det segmentet och hör dess broadcasttrafik. Därför verkar bryggning bota namnproblemet. Det gör också klienten beroende av segmentet för adressering.

Boten är att ta bort routinggränsen, inte någon ny namnförmåga inuti tunneln. Allt segmentet broadcastar passerar nu också förbindelsen.

För ett litet labb är det en rimlig byteshandel. Över en spridd personalstyrka är det sällan det.

Att skjuta ut DNS och WINS är den smalare reparationen

Ge klienten en bestämd plats att fråga. dhcp-option DNS och dhcp-option DOMAIN pekar interna namn mot en server som känner zonen, och en Windows-klient som fortfarande förlitar sig på NetBIOS kan få en WINS-server på samma sätt. Tunneln förblir routad och segmentet stannar där det hör hemma.

Två villkor avgör om det fungerar. Den namngivna servern måste svara för zonen, och frågan måste vara tillåten genom tunneln.

Testa resolvern från klienten och inte från serverns eget skal. En resolver som fungerar lokalt säger ingenting om vad tunneln bär.

Ta reda på vilket lager som misslyckades

Pinga adressen först, lös sedan upp namnet och läs vilken server som svarade. Ett negativt svar från en server som inte är värd för zonen ser annorlunda ut än en fråga som aldrig lämnade maskinen. Ett namn som löses upp men nekar anslutningar är ett helt tredje problem.

Multicast står bakom samma vägg. En grupp som 224.0.0.251 vidarebefordras inte över en routad tunnel som standard, och en rutt för gruppen räcker inte utan en multicast-medveten väg eller en reflektor på LAN:et.