Mida OpenVPN route-nopull tegelikult takistab serveril peale surumast
route-nopull viskab kõrvale pealesurutud marsruudid ja DHCP valikud, mitte käepigistuse. Valige selle, pull-filteri või mitte millegi vahel ja lisage marsruudid ise.
Pistsite route-nopull kliendiprofiili, et tunnel ei neelaks teie vaikemarsruuti, ja nüüd on kontori alamvõrk kättesaamatu, samal ajal kui klient ütleb endiselt, et on ühendatud. Mõlemad tähelepanekud on tõesed ja miski ei ebaõnnestunud. Lipp ütleb kliendile, et jätaks vahele serveri pealesurutud marsruudid ja DHCP-kirjed, mis on kitsam juhis, kui enamik inimesi selle lisamisel eeldab. Alles jääb töötav tunnel, millel pole arvamust selle kohta, millised sihtkohad peaksid seda kasutama.
See lünk ongi kogu otsus, millest see artikkel räägib. Kas server kirjeldab võrku või teeb seda klient, ja lipp annab selle töö kliendile, tehes teie eest sellest mitte midagi.
Mida lipp ühendamise hetkel välja lülitab
Tõmbav OpenVPN klient võtab tavaliselt pärast autentimist serverilt vastu paketi: marsruudid, vaikelüüsi ümbersuunamise, DNS-serverid ja paar häälestusdirektiivi. Kui route-nopull kehtib, võtab klient endiselt sessiooni vastu, kontrollib endiselt sertifikaate, läbiräägib endiselt šifreid ja keepalive’i ning tõstab endiselt liidese üles. See, mille ta kõrvale viskab, on pealesurutud route ridade ja pealesurutud dhcp-option ridade rakendamine, sealhulgas DNS.
Segadus tuleb rohelisest indikaatorist surnud rakenduse kõrval. Tunnel on olemas; sihtkohtade vastendus selle tunneliga mitte. Kliendi olekuribalt ei erista miski „ühendatud ja marsruudib“ olekut „ühendatud ja tegevusetu“ olekust, sest tunneli vaatenurgast on mõlemad sama olek.
Miks elav tunnel ei pruugi siiski midagi marsruutida
Liides ilmub oma aadressiga ja punkt-punkti ühendusel ei ole sageli midagi täpsemat kui hostmarsruut partnerini. Privaatne alamvõrk muutub kättesaadavaks alles siis, kui mõni marsruut osutab sellele liidesele õige eesliitega, ja väljalülitatud pealesurumise korral ei saabu see marsruut kunagi. Allalaaditud profiil ei aita tavaliselt samuti, sest see kirjutati eeldusel, et server annab täpselt selle teabe. Seetõttu võib liides tunduda terve, samal ajal kui alamvõrk jääb pimedaks.
Profiili lugemine tõestab seega väga vähe. Lugege selle asemel töötavat olekut ühendatud masinas:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10Aadress ilma alamvõrgu marsruudita teises käsus on selle probleemi allkiri. Kolmas käsk vastab seejärel küsimusele, mis kasutajaid tegelikult huvitab, sest see teatab liidese, mille kernel konkreetse sihtkoha jaoks valiks, mitte loendi, mida te lootsite kasutatavat. Kui see vastab füüsilise ühenduse kaudu, ei ole tunnel üldse teel.
Nimede lahendamine ebaõnnestub seotud põhjusel, mitte eraldi põhjusel. Pealesurutud dhcp-option DNS kirjed jäetakse sama lipuga vahele, nii et päringud sisemiste hostide kohta lähevad sellele lahendajale, mille kohalik võrk pakkus. Sellel lahendajal pole kontori jaoks tsooni, nii et päring ebaõnnestub või tagastab avaliku vastuse, ja tõrge näeb välja nagu serveri probleem, kuigi see on kliendi konfiguratsiooni probleem. Aadressi testimine enne nime on see, mis need kaks eristab.
Valik lipu ja eesliitefiltri vahel
Kaks valikut lahendavad sama kaebuse erinevaid kujusid ja halb valik on see, mis tekitab oleku ühendatud-kuid-kasutu. Üks asendab pealesurutud poliitika tervikuna, teine redigeerib seda eesliite kaupa. Tabel annab lühiversiooni ja selle järel olev lõik katab osa, mis inimesi tabab.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter on kolme verbiga eesliitesobitaja, seega saab see vastu võtta ridade pere, neid vaikselt eirata või ühenduse täielikult tagasi lükata, kui eesliide ilmub. Viimane käitumine on see, mida tasub teada: tagasilükkamisreegel muudab poliitikaerimeelsuse ebaõnnestunud käepigistuseks, mitte vaikseks väljajätmiseks. OpenVPN 2.6 käsiraamat loetleb aktsepteeritud eesliited ja iga verbi täpse semantika.
Levinud kesktee on lükata tagasi ainult redirect-gateway ja lasta kontori marsruutidel ja DNS-il saabuda kavatsetult. See hoiab pealesurumise töös nende osade jaoks, mida server mõistab paremini kui teie, ja takistab samal ajal seda ühte rida, mis võtaks üle teie vaikemarsruudi.
Marsruutide ja lahendaja käsitsi lisamine
Kui jätate lipu alles, peab profiil ütlema seda, mida server oleks öelnud. Kliendipoolsed route direktiivid rakendatakse pärast ühenduse loomist, nii et need töötavad lipu kõrval, mitte ei blokeerita selle poolt. Pange need profiili, mitte interaktiivsele käsureale, muidu ei taasta järgmine taasühendus töötavat olekut.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS-i rida on ebamugavas asendis: see on kliendipoolne direktiiv, kuid mõned kliendid rakendavad seda ainult platvormi DNS-integratsiooni kaudu, mis võib selle üle kirjutada, kui ühendus muutub. systemd-hostis on lahendaja otse tunneliliidesele seadmine prognoositavam kui lootmine, et klient võidab prioriteedivõistluse:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comMarsruutimisdomeen on sama oluline kui aadress. Ilma selleta võivad ka avalike nimede päringud minna sisemisele lahendajale ja iga sisemine lahendaja, mis keeldub rekursioonist, rikub sirvimise, jättes privaatse tsooni tööle. Sellega suunatakse tunnelilahendajale ainult selle sufiksi all olevad nimed ja kõik muu järgib füüsilist ühendust.
Tulemuse kontrollimine: aadress, nimi ja välimine tee
Kolm testi eristavad võimalikke tõrkeid. Hankige privaatne aadress IP järgi, seejärel sama host nime järgi, seejärel tavaline avalik sait. Töötav IP ebaõnnestuva nimega osutab lahendajale; ebaõnnestuv IP töötava nimega osutab marsruutimisele; mõlema ebaõnnestumine tähendab tavaliselt, et tunnel pole teel.
Seejärel vaadake välja, mitte sisse. Tunneli lõpp-punkti enda marsruut peab muudatuse üle elama ja iga blokeeriv tõrge peab piirduma tunneliga, ilma lõpp-punkti haarama. Klient, mis jätkab sirvimist pärast tunneli kukkumist, on poliitika, mitte marsruutimise probleem, ja see ei ilmne üheski kolmest ülalolevast testist.
Kirjutage lõplik loend profiili dokumentatsiooni: marsruudid, lahendaja, domeenid ja põhjus, miks igaüks eksisteerib. Taasühendus, mis taastoodab sama tabeli, on ainus tõend, et kohalik poliitika on täielik. Kui rakendused ikka ebaõnnestuvad, kui tunnel on üleval ja kõik kolm testi läbitud, on järgmine koht, kuhu vaadata, ühendatud-kuid-võrguühenduseta probleemide klass, mitte juba kontrollitud sertifikaadid.