Kaks VPN-klienti, üks marsruutimistabel: kes võidab vaikimisi marsruudi
Kaks VPN-klienti põrkuvad harva otse; nad kirjutavad üle sama vaikimisi marsruudi. Kontrollige valitud teekonda ja takistage seejärel ühel kliendil kõigi sihtkohtade hõivamist.
Tundub, nagu kakleks kaks VPN-klienti ühe pistiku pärast, ja ilmne parandus peaks olema ühe desinstallimine. Päriselt puutuvad nad sama pistikut harva. Iga ühendus kirjutab üle operatsioonisüsteemi marsruutimistabeli ja täistunneliprofiil hõivab vaikimisi marsruudi. Tavaliselt võidab see, kes ühendus viimasena, ja seetõttu näib sümptom klientide vahel liikuvat.
Konflikt elab marsruutimistabelis
Virtuaalne adapter pluss vaikimisi marsruut – nii haarab täistunnel liikluse. Kui teine klient paigaldab oma vaikimisi marsruudi, asendatakse vanem kirje või alandatakse seda mõõdiku järgi, ja iga sihtkoht liigub nüüd uuema tunneli kaudu. Esimene klient jääb ühendatuks ja näitab endiselt rohelist ikooni, seega liides on üleval, samal ajal kui tee on kadunud. Just see ühenduse oleku ja marsruutimise oleku eraldamine teeb käitumise segadust tekitavaks.
Kliendid on ühe ühise tabeli toimetajad. Teadmine, milline muudatus tehti viimasena, seletab peaaegu iga sümptomit.
Lugege, milline tunnel omab praegust teekonda
Kontrollige tegelikku otsust, selle asemel et usaldada klienti, mis teatab end ühendatuks. Küsige süsteemilt, milline liides kannaks konkreetset sihtkohta.
ip route get 10.20.0.5
route print -4Esimene käsk nimetab ühe sihtkoha jaoks liidese ja lähteaadressi, ja see on täpselt see küsimus, mis teid huvitab. Marsruutide väljund näitab Windowsis konkureerivaid vaikimisi kirjeid ja nende mõõdikuid, nii et näete, milline praegu võidab. Käivitage otsing iga kaugvõrgu hosti jaoks, sest üks sihtkoht võib olla õige, samal ajal kui teine võrk on kättesaamatu. Kui vastus nimetab vale tunnelit, ei aita uuesti ühendamine; marsruudipoliitikat tuleb muuta.
Takistage teist klienti kõike hõivamast
Üks klient peaks omama vaikimisi marsruuti ja teine kandma ainult oma prefikseid. OpenVPN kliendid saavad keelduda sellest, mida server peale surub.
pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10route-nopull eirab iga peale surutud marsruuti, samal ajal kui pull-filter ignore "redirect-gateway" jätab kõrvale ainult vaikimisi marsruudi direktiivi ning säilitab peale surutud DNS-i ja muud valikud. Valige nende vahel selle järgi, kui palju serveri konfiguratsiooni te veel soovite, ja lisage seejärel konkreetsed prefiksid, mida teine võrk vajab. Pidage meeles DNS-i, sest resolver, mille tunnel peale surub, kuid mis päringuid ei kanna, ei tagasta midagi. Katsetage ühte tuntud hosti igas võrgus ja kinnitage lähteaadress, mida kaugpool näeb.
Kattuvatest alamvõrkudest ei saa mööda minna
Kui mõlemad võrgud avaldavad sama prefiksi, hoiab kernel ühte kirjet kahe erineva koha jaoks ja peab valima. Hostimarsruut ei saa puuduvat eristust välja mõelda ega ka mõõdiku kohandamine. Nummerdage üks pool ümber või laske selle administraatoril kaugvahemik tõlkida, et prefiksid erineksid. Kontrollige tegelikke alamvõrke enne, kui kliente süüdistate, sest koduruuteri vaikimisi 192.168.1.0/24 põrkub kontorivahemikuga sagedamini, kui keegi ootab. Kirjutage mõlemad vahemikud piletisse, et järgmine muudatus kattuvust uuesti ei looks.
Eraldage ka kaks eesmärki: mõlemasse võrku jõudmine on marsruutimise probleem, samal ajal kui tunnelite aheldamine privaatsuse huvides on teine lahendus, kus teekonnal on veel üks operaator. Ärge kasutage ühte, et lahendada teist.