Zašto pretrage imena propadaju kroz rutiranu OpenVPN tunel

Domaćin odgovara na ping po adresi, a svaka pretraga po imenu propada. Tunel je podignut i ruta postoji, pa je prirodan zaključak da je VPN pogrešno konfigurisan. Korisniji zaključak je da pretraga nikada nije bila rutabilna: rutirani tunel nosi unicast IP, dok je dotični upit bio broadcast koji traži segment koji ne postoji na drugoj strani. Kad nesklad slojeva postane vidljiv, rješenja se sama poređaju po cijeni.

Mit: tunel je pokvaren jer imena ne rade

Simptom je uvjerljiv jer sve iznad sloja imena radi. Adrese se rutiraju, interfejs je podignut, a peer odgovara na ping. Propalo je otkrivanje koje nikada nije imalo put preko tačka-na-tačku veze, i to je druga tvrdnja od pokvarenog tunela. Razdvajanje te dvije tvrdnje je veći dio dijagnoze.

Ako se to tretira kao kvar tunela, dolazi se do izmjena profila koje ne mogu pomoći. Dodavanje opcija, mijenjanje šifre ili ponovna instalacija klijenta ostavlja broadcast tačno tamo gdje je bio.

Imenujte mehanizam koji je propao prije nego imenujete popravku. Pretraga koja koristi broadcast treba segment, dok pretraga koja koristi resolver treba adresu koju može pitati.

Šta TUN nosi, a šta ne

TUN uređaj je IP interfejs i upravo to ga čini rutabilnim. OpenVPN daje klijentu adresu i skup ruta, a od tada klijent šalje datagrame peeru. Ništa u tom modelu ne stvara dijeljeni link na kojem svaki domaćin čuje svaki okvir.

Saobraćaj otkrivanja nikako se ne uklapa u taj model. Stariji Windows upiti za imena, SSDP najave i mDNS zahtjevi šalju se svima na segmentu, a ne jednoj destinaciji. Rutirana veza nema «sve» kojima bi poslala. Svaki od tih mehanizama pretpostavlja dijeljeni medij.

Tunel zato može biti zdrav dok otkrivanje potpuno propada. Te se rečenice treba držati kad neko prijavi da je VPN pao.

Premošćavanje radi tako što uklanja granicu

TAP uređaj nosi okvire, a most ga priključuje na stvarni LAN segment. Klijent tada drži adresu na tom segmentu i čuje njegov broadcast saobraćaj. Zato premošćavanje izgleda kao lijek za problem imena. Ono i čini klijenta zavisnim od tog segmenta za adresiranje.

Lijek je uklanjanje rutne granice, a ne nova sposobnost imenovanja unutar tunela. Sve što segment emituje sada takođe prelazi vezu.

Za malu laboratoriju to je poštena razmjena. Za raspršenu radnu snagu rijetko je.

Guranje DNS-a i WINS-a je uža popravka

Dajte klijentu konkretno mjesto za pitanje. dhcp-option DNS i dhcp-option DOMAIN usmjeravaju interna imena na server koji poznaje zonu, a Windows klijent koji se još oslanja na NetBIOS može na isti način dobiti WINS server. Tunel ostaje rutiran, a segment ostaje gdje pripada.

Dva uslova odlučuju hoće li to raditi. Navedeni server mora odgovarati za zonu, a upit mora biti dozvoljen kroz tunel.

Testirajte resolver sa klijenta, a ne iz serverove vlastite ljuske. Resolver koji radi lokalno ne govori ništa o tome šta tunel nosi.

Saznajte koji je sloj propao

Prvo pingajte adresu, zatim razriješite ime i pročitajte koji je server odgovorio. Negativan odgovor servera koji ne hostuje zonu izgleda drukčije od upita koji nikada nije napustio mašinu. Ime koje se razrješava ali odbija veze sasvim je treći problem.

Multicast stoji iza istog zida. Grupa poput 224.0.0.251 ne prosljeđuje se preko rutiranog tunela po defaultu, a ruta za grupu nije dovoljna bez multicast-osviještenog puta ili reflektora na LAN-u.