Kāpēc vārdu meklēšana neizdodas maršrutētā OpenVPN tunelī

Resursdators atbild uz ping pēc adreses un neizdodas katrā meklēšanā pēc vārda. Tunelis ir aktīvs un maršruts pastāv, tāpēc dabiskais secinājums ir, ka VPN ir nepareizi konfigurēts. Noderīgāks secinājums ir, ka meklēšana nekad nav bijusi maršrutējama: maršrutēts tunelis pārvadā unicast IP, bet vaicājums bija apraide, kas meklēja segmentu, kura otrā pusē nav. Tiklīdz slāņu nesakritība kļūst redzama, labojumi paši sarindojas pēc izmaksām.

Mīts: tunelis ir salūzis, jo neizdodas vārdi

Simptoms ir pārliecinošs, jo viss virs vārdu slāņa darbojas. Adreses tiek maršrutētas, saskarne ir aktīva, un partneris atbild uz ping. Neizdevās atklāšanas mehānisms, kuram nekad nav bijis ceļa pāri punktu-punktu savienojumam, un tas ir cits apgalvojums nekā salūzis tunelis. Šo divu apgalvojumu šķiršana ir lielākā daļa no diagnozes.

Uztverot to kā tuneļa bojājumu, rodas profila izmaiņas, kas nevar palīdzēt. Opciju pievienošana, šifrēšanas maiņa vai klienta pārinstalēšana atstāj apraidi tieši tur, kur tā bija.

Nosauciet neizdevušos mehānismu pirms labojuma nosaukšanas. Meklēšanai ar apraidi vajag segmentu, bet meklēšanai ar risinātāju vajag adresi, kam pajautāt.

Ko TUN pārvadā un ko ne

TUN ierīce ir IP saskarne, un tieši tas padara to maršrutējamu. OpenVPN piešķir klientam adresi un maršrutu kopu, un no tā brīža klients sūta datagrammas partnerim. Nekas šajā modelī nerada kopīgu savienojumu, kur katrs resursdators dzird katru kadru.

Atklāšanas trafiks šajā modelī neiederas nemaz. Vecākas Windows vārdu vaicājumi, SSDP paziņojumi un mDNS pieprasījumi tiek sūtīti visiem segmentā, nevis vienai galamērķa vietai. Maršrutētam savienojumam nav neviena «visi», kam sūtīt. Katrs no šiem mehānismiem pieņem kopīgu vidi.

Tāpēc tunelis var būt vesels, kamēr atklāšana pilnībā neizdodas. Tieši pie šī teikuma jāturas, kad kāds ziņo, ka VPN ir nokritis.

Tiltošana darbojas, noņemot robežu

TAP ierīce pārvadā kadrus, un tilts to pievieno īstam LAN segmentam. Tad klientam ir adrese šajā segmentā, un tas dzird tā apraides trafiku. Tāpēc šķiet, ka tiltošana izārstē vārdu problēmu. Tā arī padara klientu atkarīgu no šī segmenta adresēšanā.

Ārstēšana ir maršrutēšanas robežas noņemšana, nevis kāda jauna vārdu spēja tuneļa iekšienē. Viss, ko segments apraida, tagad šķērso arī savienojumu.

Mazai laboratorijai tas ir godīgs maiņas darījums. Izkliedētam darbaspēkam — reti.

DNS un WINS iespiešana ir šaurākais labojums

Dodiet klientam konkrētu vietu, kur jautāt. dhcp-option DNS un dhcp-option DOMAIN novirza iekšējos vārdus uz serveri, kas zina zonu, un Windows klients, kas joprojām paļaujas uz NetBIOS, tāpat var saņemt WINS serveri. Tunelis paliek maršrutēts, un segments paliek savā vietā.

Divi nosacījumi izlemj, vai tas darbosies. Nosauktajam serverim jāatbild par zonu, un vaicājumam jābūt atļautam caur tuneli.

Pārbaudiet risinātāju no klienta, nevis no paša servera čaulas. Lokāli strādājošs risinātājs neko nepasaka par to, ko pārvadā tunelis.

Noskaidrojiet, kurš slānis neizdevās

Vispirms pingojiet adresi, tad atrisiniet vārdu un izlasiet, kurš serveris atbildēja. Servera, kas neuzņem zonu, noraidošā atbilde izskatās citādi nekā vaicājums, kas nekad nav atstājis mašīnu. Vārds, kas atrisinās, bet atsaka savienojumus, ir pavisam trešā problēma.

Multicast atrodas aiz tās pašas sienas. Grupa kā 224.0.0.251 pēc noklusējuma netiek pārsūtīta caur maršrutētu tuneli, un maršruts grupai nav pietiekams bez multicast saprotoša ceļa vai atstarotāja LAN tīklā.