OpenVPN redirect-gateway: mida iga lipp marsruutidega teeb

Ühendage profiilis redirect-gateway abil ja teie masina vaikimisi marsruut võib kaduda, kaheks jaguneda või jääda täpselt sinna, kus see oli, sõltuvalt lippudest, mida keegi kaks korda ei loe. Valik muudab ainult marsruutimise olekut ja mitte midagi muud, seega on ainus usaldusväärne tõend selle kohta, mida see tegi, tabel, mille klient pärast paigaldas. Järgneb tabel pärast ühendust, marsruut, mis hoiab tunneli enda elus, ja IPv6 liiklus, mida direktiiv ei väida kunagi katvat. Iga samm on käsk, mille saate kliendis käivitada, kui tunnel on üleval.

Mida iga lipp vaikimisi marsruudiga teeb

Ilma ühegi liputa eemaldab valik tavalise vaikimisi marsruudi ja asetab tunneli selle asemele, nii et vana lüüs kaob tabelist, kui ühendus on üleval. Lisage def1 ja see vaikimisi marsruut jääb loendisse, tööd teevad kaks kitsamat marsruuti. Lisage bypass-dhcp ja ka DHCP marsruut jääb alles, mis loeb võrgus, kus klient peab ikka veel kohalikku DHCP serverit saama. Lippude loend OpenVPN 2.6 käsiraamatu lehel on piisavalt lühike, et korra lugeda, ja iga kirje muudab, millised marsruudid tabelisse jõuavad.

Lükatud valik käitub saabudes samamoodi, seega võib kliendi profiil üldse mitte midagi sisaldada, samal ajal kui tabel näib täielikult ümber suunatud. See on normaalne: server saatis lipud, klient rakendas need ja kohalik fail ei maininud direktiivi kunagi. Kui tõuge näib mitte midagi tegevat, kontrollige kliendipoolset filtrit, mis tõmmatud valikud vastu võtab või ära viskab, sest ära visatud valik ei tekita kummaski otsas viga.

def1 võidab täpsusega teie vaikimisi marsruuti puutumata

Kaks poolikumat vaikimisi marsruuti katavad koos IPv4 ruumi, 0.0.0.0/1 ja 128.0.0.0/1. Kumbki on täpsem kui 0.0.0.0/0, seega eelistab otsing neid, samal ajal kui tegelik vaikimisi marsruut jääb tabelisse kõige vähem täpse vaste jaoks.

Lugege tabelit, mitte profiili, sest ainult tabel näitab, millises neist juhtudest te olete. Kahest reast piisab nende eristamiseks:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Pange tähele liidest ja mõõdikut igal real, mitte ainult sihtkohta. Tunnelile osutav vaikimisi marsruut ja tunnelile osutav paar poolikuid marsruute kirjeldavad sama kavatsust ja ebaõnnestuvad erinevalt, kui tunnel maha kukub, sest ühel juhul on varuvariant endiselt olemas. Kirjutage mõlemad väljad muudatuse märkmesse. Ellujäänud varuvariant hoiab mõnikord kaugsessiooni piisavalt kaua elus, et tunnel parandada, ja see on ka see, mis lekitab liiklust, kui kavatsus oli täis tunnel.

Hoidke tunneli lõpp-punkt kättesaadav

Klient vajab marsruuti tunneli kaugemasse otsa, mis ise läbi tunneli ei lähe. OpenVPN paigaldab selle hosti marsruudi enne, kui midagi muud muudab, ja käsitsi marsruudi muutmine või teine VPN klient võib selle ära võtta. Sümptom pärast seda on ühendus, mis teatab, et on ühendatud, ja siis ei lase midagi läbi.

Küsige tuumalt, millist liidest see lõpp-punkti aadressi jaoks kasutaks, kui tunnel on üleval. Vastus peab nimetama füüsilist liidest ja selle lüüsi, mitte kunagi tun0:

ip route get 198.51.100.20

Kui see otsing tagastab tunnelseadme, kannab tunnel oma transporti ja variseb kokku niipea, kui mõni pakett peab välja minema. Kohalikud prefiksid, teine adapter ja poliitikapõhine marsruutimine loevad siin endiselt, seetõttu võib puhtal sülearvutil töötav ümbersuunamine ebaõnnestuda hostis, kus on haldusliides ja kaks vaikimisi marsruuti. Tavaliselt süüdistatakse profiili selles, mida tegi aadressiplaan.

IPv6 liiklus kasutab edasi oma tabelit

IPv4 ümbersuunamine jätab IPv6 rahule ja kahte perekonda muudavad erinevad lipud. Kahe virna hostis, kus v6 vaikimisi marsruut töötab, võib v4 liiklus istuda täielikult tunneli sees, samal ajal kui iga v6-võimeline sihtkoht lahkub füüsilise lingi kaudu. Host, mis ühes tabelis õige välja näeb, lekitab teises.

Kontrollige v6 tabelit pärast ühendamist, selle asemel et eeldada, et tunnel kattis selle. Direktiiv kannab aadressiperekonna lippe just sel põhjusel ja profiil, mis need välja jätab, pärib selle, mida platvorm vaikimisi teeb:

ip -6 route show default
ip -6 route get 2001:db8::10

Tõestage, millist liidest rakendus kasutab

Ühendatud olek ei ole blokeering ja marsruudi muutmine ei ole hädaseiskamisklahv. Kui otsene liiklus peab tunneli rikke korral seiskuma, elab see poliitika tulemüüris ja vajab omaette katset.

Katsetage teed, mida rakendus tegelikult läbib, mitte teed, mida profiil kirjeldab. Küsige kõigepealt marsruuti, seejärel siduge päring kordamööda iga liidesega ja võrrelge, mida kaugem pool teatab:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Kui mõlemad päringud tagastavad sama aadressi, ei kasuta rakendus tunnelit, kuigi marsruutimistabel ütleb, et peaks. Kui õnnestub ainult tunneliga seotud päring, on füüsiline tee selle sihtkoha jaoks filtreeritud ja tunnel teeb seda, mida palusite. Kirjutage lipud, paigaldatud marsruudid, lõpp-punkti otsing ja mõlemad väljunditulemused muudatuste kirjesse, et järgmine inimene päriks faktid, mitte ekraanipildi.