Usmerjevalnik LAN in odjemalec VPN: dve napravi, dve usmerjevalni tabeli

Dve napravi posredujeta paket in vsaka vodi svojo tabelo. Usmerjevalnik LAN ve, da oddaljena predpona pripada odjemalcu VPN, odjemalec VPN pa ve, kako doseže to predpono skozi svoj tunel. Nastavite le prvo tabelo in paket prispe do stroja brez ustrezne poti, zato znova odide po privzeti poti. To je vsa napaka, in z vidika LAN je videti kot zanka usmerjanja, ker skoraj je.

Narišite oba skoka, preden se dotaknete poti

Vzemite ilustrativno postavitev: gostitelji LAN na 192.168.50.0/24, običajni usmerjevalnik na 192.168.50.1, namenski odjemalec na 192.168.50.15 in oddaljeni LAN na 10.60.0.0/24, dosegljiv le skozi tunel, ki ga ima ta odjemalec. Nobeno od obeh zasebnih območij se ne prekriva z drugim, in tunel ima svoj načrt naslovov.

Obe zasebni območji sta pomembni, ker določata, katera naprava lahko odgovori. Oddaljena stran bo videla paket, ki prihaja z naslova tunela odjemalca, in njen odgovor mora najti pot nazaj na 192.168.50.0/24. Če je nastavljena le odhodna smer, lahko zahteva deluje, medtem ko odgovor izgine.

Korak 1: usmerite usmerjevalnik na odjemalca, ne na tunel

Na usmerjevalniku LAN dodajte ciljno pot, katere naslednji skok je naslov LAN odjemalca:

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

Ta zapis pravi „dostavi ga stroju, ki zna tunelirati“. Ne pove ničesar o tem, kako je tunel zgrajen, in ne nadomešča odjemalčeve lastne poti. Na upravljanem usmerjevalniku ekvivalent živi na strani statičnih poti naprave; na usmerjevalniku Linux spada v konfiguracijo vmesnika, ki ima v lasti LAN, ne v lupino, ki jo boste zaprli.

Preverite odgovor drugega ukaza. Če poroča odjemalca kot gateway in vmesnik LAN kot device, je prvi skok pravilen, preostalo delo pa je na drugem stroju.

Korak 2: dajte odjemalcu lastno pot na strani tunela

Odjemalec zdaj prejme paket za 10.60.0.0/24 in pogleda v svojo tabelo. Če je njegova konfiguracija tunela namestila pot za to predpono, paket nadaljuje šifriran. Če ne, paket ustreza običajni privzeti poti in se vrne na 192.168.50.1, ki ga znova pošlje odjemalcu.

Poglejte, preden kaj dodate:

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

Manjkajoča pot predpone v vseh tabelah je ugotovitev, ki jo iščete. Dodajte jo prek lastne konfiguracije tunela, da jo bo naslednja ponovna povezava znova namestila; ročna ip route add izgine s sejo in povzroči, da se napaka vrne v najbolj neprijetnem trenutku. Naslednji skok je vmesnik tunela ali naslov, ki ga VPN dodeli kot svojega partnerja, odvisno od odjemalca, naslov partnerja pa mora priti iz trenutnega profila in ne iz stare opombe.

Zanka, ko se pojavi, v praksi ni neskončna: TTL se ob vsakem prehodu zniža in paket umre s sporočilom o preseženem času. Zato lahko ponavljajoči se traceroute nakazuje cikel, medtem ko odjemalec, ki preprosto ne posreduje, isti paket tiho zavrže.

Korak 3: dovolite posredovanje in izberite povratno pot

Prejemanje in posredovanje sta različni dovoljenji. net.ipv4.ip_forward=1 na odjemalcu dovoljuje tranzit na ravni jedra, požarna pravila pa ga morajo še vedno dovoliti med vmesnikom LAN in tunelom. Pravilo, ki dovoljuje dostop do odjemalčeve lastne upravljalne strani, ne bo dovolilo tranzita v oddaljeni LAN, razliko pa je lahko spregledati, ko isti gostitelj lokalno odgovarja na ping.

Oddaljena stran ima zrcalno težavo. Vedeti mora, da je 192.168.50.0/24 dosegljiv skozi tega overjenega odjemalca. S OpenVPN to običajno pomeni pot na odjemalca, ki jo potisne konfiguracija strežnika, ali datoteko, specifično za odjemalca na strežniku, ki razglasi LAN za odjemalcem. Brez tega oddaljeni LAN bodisi zavrže odgovor bodisi ga pošlje na svoj privzeti prehod, to je v internet.

Prevajanje vira je alternativa, ko predpone LAN ni mogoče oglaševati. Omejeno pravilo masquerade na odjemalcu prepiše vir na naslov tunela, odgovori pa se nato vrnejo samodejno. Prav tako skrije, kateri gostitelj LAN je poslal zahtevo, in samo po sebi ne dovoljuje oddaljeni strani, da začne povezave navznoter. Ta kompromis izberite zavestno, namesto da bi dodali splošno masquerade in stranski učinek odkrili pozneje.

Korak 4: obe odločitvi naredite trajni, nato preizkusite resnično pot

Vsaka pot ima lastnika, lastnik pa je konfiguracija, ki se obnovi ob zagonu ali ob ponovni povezavi. Na usmerjevalniku je to lahko zapis statične poti; na odjemalcu je to lahko profil VPN, NetworkManager ali systemd-networkd. Preverite s ponovno povezavo tunela in ponovnim zagonom odjemalca, nato tabelo preberite znova, namesto da bi zaupali spremembi.

Privzeto pot, ki nosi zunanjo povezavo tunela, pustite nedotaknjeno. Če jo zamenjate, da bi „poenostavili“ nastavitev, se šifrirana pot prekine, preden jo lahko uporabi kakršen koli notranji promet, simptom pa je tunel, ki se po spremembi nikoli več ne vzpostavi.

Preizkusite z običajnega gostitelja LAN, ne z odjemalca, ker zahteva, ki nastane na odjemalcu, nikoli ne preizkusi prvega skoka usmerjevalnika. Pridobite storitev, ki obstaja le v oddaljenem LAN, in potrdite telo odgovora, nato poglejte števce ali dnevnike odjemalca, da vidite tranzit. Notranji traceroute z zasebnimi skoki dokazuje posredovanje, ne šifriranja: zunanja pot je ločeno opazovanje in le števci vmesnika tunela kažejo, kaj je šlo skozenj.