Lokaal netwurk net berikber wylst de VPN ferbûn is? Fjouwer kontrôles

De tunnel komt omheech, it intranet ferskynt en de printer hâldt op mei antwurdzjen. Neat op it LAN is misgien; de klient hat it paad feroare dat er brûkt foar adressen dy't er net mear as lokaal beskôget. Gean de fjouwer kontrôles hjirûnder yn folchoarder troch en stopje as ien in konkreet ferskil jout, want itselde symptoom hat fjouwer algemiene oarsaken en mar ien dêrfan wurdt ferholpen troch de VPN te bewurkjen.

Earst, besjoch de rûtetabel dy't de klient ynstallearre hat

Iepenje de rûtetabel fan de klient wylst de VPN ferbûn is. Op Linux brûk ip route, op Windows route print of Get-NetRoute, en op macOS netstat -rn. Jo sykje in standertrûte troch de tunnel en wat der bard is mei de fysike standertrûte.

In folsleine-tunnelklient foeget faak twa heale standertrûtes ta, 0.0.0.0/1 en 128.0.0.0/1, ynstee fan 0.0.0.0/0 te ferfangen. De oarspronklike standertrûte bliuwt sichtber mar ferliest elke syktocht, dêrom kin de tabel yntakt lykje wylst alle ferkear bûten it subnet beweecht. As de VPN-klient in opsje foar splitstunnel biedt en it belied dat tastiet, is dat de skjinste reparaasje.

As de tunnel de standertrûte bliuwe moat, pin dan it lokale subnet fêst. Op Linux neamt de rûte de fysike interface en de gateway; op Windows foegje -p ta om it permanint te meitsjen en lês it interfacenûmer út route print ynstee fan it te rieden:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

In fêstpine rûte hâldt mar salang't it adres dat er neamt itselde bliuwt. In laptop dy't syn Wi-Fi-adapter by elke ferbining opnij nûmeret, sil de regel wer brekke, dus kontrolearje it interfaceadres foardat jo beslute dat de reparaasje mislearre is.

Twadde, befêstigje dat it adres fan it begjin ôf lokaal wie

As de bestimming yn it ferbûne subnet leit, jildt de standertrûte fan de tunnel nea en is de VPN net de oarsaak. In printer op 192.168.1.40 by in klient mei 192.168.1.0/24 brûkt de ferbûne rûte; as dat adres mislearret, sjoch dan nei it apparaat, de switch of de firewall op de klient ynstee fan de VPN.

It gefal dat minsken ferrifelt is in iepenbier adres foar in lokale server. Fan binnen it LAN freget it berikken fan it WAN-adres fan de router en weromkomme om hairpin-NAT, en in protte routers ymplementearje dat gewoan net foar portforwardings. Test it partikuliere adres njonken it iepenbiere. As it partikuliere adres wurket en it iepenbiere net, hat de VPN allinnich in NAT-beheining bleatlein dy't der al wie.

In hostnamme makket it slimmer. As de lokale namme no nei it iepenbiere adres resolvet, sil de klient besykje te hâlden mei it paad dat net weromkomme kin. Brûk it partikuliere adres foar de test en reparearje dan de namme ynstee fan noch in portforwarding ta te foegjen.

Tredde, sjoch wa't no antwurdet op nammen

In bedriuwsresolfer ken it intranet en wit meastentiids neat fan in NAS-hostnamme, de Bonjour-namme fan in printer of it lokale alias fan in router. As de VPN syn DNS-servers trochdrukt, hâlde dy nammen op mei resolven ek al binne har adressen noch berikber. Freegje de namme direkt op en fergelykje it antwurd mei it adres dat jo witte dat it apparaat hat.

Op Linux lit resolvectl query nas.local sjen hokker resolfer antwurde. Op Windows neamt nslookup nas.local de server, en ipconfig /all lit de folchoarder fan resolvers sjen. As it lokale suffiks no troch de bedriuwsresolfer hanthavene wurdt, stjoer dat suffiks dan werom nei de lokale resolfer of brûk it IP-adres fan it apparaat.

Untdekking is in aparte laach. mDNS en broadcast geane net troch in rûtearre tunnel, dus in apparaat kin berikber wêze fia adres wylst syn namme ûnsichtber bliuwt. In reflektor of in lokale DNS-ynfier lost dat op; in rûte net.

Fjirde, kontrolearje oft de oare masine ek op in VPN sit

As de masine dy't jo berikke wolle ek in VPN-klient draait, kin jo sesje oankomme wylst it antwurd troch de oare tunnel fuortgiet. Dat smyt in ferbining op dy't him festiget en dan fêstrint, of in RDP- en SSH-poging dy't ferrint sûnder flater oan jo kant. Kontrolearje de rûtetabel fan 'e oare host en syn standertpaad foardat jo jo klient de skuld jouwe.

Kontrolearje ek it adres dêr't de tsjinst op harket. In listener dy't allinnich oan it tunneladres bûn is, akseptearret ferbiningen fan 'e VPN en wegeret se fan it LAN, sels as rûtering perfekt is. Dat is tsjinstkonfiguraasje, gjin netwurkpaad, en it komt faak foar op behearynterfaces dy't op it VPN-adres fêstset waarden.

Hâld in behearpaad oan dat net fan de tunnel ôfhinget: in statyske rûte dy't jo boarnenetwurk neamt, in oare interface oan it LAN ferbûn, of in konsôle dy't de tunnel folslein omslút. Dat paad ûntwerpe nei't de sesje fuortfallen is, is folle dreger as it tafoegje foar de folgjende ferbining.

Pas de reparaasje ta dy't by de mislearre kontrôle past

As de rûtetabel in heale-standertkaping sjen liet, kies dan splitstunnel as it belied dat tastiet en in fêstpine lokale rûte as it dat net docht. As it adres iepenbier bliek te wêzen, skeakelje de test en de namme oer nei it partikuliere adres. As de resolfer fan hân feroare is, behein it lokale suffiks of brûk it adres. As de oare host tunnelisearre is, reparearje syn werompaad of syn listenerbining.

Feroarje ien ding, werhelje dan deselde kontrôle. In rûte taheakke foar it ferkearde subnet, in resolfer-suffiks mei in typflater en in fêstpine rûte op in interface dy't opnij nûmeret, lykje allegear op de oarspronklike stoaring. De werhelling is wat in reparaasje fan in tafal skiedt.

Skriuw de rûte, it adres en de resolfer op dy't wurken wylst de VPN ferbûn wie. De folgjende werferbining sil teminsten ien dêrfan feroarje, en de notysje makket de folgjende steuring in koarte fergeliking ynstee fan in nij ûndersyk.