OpenVPN redirect-gateway: čo každý prepínač robí s trasami

Pripojte sa s redirect-gateway v profile a predvolená trasa vášho počítača môže zmiznúť, rozdeliť sa na dve alebo zostať presne tam, kde bola, podľa prepínačov, ktoré nikto nečíta dvakrát. Voľba mení len stav smerovania a nič iné, takže jediným spoľahlivým dôkazom o tom, čo urobila, je tabuľka, ktorú klient potom nainštaloval. Nasleduje tabuľka po pripojení, trasa, ktorá udržiava tunel samotný nažive, a premávka IPv6, ktorú direktíva nikdy netvrdí, že pokrýva. Každý krok je príkaz, ktorý môžete spustiť na klientovi, kým je tunel aktívny.

Čo každý prepínač robí s predvolenou trasou

Bez akéhokoľvek prepínača voľba odstráni obvyklú predvolenú trasu a na jej miesto postaví tunel, takže stará brána zmizne z tabuľky, kým je spojenie aktívne. Pridajte def1 a tá predvolená trasa zostane v zozname, pričom prácu urobia dve užšie trasy. Pridajte bypass-dhcp a prežije aj trasa DHCP, čo je dôležité v sieti, kde sa klient ešte musí dostať na miestny server DHCP. Zoznam prepínačov na stránke manuálu OpenVPN 2.6 je dosť krátky na jedno prečítanie a každá položka mení, ktoré trasy skončia v tabuľke.

Zaslaná voľba sa po príchode správa rovnako, takže klientsky profil nemusí obsahovať nič, kým tabuľka vyzerá plne presmerovaná. To je normálne: server poslal prepínače, klient ich použil a miestny súbor direktívu nikdy nespomenul. Keď sa zdá, že push nič nerobí, skontrolujte filter na strane klienta, ktorý stiahnuté voľby prijíma alebo zahadzuje, pretože zahodená voľba nevyvolá chybu na žiadnej strane.

def1 vyhráva vďaka špecifickosti bez toho, aby sa dotkol vašej predvolenej trasy

Dve polovičné predvolené trasy spolu pokrývajú priestor IPv4, 0.0.0.0/1 a 128.0.0.0/1. Každá je konkrétnejšia ako 0.0.0.0/0, takže vyhľadávanie ich uprednostní, kým skutočná predvolená trasa zostáva v tabuľke pre všetko, čo žiada najmenej konkrétnu zhodu.

Čítajte tabuľku, nie profil, pretože len tabuľka ukazuje, v ktorom z týchto prípadov sa nachádzate. Na ich rozlíšenie stačia dva riadky:

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

Všímajte si rozhranie a metriku na každom riadku, nielen cieľ. Predvolená trasa ukazujúca do tunela a dvojica polovičných trás ukazujúcich do tunela opisujú rovnaký zámer a zlyhávajú inak, keď tunel padne, pretože v jednom prípade záložná cesta ešte existuje. Zapíšte obe polia do poznámky o zmene. Prežívajúca záložná cesta niekedy udrží vzdialenú reláciu nažive dosť dlho na opravu tunela a je to aj to, čo uniká premávke, keď bol zámerom plný tunel.

Udržujte koncový bod tunela dostupný

Klient potrebuje trasu k vzdialenému koncu tunela, ktorá sama nevedie tunelom. OpenVPN nainštaluje túto hostiteľskú trasu skôr, než zmení čokoľvek iné, a ručná úprava trás alebo druhý klient VPN ju môžu odstrániť. Príznakom potom je spojenie, ktoré hlási pripojenie a potom nič nepustí.

Opýtajte sa jadra, ktoré rozhranie by použilo pre adresu koncového bodu, kým je tunel aktívny. Odpoveď musí uviesť fyzické rozhranie a jeho bránu, nikdy tun0:

ip route get 198.51.100.20

Ak toto vyhľadávanie vráti zariadenie tunela, tunel nesie vlastnú dopravu a zrúti sa, len čo bude musieť nejaký paket odísť. Miestne prefixy, druhý adaptér a smerovanie podľa zásad tu stále hrajú rolu, a preto presmerovanie, ktoré funguje na čistom notebooku, môže zlyhať na hostiteľovi s rozhraním na správu a dvomi predvolenými trasami. Zvyčajne sa obviňuje profil z toho, čo urobil plán adries.

Premávka IPv6 naďalej používa vlastnú tabuľku

Presmerovanie IPv4 necháva IPv6 na pokoji a obe rodiny sa menia rôznymi prepínačmi. Na hostiteľovi s duálnym zásobníkom a funkčnou predvolenou trasou v6 môže premávka v4 sedieť celá v tuneli, kým každý cieľ schopný v6 odchádza cez fyzické rozhranie. Hostiteľ, ktorý vyzerá správne v jednej tabuľke, uniká v druhej.

Po pripojení skontrolujte tabuľku v6, namiesto toho, aby ste predpokladali, že ju tunel pokryl. Direktíva nesie prepínače rodiny adries práve preto a profil, ktorý ich vynechá, zdedí to, čo platforma robí predvolene:

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

Dokážte, ktoré rozhranie aplikácia používa

Stav pripojenia nie je blokovanie a zmena trasy nie je núdzový vypínač. Ak má priama premávka prestať, keď tunel zlyhá, táto zásada žije vo firewalle a potrebuje vlastný test.

Testujte cestu, ktorou aplikácia skutočne ide, nie cestu, ktorú opisuje profil. Najprv sa opýtajte na trasu, potom postupne pripnite požiadavku na každé rozhranie a porovnajte, čo hlási vzdialená strana:

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

Ak obe požiadavky vrátia rovnakú adresu, aplikácia tunel nepoužíva, hoci smerovacia tabuľka hovorí, že by mala. Ak uspeje len požiadavka viazaná na tunel, fyzická cesta je pre tento cieľ filtrovaná a tunel robí to, o čo ste požiadali. Zapíšte prepínače, nainštalované trasy, vyhľadanie koncového bodu a oba výsledky výstupu do záznamu o zmene, aby ďalší človek zdedil fakty namiesto snímky obrazovky.