Kāpēc jūsu LAN nesasniedz pakalpojumu VPN klientā

Jūsu tunelis ir uzcelts, pakalpojums klausās, un biroja LAN joprojām neko nesaņem atpakaļ. Neviens nesabojāja VPN. No LAN puses klēpjdatora tuneļa adrese neeksistē, kamēr kaut kas nepasaka LAN, kā tai piekļūt, un atbildei jāatgriežas pa to pašu ceļu, pa kuru pieprasījums izgāja. Esmu redzējis cilvēkus trīs reizes pārbūvējam pilnīgi veselu tuneli, pirms kāds paskatījās uz atgriešanās ceļu.

Salūzis nav tunelis

Abi gali atrodas privātos diapazonos, tas ir normāls gadījums, nevis nepareiza konfigurācija. Tāda adrese kā 10.8.0.6 ir reāla tuneļa iekšpusē un neeksistē nekur citur, tāpēc LAN nav iemesla tur kaut ko sūtīt. Pirms aiztikt maršrutēšanu, pārliecinieties, ka pakalpojums vispār ir sasniedzams tuneļa iekšpusē: klientā ss -ltn parāda, vai klausītājs ir piesaistīts 127.0.0.1, LAN saskarnei vai tuneļa adresei. Dēmons, kas piesaistīts tikai loopback, neatbild nevienam, izņemot sevi, un to nemaina neviens maršruts, DNAT vai porta pāradresācija.

Starpniekserveris portā 80 vai 443 ir cits rīks ar citu redzamību. Tas pārvieto pieprasījumus, nevis paketes, tāpēc tas ir nepareizais slānis neapstrādātam datubāzes savienojumam, un tieši ķeršanās pie tā ir ceļš, kā šī problēma nonāk trīs rīku dziļumā, pirms kāds kaut ko izmēra.

Maršruta forma: pastāstiet LAN, kur atrodas baseins

Statisks maršruts LAN vārtejā ir vistīrākā atbilde, kad LAN un tuneļa baseins nepārklājas. Novirziet baseinu uz mašīnu, kas pabeidz tuneli:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Tas izlabo tikai vienu virzienu, tāpēc pusgatavas šīs izmaiņas versijas izskatās kā progress. Tuneļa pusei vajag atbilstošo pusi, citādi atbilde pamet klientu pa tā paša noklusējuma maršrutu un iet bojā ceļā:

push "route 192.168.1.0 255.255.255.0"

Apakštīklam, kas atrodas aiz viena klienta, nevis aiz servera, serverim vajag gan sistēmas maršrutu, gan iroute ierakstu tā klienta failā zem client-config-dir. Bez iroute OpenVPN zina, ka prefikss pastāv, un nav ne jausmas, kurš klients to pārvalda: paketes pienāk, un dēmonam nav ar ko tās saskaņot.

Lūk, mīts, kas ir pelnījis nosaukumu. Maršruts padara adresi sasniedzamu; tas nepadara otru pusi gatavu atbildēt. Vietnes-uz-vietni partneri uzliek vēl vienu slāni, jo attālinātā vārteja pieņem tikai avotus tās politikā uzskaitīto prefiksu iekšienē, un klēpjdators, kas nāk no mājas baseina, tajos nav.

NAT forma: DNAT uz iekšu un tā SNAT rinda, ko visi izlaiž

Kad jūs nevarat aiztikt LAN vārteju vai vēlaties publicēt tieši vienu portu, tulkošana VPN resursdatorā darbojas bez jebkāda maršruta LAN. Publicējiet portu, pāradresējiet to un pārtulkojiet avotu ceļā uz tuneli:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Trešā rinda ir tā, kas pazūd. Izlaidiet to, un klients redz sākotnējo LAN adresi kā avotu, atbild pa savu noklusējuma maršrutu, un šī atbilde dodas tunelī, nevis atpakaļ uz LAN. Vai savienojums izdzīvos, tad ir atkarīgs no maršrutēšanas, ko nekad neesat plānojis. Ar SNAT klients redz servera tuneļa adresi, tāpēc atbilde seko tunelim atpakaļ līdz vienīgajam resursdatoram, kas var atcelt tulkojumu.

