VPN klientai prisijungia, bet interneto nėra: trys trūkstamos dalys

Klientas gauna adresą, serveris atsako į ping, o kiekvienas puslapis vis tiek baigiasi skirtuoju laiku. Dauguma žmonių šiuo metu pradeda redaguoti kliento profilį, o tai dažniausiai yra bergždžias darbas: kai tunelis pakeltas, serveris turi elgtis kaip maršrutizatorius. Trys sąlygos turi būti įvykdytos vienu metu, kad paketas išeitų ir grįžtų atsakymas, ir simptomas yra toks pat, kurios bebūtų trūkstama.

Kodėl veikiantis tunelis vis dar neturi išėjimo

Branduolys turi persiųsti paketus tarp sąsajų, o tai daugumoje Linux platinimų pagal numatymą išjungta. Srautas turi būti išverstas į adresą, į kurį išorinis pasaulis gali atsakyti, nebent kiekvienas aukštesnis maršrutizatorius jau žino grįžimo kelią į tunelio potinklį. Ugniasienės persiuntimo kelias turi leisti srautą abiem kryptimis, įskaitant atsakymus.

Kiekvieną iš jų galima taisyti atskirai, ir tai yra spąstai. Įjungus persiuntimą be vertimo taisyklės, paketai išeina su privačiu šaltiniu ir be grįžimo kelio. Pridėjus vertimą be persiuntimo taisyklės, branduolys paketą numeta vienu žingsniu vėliau.

Todėl tikrinkite tris sluoksnius, o ne klientą, ir keiskite po vieną, kad rezultatas ką nors reikštų.

Persiuntimas yra branduolio jungiklis, kurį turite padaryti nuolatiniu

Prieš keisdami patikrinkite dabartinę reikšmę, tada ją nustatykite ir patvirtinkite, kad pakeitimas įsigaliojo.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Pirmoji komanda praneša dabartinę reikšmę, antroji ją nustato veikimo metu, o trečioji įrodo, kad įrašymas pavyko. Veikimo metu reikšmė išnyksta kitą kartą paleidus iš naujo, todėl veikianti sesija gali sugesti po priežiūros be jokių konfigūracijos pakeitimų.

Padarykite ją nuolatinę faile po /etc/sysctl.d/, tada pritaikykite tą failą, o ne paleiskite iš naujo, kad sužinotumėte. FreeBSD atitikmuo yra net.inet.ip.forwarding, o nuolatiniam veikimui – gateway_enable=YES faile rc.conf. Įrenginys, pranešantis, kad persiuntimas išjungtas, paaiškina visą klasę pranešimų „paketai ateina, o nieko negrįžta”. Tikrinkite nustatymą ir po kiekvieno atnaujinimo, nes perstatytas branduolys ar pakeistas įrenginio atvaizdas gali jį atstatyti niekam nepasakęs.

Pasirinkite masquerade arba vieną fiksuotą vertimo adresą

Su dinamišku išoriniu adresu masquerading yra paprasčiausia teisinga forma. Nurodykite tunelio potinklį kaip šaltinį, o išorinę sąsają kaip išėjimą.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Su statiniu viešuoju adresu šaltinio vertimas būtent į tą adresą yra labiau nuspėjamas ir lengviau audituojamas.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Antroji forma turi priežiūros spąstus: kietai užkoduotas adresas, kuris vėliau pasikeičia, palaiko tunelį veikiantį, kol prieiga prie interneto tyliai sustoja. Arba naudokite masquerade, arba atnaujinkite taisyklę, kai tiekėjas jus perkelia. Sąsaja taip pat svarbi, nes maršrutizatorius, bendrinantis savo viršutinį tunelį, turi verstis per tą tunelį, o ne per fizinį WAN.

Filtrų lentelė yra trečiasis vartai

Persiuntimas ir vertimas gali būti abu teisingi, o paketas vis tiek žūva filtrų lentelėje. ufw yra dažnas kaltininkas: jo persiuntimo politika pateikiama kaip DROP, o likusi sąranka gali atrodyti visiškai teisinga, kol tas vienas nustatymas žudo srautą. Jį pakelti yra sąmoningas saugumo sprendimas, o ne žymės langelis.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Pirmoji taisyklė leidžia naują srautą iš tunelio į išorę, o antroji – tik atsakymus atgal. Susiaurinkite abi iki tunelio potinklio ir numatomo tikslo, nes bendras leidimas tunelio sąsajoje paverčia VPN atviru išėjimo tašku kiekvienam, kuris gali autentifikuotis.

Tiltu sujungtas tunelis reikalauja kito atsakymo. Adresas priklauso tiltui, o ne fiziniam prievadui, todėl sąsajos pavergimas pašalina anksčiau turėtą adresą ir priegloba atrodo nepasiekiama, kol pats tiltas gauna adresą, kurį gali suteikti dhclient br0. Ta gedimas atrodo kaip VPN problema, o iš tikrųjų tai antrojo sluoksnio problema. Patikrinkite paties tilto adresą prieš liesdami ugniasienę, nes filtro pakeitimas negali sutaisyti prieglobos, kuri nebeturi adreso, iš kurio siųsti.

Kur žiūrėti, kai puslapis niekada neįkeliamas

Pinginkite serverio tunelio adresą, kad įrodytumėte, jog tunelis egzistuoja. Tada paleiskite traceroute iš kliento į viešą adresą ir perskaitykite, kur jis sustoja: serveryje paketas atvyksta, bet nepersiunčiamas ir neišverčiamas; už serverio problema yra aukščiau ir ne jūsų rankose.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Pirmoji komanda įrodo, kad tunelis neša srautą iki paties serverio, o antroji parodo, kaip toli paketas pasiekia išorę. Pėdsakas, pasibaigiantis tunelio adresu, rodo persiuntimą arba vertimą serveryje, o pėdsakas, sustojantis vienu šuoliu vėliau, rodo tiekėją arba viršutinio maršrutizatoriaus grįžimo kelią.

Serveryje stebėkite išorinę sąsają, kol klientas krauna puslapį. Srautas, išeinantis su privačiu šaltinio adresu, reiškia, kad trūksta vertimo, o visiškas atsakymo nebuvimas reiškia, kad jį meta persiuntimo kelias arba viršutinis grįžimo maršrutas.

Jei nuotoliniai klientai turi pasiekti ir serverio LAN prieglobas, atminkite, kad LAN reikia grįžimo maršruto į tunelio potinklį. Tai maršrutizavimas, o ne vertimas, ir tai yra žingsnis, kuris dažniausiai pamirštamas, kai interneto kelias pagaliau pradeda veikti.