LAN router a VPN klient: dve zariadenia, dve smerovacie tabuľky

Dve zariadenia preposielajú paket a každé si drží vlastnú tabuľku. LAN router vie, že vzdialený prefix patrí VPN klientovi, a VPN klient vie, ako sa k tomu prefixu dostať cez svoj tunel. Nakonfigurujte len prvú tabuľku a paket dorazí k stroju, ktorý nemá zodpovedajúcu trasu, takže znova odíde cez predvolenú trasu. To je celá porucha a z pohľadu LAN to vyzerá ako smerovacia slučka, pretože takmer je.

Nakreslite oba skoky, než sa dotknete trasy

Vezmite ilustratívne usporiadanie: hostitelia LAN na 192.168.50.0/24, bežný router na 192.168.50.1, vyhradený klient na 192.168.50.15 a vzdialená LAN na 10.60.0.0/24 dostupná len tunelom, ktorý tento klient drží. Ani jedno z dvoch privátnych rozsahov sa s druhým neprekrýva, a tunel má vlastný plán adries.

Oba privátne rozsahy sú dôležité, pretože určujú, ktoré zariadenie môže odpovedať. Vzdialená strana uvidí paket prichádzať z tunelovej adresy klienta a jej odpoveď si musí nájsť cestu späť na 192.168.50.0/24. Ak je nakonfigurovaný len odchádzajúci smer, požiadavka môže fungovať, zatiaľ čo odpoveď zmizne.

Krok 1: nasmerujte router na klienta, nie na tunel

Na LAN routeri pridajte cieľovú trasu, ktorej ďalší skok je LAN adresa klienta:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Tento záznam hovorí „doruč to stroju, ktorý vie tunelovať“. Nehovorí nič o tom, ako sa tunel stavia, a nenahrádza klientovu vlastnú trasu. Na spravovanom routeri žije ekvivalent na stránke statických trás zariadenia; na Linux routeri patrí do konfigurácie rozhrania, ktoré vlastní LAN, nie do shellu, ktorý zavriete.

Skontrolujte odpoveď druhého príkazu. Ak hlási klienta ako gateway a LAN rozhranie ako device, prvý skok je správny a zvyšná práca je na druhom stroji.

Krok 2: dajte klientovi vlastnú trasu na strane tunela

Klient teraz dostane paket pre 10.60.0.0/24 a pozrie sa do svojej tabuľky. Ak jeho tunelová konfigurácia nainštalovala trasu pre tento prefix, paket pokračuje šifrovane. Ak nie, paket zodpovedá bežnej predvolenej trase a vráti sa na 192.168.50.1, ktorý ho pošle znova klientovi.

Pozrite sa, než niečo pridáte:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Chýbajúca trasa prefixu vo všetkých tabuľkách je nález, ktorý hľadáte. Pridajte ju cez vlastnú konfiguráciu tunela, aby ju budúce opätovné pripojenie znova nainštalovalo; ručná ip route add zmizne so seansou a porucha sa vráti v najmenej vhodnej chvíli. Ďalším skokom je tunelové rozhranie alebo adresa, ktorú VPN prideľuje ako svojho partnera, podľa klienta, a adresa partnera by mala pochádzať z aktuálneho profilu, nie zo starej poznámky.

Slučka, keď nastane, nie je v praxi nekonečná: TTL pri každom prechode klesá a paket umiera so správou o prekročení času. Preto opakovaný traceroute môže naznačovať cyklus, zatiaľ čo klient, ktorý jednoducho nepreposiela, ten istý paket ticho zahodí.

Krok 3: povoľte preposielanie a vyberte spiatočnú cestu

Prijímať a preposielať sú rôzne oprávnenia. net.ipv4.ip_forward=1 na klientovi povoľuje tranzit na úrovni jadra a pravidlo firewallu ho ešte musí povoliť medzi LAN rozhraním a tunelom. Pravidlo, ktoré povoľuje prístup k vlastnej stránke správy klienta, nepovolí tranzit do vzdialenej LAN, a tento rozdiel sa dá ľahko prehliadnuť, keď ten istý hostiteľ lokálne odpovedá na pingy.

Vzdialená strana má zrkadlový problém. Musí vedieť, že 192.168.50.0/24 je dostupná cez tohto overeného klienta. S OpenVPN to zvyčajne znamená trasu pre jednotlivých klientov, ktorú pretlačí konfigurácia servera, alebo súbor špecifický pre klienta na serveri, ktorý deklaruje LAN za klientom. Bez toho vzdialená LAN buď odpoveď zahodí, alebo ju pošle na svoju predvolenú bránu, teda na internet.

Preklad zdroja je alternatíva, keď sa prefix LAN nedá inzerovať. Obmedzené pravidlo masquerade na klientovi prepíše zdroj na tunelovú adresu a odpovede sa potom vracajú prirodzene. Tiež skrýva, ktorý hostiteľ LAN požiadavku odoslal, a samo o sebe neumožňuje vzdialenej strane iniciovať spojenia dovnútra. Zvoľte tento kompromis vedome, namiesto toho, aby ste pridali plošné masquerade a vedľajší účinok objavili neskôr.

Krok 4: obe rozhodnutia zaveďte trvalo, potom otestujte skutočnú cestu

Každá trasa má vlastníka a vlastníkom je konfigurácia, ktorá sa obnoví pri štarte alebo pri opätovnom pripojení. Na routeri to môže byť záznam statickej trasy; na klientovi to môže byť profil VPN, NetworkManager alebo systemd-networkd. Overte opätovným pripojením tunela a reštartom klienta, potom tabuľku prečítajte znova, namiesto toho, aby ste úprave dôverovali.

Predvolenú trasu, ktorá nesie vonkajšie spojenie tunela, nechajte nedotknutú. Jej nahradenie, aby sa nastavenie „zjednodušilo“, rozbije šifrovanú cestu skôr, než ju akákoľvek vnútorná prevádzka stihne použiť, a príznakom je tunel, ktorý sa po zmene už nikdy nenadviaže.

Testujte z bežného hostiteľa LAN, nie z klienta, pretože požiadavka vzniknutá na klientovi nikdy neprecvičí prvý skok routera. Stiahnite službu, ktorá existuje len vo vzdialenej LAN, a potvrďte telo odpovede, potom skontrolujte počítadlá alebo logy klienta, aby ste videli tranzit. Vnútorný traceroute so súkromnými skokmi dokazuje preposielanie, nie šifrovanie: vonkajšia cesta je samostatné pozorovanie a iba počítadlá rozhrania tunela ukazujú, čo cez neho odišlo.