Kodėl vardų paieška nepavyksta per maršrutizuotą OpenVPN tunelį

Mazgas atsako į ping pagal adresą, o kiekviena paieška pagal vardą nepavyksta. Tunelis veikia ir maršrutas egzistuoja, todėl natūrali išvada — VPN sukonfigūruotas neteisingai. Naudingesnė išvada: paieška niekada nebuvo maršrutizuojama, nes maršrutizuotas tunelis perduoda unicast IP, o užklausa buvo transliacija, ieškojusi segmento, kurio kitoje pusėje nėra. Kai sluoksnių neatitikimas tampa matomas, sprendimai patys išsirikiuoja pagal kainą.

Mitas: tunelis sugedęs, nes nepavyksta vardai

Simptomas įtikinamas, nes viskas aukščiau vardų sluoksnio veikia. Adresai maršrutizuojami, sąsaja veikia, o partneris atsako į ping. Nepavyko aptikimo mechanizmas, kuris niekada neturėjo kelio per taškas-taškas jungtį, ir tai kitas teiginys nei sugedęs tunelis. Šių dviejų teiginių atskyrimas yra didžioji diagnozės dalis.

Traktuojant tai kaip tunelio gedimą, atsiranda profilio pakeitimai, kurie negali padėti. Parinkčių pridėjimas, šifravimo keitimas ar kliento perinstaliavimas palieka transliaciją tiksliai ten, kur ji buvo.

Įvardykite nepavykusį mechanizmą prieš įvardydami sprendimą. Paieška, naudojanti transliaciją, reikalauja segmento, o paieška, naudojanti resolverį, reikalauja adreso, kurio paklausti.

Ką TUN perduoda, o ko ne

TUN įrenginys yra IP sąsaja, ir būtent tai daro jį maršrutizuojamu. OpenVPN duoda klientui adresą ir maršrutų rinkinį, o nuo to laiko klientas siunčia datagramas partneriui. Niekas tame modelyje nesukuria bendros jungties, kur kiekvienas mazgas girdi kiekvieną kadrą.

Aptikimo srautas visiškai netelpa į tą modelį. Senesnės Windows vardų užklausos, SSDP pranešimai ir mDNS prašymai siunčiami visiems segmente, o ne vienai paskirties vietai. Maršrutizuota jungtis neturi jokio „visi“, kam siųsti. Kiekvienas iš tų mechanizmų numato bendrą terpę.

Todėl tunelis gali būti sveikas, kol aptikimas visiškai nepavyksta. Būtent šios frazės reikia laikytis, kai kas nors praneša, kad VPN neveikia.

Sąsaja veikia panaikindama ribą

TAP įrenginys perduoda kadrus, o tiltas prijungia jį prie tikro LAN segmento. Tada klientas turi adresą tame segmente ir girdi jo transliavimo srautą. Štai kodėl atrodo, kad sąsaja išgydo vardų problemą. Ji taip pat padaro klientą priklausomą nuo to segmento adresavimui.

Išgydymas yra maršrutizavimo ribos panaikinimas, o ne kokia nors nauja vardų galimybė tunelio viduje. Viskas, ką segmentas transliuoja, dabar kerta ir jungtį.

Mažai laboratorijai tai sąžininga mainais. Paskirstytai darbo jėgai — retai.

DNS ir WINS įstūmimas yra siauresnis taisymas

Duokite klientui konkrečią vietą klausti. dhcp-option DNS ir dhcp-option DOMAIN nukreipia vidinius vardus į serverį, kuris pažįsta zoną, o Windows klientas, vis dar pasikliaujantis NetBIOS, tuo pačiu būdu gali gauti WINS serverį. Tunelis lieka maršrutizuotas, o segmentas lieka savo vietoje.

Du sąlygos lemia, ar tai veiks. Nurodytas serveris turi atsakyti už zoną, o užklausa turi būti leidžiama per tunelį.

Testuokite resolverį iš kliento, o ne iš paties serverio apvalkalo. Vietoje veikiantis resolveris nieko nesako apie tai, ką perduoda tunelis.

Išsiaiškinkite, kuris sluoksnis nepavyko

Pirmiausia pinginkite adresą, tada išspręskite vardą ir perskaitykite, kuris serveris atsakė. Neigiamas atsakymas iš serverio, kuris nehostina zonos, atrodo kitaip nei užklausa, kuri niekada neišėjo iš mašinos. Vardas, kuris išsprendžiamas, bet atmeta ryšius, yra visiškai trečia problema.

Multicast yra už tos pačios sienos. Grupė kaip 224.0.0.251 pagal nutylėjimą nepersiunčiama per maršrutizuotą tunelį, o grupės maršrutas nepakanka be multicastą suprantančio kelio ar atšvaito LAN tinkle.