Opinber forskeyti í gegnum OpenVPN: laga bakleiðina

Fylgstu með tunnilinum rísa og biðlarinn pinga hinum megin, og síðan svarar opinbert vistfang sem tilheyrir bak við VPN frá öðrum stað, eða alls ekki. Þetta einkenni hefur venjulega ekkert með dulritunina eða skírteinin að gera. Forskeyti sem þjónustuveitan beinir er afhent sem IP-leið, og að bera það í gegnum OpenVPN þýðir að endurskapa þá leið á tveimur stigum og varðveita upprunavistfangið á bakleiðinni. Ekki þarf að brúa WAN-ið, og að bæta vistfanginu við tengi býr ekki til efri leiðina.

Forskytið verður fyrst að vera beint til þín

Spurðu þjónustuveituna hvernig blokkin er afhent. Forskeyti sem beint er á aðalvistfang þjónsins þíns er annað en vistföng sem þjónustuveitan býst við að ná beint á WAN-kafla. Aðeins fyrsta líkanið virkar með hönnuninni hér.

Ef þjónustuveitan beinir 198.51.100.64/28 á inngangsþjóninn þinn koma pakkar fyrir það bil á þjóninn og stöðvast þar nema þú sendir þá áfram. Ef þjónustuveitan brýr bilið yfir á uplink-ið þitt í staðinn verður þjóninn að svara ARP fyrir það, sem er annað vandamál.

Prófaðu afhendingarlíkanið áður en þú snertir OpenVPN: að utan, pingaðu vistfang í blokkinni og sjáðu hvaða tengi tekur við því. Ef ekkert berst mun engin tunnelstilling hjálpa. Ef vistfangið svarar beint á WAN-inu er þjónustuveitan að brúa í stað þess að beina, og hönnunin hér að neðan á ekki við.

Tvö stig leiðar: kjarnaleið og iroute

OpenVPN þarf forskeytið á tveimur stöðum. Kjarninn verður að vita að forskeytið tilheyrir tunniltækinu, svo framsendir pakkar fari inn í OpenVPN í stað sjálfgefnu leiðarinnar. OpenVPN verður líka að vita hvaða auðkenndi biðlari á forskeytið, og það er iroute-færslan í biðlarasértæku möppunni.

Leiðin á þjónshliðinni lítur svona út, og forskeytið og gríman verða að passa við úthlutunina:

ip route add 198.51.100.64/28 dev tun0

Biðlarasértæka stillingin úthlutar eignarrétti. Settu hana í CCD-skrána sem heitir eftir almennu nafni biðlaraskírteinisins, og staðfestu að það sé möppan sem þjóninn les í raun:

iroute 198.51.100.64 255.255.255.240

Skjöl OpenVPN um beind net lýsa báðum stigum og hvers vegna þau eru aðskilin. Kjarnaleið án iroute sendir pakka í tunnilinn án eiganda, og OpenVPN hendir þeim. iroute án kjarnaleiðarinnar lætur pakkana vera á sjálfgefinni slóð þjónsins. Báðar villurnar líta út eins og brotinn tunnill frá biðlarahlið.

Hvar þjónustuvistfangið býr

Framselda forskeytið er ekki það sama og eigin vistföng tunnilsins. Númeraðu tenginguna úr einkarýminu ef þú vilt, og settu opinbera þjónustuvistfangið þar sem þjónustan keyrir í raun.

Á Linux-biðlara sem lýkur þjónustunni staðbundið er eitt hýsilvistfang nóg:

ip address add 198.51.100.70/32 dev lo

Ef forskeytinu er beitt áfram á VM-hýsil eða annað LAN skaltu stilla þá niðurleið og bakleið hennar í staðinn. Ekki er þörf á að úthluta hverju vistfangi í blokkinni til VPN-biðlarans, og það skapar árekstra síðar.

Haltu opinbera upprunanum á bakleiðinni

Svar frá framselda forskeytinu verður að fara út um tunnilinn og ná leið þjónustuveitunnar. Ef fjárhýsillinn sendir það um sitt eigið ISP virðist upprunavistfangið falsað, og þjónustuveitan eða áfangastaðurinn hendir því. Lausnin er regla byggð á uppruna eða sérstök leiðartöfla, ekki breiðara NAT. Án hennar virkar þjónustan frá mótaðilanum í tunnilnum og mistekst hvarvetna annars staðar.

Á inngangsþjóninum er breið masquerade-regla venjulegi sökudólgurinn. Hún endurskrifar opinbera upprunann í aðalvistfang þjónsins, og biðlarinn sér aldrei það raunverulega:

iptables -t nat -S POSTROUTING

Takmarkaðu NAT við einkaaðila VPN-biðlarana sem þurfa það og láttu framselda forskeytið óþýtt. Staðfestu síðan að þjóninn sendi forskeytið yfirhöfuð áfram, því framsendingarkeðja sem hafnar sjálfgefið hendir því hljóðlaust.

Staðfestu báðar áttir áður en þú treystir því

Staðfestingin eru fjórar athuganir, ekki ein. Staðfestu að leið þjónustuveitunnar berist, kjarninn sendi forskeytið í tunnilinn, OpenVPN tengi það rétta biðlaranum, og svarið komi til baka með opinbera upprunann óskaddaðan. Hver athugun hefur sína skipun, svo bilun bendir á lag en ekki alla hönnunina. Keyrðu þær í þessari röð eftir hverja stillingarbreytingu.

Spurðu kjarnann hvaða leið framselt vistfang tekur, og fylgstu með tunnilnum meðan beiðni keyrir:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Sía á öfugri leið getur ógilt rétta leið. Athugaðu virka stillingu á tunnilnum og á uplink-inu, og mundu að strangt ham hafnar umferð þar sem uppruninn passar ekki við tengið sem hún kom á:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Að lokum, prófaðu bilunartilfellið. Stöðvaðu tunnilinn og staðfestu að opinbera forskeytið leki ekki út um venjulega uplink-ið. Endurheimt VPN ætti að koma þjónustunni aftur án þess að víkka hvaða port hýsillinn opnar.