Kādu avota adresi NGINX reģistrēs VPN klientam?

Vienā resursdatorā uzstādītā NGINX un OpenVPN konfigurācijā parādās trīs klienta adreses, pa vienai katram ceļam, ko pieprasījums var izvēlēties. Pārlūks, kas sasniedz tuneļa adresi, pārlūks, kas sasniedz publisko adresi, un programma, kas iziet pa vārtejas interneta ceļu, klausīšanās ligzdā izskatās atšķirīgi. Pirms interpretējat žurnāla rindu, izlemiet, kuru ceļu skatāties. Lēmums ir atkarīgs no galamērķa, ko klients izmantoja, no izņēmuma, kas tam ir ārējam VPN galapunktam, un no tā, vai kaut kas pa ceļam pārtulko pakešu datus.

Izlemiet pēc galamērķa, nevis pēc tā, kas ir lietotājs

Sāciet ar adresi, uz kuru pieprasījums tika nosūtīts, jo šī adrese izvēlas ceļu. Pieprasījums uz resursdatora tuneļa adresi pienāk tuneļa saskarnē ar klienta iekšējo adresi kā avotu. Pieprasījums uz resursdatora publisko adresi parasti pienāk uz internetu vērstā saskarnē ar klienta publisko adresi, pat ja tajā pašā klēpjdatorā tajā brīdī ir izveidots tunelis. Piederība VPN baseinam tāpēc ir pakešu ceļa īpašība, nevis īpašība, kas seko lietotājam.

Tieši šo trešo rindu ir vērts pārbaudīt vispirms, kad žurnālā parādās VPN lietotājs ar adresi, kam ar tuneli nav nekāda sakara. Tas arī izskaidro, kāpēc divi lietotāji ar vienu un to pašu profilu var radīt atšķirīgus ierakstus: viņu pašu piekļuves tīkli atšķiras, un nekas tunelī to nepārraksta.

Kāpēc ārējais galapunkts rada otru publisko ceļu

Klientam jāsasniedz vārtejas publiskā adrese, lai izveidotu tuneli, tāpēc maršrutam uz šo adresi jāpastāv ārpus tuneļa. Kad klients novirza visu trafiku uz iekšu, saprātīga implementācija patur skaidru resursdatora maršrutu uz servera publisko adresi, lai izvairītos no tuneļa, kas atkarīgs no sevis paša. Šis izņēmums nav selektīvs attiecībā uz pakalpojumiem, tāpēc tam seko jebkurš pieprasījums uz to pašu publisko adresi, tostarp pārlūka pieprasījums uz vārtejā mitinātu vietni.

Šis ir mehānisms, kas slēpjas aiz lielākās daļas mulsinošo ziņojumu šajā jomā, un tas ir atkarīgs no klienta, nevis servera implementācijas. Tāpēc divi klienti ar identiskiem profiliem var uzvesties atšķirīgi. Ja izņēmumu noņem, lai »salabotu« žurnālu, kopā ar to nokrīt arī tunelis, tāpēc saglabājiet to un projektējiet ap to.

Lasiet ligzdu, tabulu un žurnāla formātu kopā

Trīs novērojumi nosaka, kuru ceļu skatāties: kur ligzda klausās, kura saskarne atbild uz galamērķi un ko žurnāla formāts patiešām ieraksta. Ja klausītājs ir piesaistīts tikai tuneļa adresei, publisks pieprasījums to nemaz nevar sasniegt, un tas uzreiz izslēdz divas rindas. Ja klienta meklējums atgriež tuneļa ierīci, pieprasījums pienāca ar iekšēju avotu, un žurnālam tas jāparāda.

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

Pēc tam lasiet formātu, nevis rindu. Lauks, ko baro pārsūtītā galvene, reģistrē apgalvojumu, nevis ligzdas partneri, un apgalvojumam ir nozīme tikai tad, ja tiešais partneris ir uzticams starpniekserveris. Abu vērtību ierakstīšana žurnālā izšķir vēlākus strīdus, jo tiešais partneris un aizstātā adrese ir dažādi fakti, un tikai viens no tiem nāca no tīkla.

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

Izvēlieties vēlamo ieejas punktu un saskaņojiet DNS

Ja vietnei jābūt pieejamai tikai pa tuneli, piešķiriet tai vārdu, kas VPN klientiem izšķiras uz tuneļa adresi, un īstenojiet politiku klausīšanās ligzdā. Sadalīta DNS atbilde, kas atgriež 10.24.0.1 iekšējam vārdam, ir maršrutēšanas lēmums vārdu izšķiršanas detaļas kostīmā. Ja vietnei jābūt arī publiskai, paturiet divus vārdus vai divus portus un ļaujiet žurnālam pateikt, kurš apkalpoja pieprasījumu.

Atļauju noteikumi ievēro to pašu loģiku. Tuneļa baseina atļaušana nepiešķir tiesības uz publisku pieprasījumu, un tā neaizpildīs iekšējo adresi savienojumā, kas pienāca pa internetu. Abu ieejas punktu sajaukšana vienā vārdā padara ierakstīto avotu par klienta maršrutēšanas blakusefektu, nevis projektēšanas izvēli.

Pārbaudiet ceļu, pēc tam politiku

Apstipriniet ceļu ar uztveršanu uz vārtejas un pieprasījumu, ko kontrolējat. Uztveršana tuneļa ierīcē un publiskajā saskarnē parāda, kura nesa baitus, un pakešu secība pasaka, vai starp tām notika pārtulkošana.

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

Pēc tam pārbaudiet piekļuvi abos virzienos: paredzētā nosauktā ieeja darbojas paredzētajam klientam, un neapstiprināts publisks ceļš tiek noraidīts, nevis vienkārši lēns. Vispārīga IP atbalss vietne pierāda kaut ko par vārtejas interneta izeju un neko par šo vietni tajā pašā resursdatorā. Kad lapa un WebSocket nesaskan, salīdziniet to URL, adrešu saimes un DNS atbildes, pirms pieskaraties servera konfigurācijai.