Patērētāju programmaparatūra izmanto savus ķēžu nosaukumus un negenerē šo tulkojumu jūsu vietā. Tomato gadījumā ienākošais noteikums nonāk WANPREROUTING un pēc tam filtrēšanas ķēdē, piemēram, wanin, un noteikumu kopai, kas izskatās pilnīga, joprojām vajag manuālu POSTROUTING rindu. Tā nav programmaparatūras kļūda; tā ir noteikumu kopa, kas rakstīta tikai ienākošajai plūsmai.

Kāpēc pareizi izskatīgs noteikums tomēr nomet paketi

Lielākā daļa šo kļūmju nav tajā noteikumā, uz kuru jūs skatāties. Pārbaudiet četras lietas šādā secībā un apstājieties pie pirmās, kas neizpildās:

• Ķēžu secība. iptables -I ievieto augšā, un -A pievieno beigās, tāpēc agrāks atļaujošs vai bloķējošs noteikums izlemj pirmais.
• Nepareiza ķēde. Plūsma, kas adresēta pašam maršrutētājam, šķērso INPUT, un pārsūtītā plūsma to nekad neskar. Viena pakalpojuma publicēšanai var būt vajadzīgi noteikumi abās.
• Virziena karodziņi. -i tun0 atbilst plūsmai, kas nāk no klientiem, un -o tun0 plūsmai, kas iet pretī. REJECT ar nepareizu karodziņu bloķē kaut ko, ko neesat domājis.
• Avota ierobežojums. Pāradresācija, kas pieņem vienu klienta adresi, darbojas no tā klienta un nomet jebkuru citu avotu bez vārda.

Noteikums ar nulles pakešu skaitītāju nemaz nav ceļā, un skaitītāju lasīšana ir ātrākais veids, kā atšķirt nepareizas ķēdes problēmu no nepareiza noteikuma problēmas.

Vietējā pāradresācija, kad LAN neko nevar mainīt

SSH vietējā pāradresācija apiet visu jautājumu. Tai nav vajadzīgs maršruts LAN, klienta ugunsmūra sadarbība un nekur publicēts ports:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Tad pakalpojums parādās tās mašīnas localhost:3000, kas tur tuneli, un nekur citur. Tā ir robeža: viena darbstacija, viens ports, un pāradresācija mirst kopā ar sesiju, ja vien kaut kas to nepalaidīs no jauna. Administratoram, kas pārbauda testa datubāzi, tas ir pareizais rīks. Kamerai vai skenerim, kam jāpiekļūst citiem cilvēkiem, tas nav, jo katram lietotājam būtu vajadzīga sava pāradresācija.

Pirms pievienojat vēl vienu noteikumu, pārbaudiet abus virzienus

Tulkošana atstāj pēdas, un tās lasīt ir labāk nekā minēt. VPN resursdatorā conntrack -L parāda, vai tulkošana vispār notika, iptables -t nat -L -n -v parāda, vai skaitītāji pārvietojās, un tcpdump -ni any port 3000 parāda, kura avota adrese patiešām ieradās. Klientā ss -ltn apstiprina, ka klausītājs ir adresē, kuru tunelis var sasniegt.

Pēc tam izvēlieties formu, ko paturat. Viens publicēts ports, maršruts visam baseinam un pāradresācija vienam administratoram ir trīs dažādas saistības, un to sajaukšana ir ceļš, kā strādājošs iestatījums kļūst par tādu, ko pēc pusgada neviens nevar izskaidrot. Pierakstiet, kura adrese no kurienes ir sasniedzama, un nākamais cilvēks, kas to atkļūdos, sāks ar atbildi, nevis ar tuneli.