Kokį šaltinio adresą NGINX įrašys VPN klientui?

Tame pačiame hoste veikiančioje NGINX ir OpenVPN sąrankoje matomi trys kliento adresai, po vieną kiekvienam keliui, kurį gali pasirinkti užklausa. Naršyklė, pasiekianti tunelio adresą, naršyklė, pasiekianti viešą adresą, ir programa, išeinanti per tinklų sietuvo interneto kelią, klausymosi lizde atrodo skirtingai. Prieš interpretuodami žurnalo eilutę, nuspręskite, kurį kelią stebite. Sprendimas priklauso nuo paskirties, kurią naudojo klientas, nuo išimties, kurią jis turi išoriniam VPN galiniam taškui, ir nuo to, ar kas nors pakeliui išverčia paketą.

Spręskite pagal paskirtį, o ne pagal tai, kas yra naudotojas

Pradėkite nuo adreso, kuriam buvo išsiųsta užklausa, nes būtent šis adresas parenka kelią. Užklausa hosto tunelio adresui ateina tunelio sąsaja, o kliento vidinis adresas yra šaltinis. Užklausa hosto viešajam adresui paprastai ateina interneto link nukreipta sąsaja su kliento viešuoju adresu, net kai tame pačiame nešiojamajame kompiuteryje tuo metu yra sukurtas tunelis. Priklausymas VPN telkiniui todėl yra paketo kelio savybė, o ne savybė, kuri seka naudotoją.

Būtent šią trečią eilutę verta patikrinti pirmiausia, kai žurnale pasirodo VPN naudotojas su adresu, neturinčiu nieko bendra su tuneliu. Tai taip pat paaiškina, kodėl du naudotojai su ta pačia profiliu gali sukurti skirtingus įrašus: jų pačių prieigos tinklai skiriasi, ir niekas tunelyje to neperrašo.

Kodėl išorinis galinis taškas sukuria antrą viešą kelią

Klientas turi pasiekti viešą sietuvo adresą, kad sukurtų tunelį, todėl maršrutas į tą adresą turi egzistuoti už tunelio ribų. Kai klientas nukreipia visą srautą į vidų, protinga įgyvendinimo versija palieka aiškų hosto maršrutą į serverio viešąjį adresą, kad išvengtų tunelio, kuris priklauso nuo savęs paties. Ši išimtis neskiria paslaugų, todėl jos laikosi bet kuri užklausa tam pačiam viešajam adresui, įskaitant naršyklės užklausą svetainei, talpinamai sietuvo.

Tai mechanizmas, slypintis už daugumos painių pranešimų šioje srityje, ir jis priklauso nuo kliento, o ne serverio įgyvendinimo. Todėl du klientai su identiškais profiliais gali elgtis skirtingai. Pašalinus išimtį, kad žurnalas būtų »sutvarkytas«, nukrenta ir tunelis, tad palikite ją ir projektuokite aplink ją.

Skaitykite lizdą, lentelę ir žurnalo formatą kartu

Trys stebėjimai nusprendžia, kurį kelią stebite: kur lizdas klausosi, kuri sąsaja atsako į paskirtį ir ką žurnalo formatas iš tikrųjų įrašo. Jei klausytojas susietas tik su tunelio adresu, vieša užklausa jo apskritai negali pasiekti, o tai iš karto atmeta dvi eilutes. Jei kliento paieška grąžina tunelio įrenginį, užklausa atėjo su vidiniu šaltiniu ir žurnalas turėtų tai parodyti.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Tada skaitykite formatą, o ne eilutę. Laukas, maitinamas persiųsto antraštės, įrašo teiginį, o ne lizdo partnerį, ir teiginys svarbus tik tada, kai tiesioginis partneris yra patikimas tarpinis serveris. Abiejų reikšmių įrašymas į žurnalą išsprendžia vėlesnius ginčus, nes tiesioginis partneris ir pakeistas adresas yra skirtingi faktai, ir tik vienas iš jų atėjo iš tinklo.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Pasirinkite norimą įėjimo tašką ir suderinkite DNS

Jei svetainė turi būti pasiekiama tik per tunelį, duokite jai vardą, kuris VPN klientams nurodo tunelio adresą, ir vykdykite politiką klausymosi lizde. Padalytas DNS atsakymas, grąžinantis 10.24.0.1 vidiniam vardui, yra maršrutizavimo sprendimas, apsirengęs vardų sprendimo detalės kostiumu. Jei svetainė turi būti ir vieša, laikykite du vardus arba du prievadus ir leiskite žurnalui pasakyti, kuris aptarnavo užklausą.

Leidimo taisyklės laikosi tos pačios logikos. Tunelio telkinio leidimas nesuteikia teisės viešai užklausai ir neužpildys vidinio adreso ryšiui, kuris atėjo per internetą. Abiejų įėjimo taškų maišymas po vienu vardu paverčia įrašytą šaltinį kliento maršrutizavimo šalutiniu poveikiu, o ne projektavimo pasirinkimu.

Patikrinkite kelią, tada politiką

Patvirtinkite kelią sietuvo užfiksuotu įrašu ir užklausa, kurią valdote. Užfiksavimas tunelio įrenginyje ir viešojoje sąsajoje parodo, kuri nešė baitus, o paketų tvarka pasako, ar tarp jų įvyko vertimas.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Tada patikrinkite prieigą abiem kryptimis: numatytas įvardytas įėjimas veikia numatytam klientui, o nepatvirtintas viešas kelias atmetamas, o ne tik lėtas. Bendra IP atgarsio svetainė įrodo kai ką apie sietuvo interneto išėjimą ir nieko apie šią svetainę tame pačiame hoste. Kai puslapis ir WebSocket nesutaria, palyginkite jų URL, adresų šeimas ir DNS atsakymus prieš liesdami serverio konfigūraciją.