LAN maršrutizatorius ir VPN klientas: du įrenginiai, dvi maršrutų lentelės

Du įrenginiai persiunčia paketą ir kiekvienas laiko savo lentelę. LAN maršrutizatorius žino, kad nuotolinis prefiksas priklauso VPN klientui, o VPN klientas žino, kaip pasiekti tą prefiksą per savo tunelį. Sukonfigūruokite tik pirmą lentelę ir paketas atvyksta į mašiną, kuri neturi atitinkančio maršruto, todėl vėl išvyksta numatytuoju maršrutu. Tai yra visa triktis, ir iš LAN pusės ji atrodo kaip maršrutizavimo kilpa, nes beveik ja ir yra.

Nubrėžkite du šuolius prieš liesdami maršrutą

Paimkite iliustracinį išdėstymą: LAN mazgai 192.168.50.0/24, įprastas maršrutizatorius 192.168.50.1, skirtasis klientas 192.168.50.15 ir nuotolinis LAN 10.60.0.0/24, pasiekiamas tik per tunelį, kurį turi tas klientas. Nė vienas iš dviejų privačių diapazonų nepersidengia su kitu, o tunelis turi savo adresų planą.

Abu privatūs diapazonai svarbūs, nes jie nusprendžia, kuris įrenginys gali atsakyti. Nuotolinė pusė matys paketą ateinant iš kliento tunelio adreso, o jos atsakymas turi rasti kelią atgal į 192.168.50.0/24. Jei sukonfigūruota tik išeinanti kryptis, užklausa gali veikti, o atsakymas dingsta.

1 žingsnis: nukreipkite maršrutizatorių į klientą, o ne į tunelį

LAN maršrutizatoriuje pridėkite paskirties maršrutą, kurio kitas šuolis yra kliento LAN adresas:

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

Tas įrašas sako „pristatyk jį mašinai, kuri gali tuneliuoti“. Jis nieko nesako apie tai, kaip statomas tunelis, ir nepakeičia paties kliento maršruto. Valdomame maršrutizatoriuje atitikmuo gyvena įrenginio statinių maršrutų puslapyje; Linux maršrutizatoriuje jis priklauso sąsajos, kuri valdo LAN, konfigūracijai, o ne apvalkalui, kurį uždarysite.

Patikrinkite antrosios komandos atsakymą. Jei jis praneša klientą kaip gateway, o LAN sąsają kaip device, pirmas šuolis teisingas, o likęs darbas yra kitoje mašinoje.

2 žingsnis: duokite klientui savo maršrutą tunelio pusėje

Klientas dabar gauna paketą 10.60.0.0/24 adresui ir pasižiūri į savo lentelę. Jei jo tunelio konfigūracija įdiegė maršrutą tam prefiksui, paketas tęsiasi užšifruotas. Jei ne, paketas atitinka įprastą numatytąjį ir grįžta į 192.168.50.1, kuris vėl jį siunčia klientui.

Pažiūrėkite prieš ką nors pridėdami:

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

Trūkstamas prefikso maršrutas visose lentelėse yra tas radinys, kurio ieškote. Pridėkite jį per paties tunelio konfigūraciją, kad kitas prisijungimas jį vėl įdiegtų; rankinis ip route add dingsta su sesija ir grąžina triktį pačiu netinkamiausiu metu. Kitas šuolis yra tunelio sąsaja arba adresas, kurį VPN priskiria kaip savo porininką, priklausomai nuo kliento, o porininko adresas turėtų ateiti iš dabartinio profilio, o ne iš senos pastabos.

Kilpa, kai ji atsiranda, praktiškai nėra begalinė: TTL mažėja kiekvieną kartą, o paketas miršta su pranešimu apie viršytą laiką. Štai kodėl kartojamas traceroute gali rodyti ciklą, o klientas, kuris tiesiog nepersiunčia, tą patį paketą tyliai numeta.

3 žingsnis: leiskite persiuntimą ir pasirinkite grįžimo kelią

Gavimas ir persiuntimas yra skirtingi leidimai. net.ipv4.ip_forward=1 kliente leidžia tranzitą branduolio lygiu, o ugniasienės taisyklė vis tiek turi jį leisti tarp LAN sąsajos ir tunelio. Taisyklė, leidžianti prieigą prie paties kliento valdymo puslapio, neleis tranzito į nuotolinį LAN, o šį skirtumą lengva praleisti, kai tas pats mazgas vietoje atsakinėja į ping.

Nuotolinė pusė turi veidrodinę problemą. Ji turi žinoti, kad 192.168.50.0/24 pasiekiamas per šį autentifikuotą klientą. Su OpenVPN tai paprastai reiškia kiekvienam klientui skirtą maršrutą, kurį stumia serverio konfigūracija, arba klientui būdingą failą serveryje, kuris deklaruoja LAN už kliento. Be to, nuotolinis LAN arba numeta atsakymą, arba siunčia jį į savo numatytąjį šliuzą, tai yra internetą.

Šaltinio vertimas yra alternatyva, kai LAN prefikso negalima skelbti. Apribota masquerade taisyklė kliente perrašo šaltinį į tunelio adresą, ir atsakymai tada grįžta natūraliai. Ji taip pat paslepia, kuris LAN mazgas pateikė užklausą, ir pati savaime neleidžia nuotolinei pusei inicijuoti jungčių į vidų. Pasirinkite šį kompromisą sąmoningai, o ne pridėkite visuotinę masquerade ir vėliau atraskite šalutinį poveikį.

4 žingsnis: padarykite abu sprendimus ilgalaikius, tada išbandykite tikrąjį kelią

Kiekvienas maršrutas turi savininką, o savininkas yra konfigūracija, kuri atsikuria įjungiant arba prisijungiant iš naujo. Maršrutizatoriuje tai gali būti statinio maršruto įrašas; kliente tai gali būti VPN profilis, NetworkManager arba systemd-networkd. Patikrinkite iš naujo prijungdami tunelį ir perkraudami klientą, tada perskaitykite lentelę iš naujo, užuot pasitikėję pakeitimu.

Palikite nepažeistą numatytąjį maršrutą, kuris neša išorinį tunelio ryšį. Pakeitus jį „supaprastinti“ sąranką, užšifruotas kelias lūžta anksčiau, nei bet koks vidinis srautas galės jį naudoti, o simptomas yra tunelis, kuris po pakeitimo niekada nebeatsistato.

Išbandykite iš įprasto LAN mazgo, o ne iš kliento, nes kliente atsiradusi užklausa niekada neišnaudoja pirmo maršrutizatoriaus šuolio. Gaukite paslaugą, kuri egzistuoja tik nuotoliniame LAN, ir patvirtinkite atsakymo turinį, tada pažiūrėkite į kliento skaitiklius ar žurnalus, kad pamatytumėte tranzitą. Vidinis traceroute su privačiais šuoliais įrodo persiuntimą, o ne šifravimą: išorinis kelias yra atskiras stebėjimas, ir tik paties tunelio sąsajos skaitikliai rodo, kas per jį išėjo.