VPN-kliendid jõuavad serverini, aga mitte LAN-i: milline lahendus?

Klient pingib OpenVPN-serveri tunneli aadressi ja saab vastuse, seejärel proovib serveri LAN-is olevat hosti ja ei saa midagi. See lõhe kitsendab viga tublisti: tunnel on üleval, edastamine tõenäoliselt töötab ja vastus lahkub uksest, mis tagasi ei vii. Lahendusi on kolm ja õige sõltub sellest, mida sa kontrollid ja millest oled valmis loobuma. Vasta kolmele allolevale küsimusele järjekorras ja valik ei ole enam maitse asi.

Kõigepealt tee kindlaks, kumb suund on katki

Päring saabub tunneli liidesele VPN-i pooli kuuluva lähteaadressiga. Server edastab selle LAN-i hostile ja see host vastab lüüsile, mille tema enda tabel nimetab, tavaliselt LAN-i ruuterile. Kui ruuteril pole pooli jaoks marsruuti, sureb vastus seal või uitab interneti suunas.

Testi mõlemat masinat enne, kui kumbagi muudad. Küsi serveris marsruutimistabelilt, kuidas see kliendini jõuaks; küsi LAN-i hostilt, kuidas see samani aadressini jõuaks. Esimene otsing osutab tavaliselt tunnelile ja teine LAN-i ruuterile ning see erinevus ongi viga ühes reas. Kaks otsingut on odavamad kui tulemüüri audit ja need selgitavad probleemi suuna.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Kui LAN-i host osutab juba VPN-serverile, on sinu probleem tulemüürireegel või MTU piir, mitte puuduv tagasitee. Ära lisa marsruuti, et filtrit parandada.

Esimene küsimus: kas saad kauges LAN-is ruuterit muuta?

Kui LAN-i ruuter on sinu, on puhas vastus staatiline marsruut VPN-i poolile, mille järgmine hüpe on VPN-serveri LAN-i aadress. See hoiab klientide lähteaadressid puutumatuna, mis loeb siis, kui LAN-i hostid logivad, filtreerivad või piiravad kiirust aadressi järgi. See ei vaja ka serveris tõlkimist, nii et tunnel jääb puhtaks marsruutimisteeks. Kohustus, mille see loob, on dokumentatsioon, sest pool, marsruut ja serveri seadistus peavad ühtima.

See nurjub vaikselt päeval, mil keegi pooli muudab. Kirjuta väärtus üks kord üles ja käsitle muudatust üheski kolmest kohast muudatusena kõigis kolmes.

NAS või Layer 3 kommutaator, mis teenust majutab, vajab sama marsruuti, välja arvatud juhul, kui saadab kõik ruuteri kaudu, millel see on. Kontrolli seadet, mis alamvõrgu lõpetab, mitte ainult interneti poole jäävat. Väikestes võrkudes on sageli kolm seadet, kellel on marsruutimise kohta oma arvamus.

Teine küsimus: kas LAN võib lõpetada kliendi aadresside nägemise?

Kui ruuter kuulub kellelegi teisele, ei vaja VPN-serveris tõlkimine koostööd. LAN-i host näeb serveri LAN-i aadressi, vastab sellele ja server tõlgib tagasi. Sellepärast käituvad seadmed ja NAT-põhised kaugjuurdepääsu rollid nii.

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

Hind on omistamine: kliendi kohta käivad aadressid kaovad LAN-i logidest. Iga lubatud loend LAN-i hostis peab siis nimetama serverit, mitte pooli.

Vali tõlkimine siis, kui koostööd pole saadaval, mitte siis, kui see on lihtsalt ebamugav. See peidab kliendi iga tulevase uurimise eest, ka nende eest, kus pead teadma, milline sülearvuti ühenduse avas. See võib ka rikkuda protokolle, mis upitavad aadressid kasulikku koormisse, sest tõlkimine elab päises. Kumbki valik pole arenenum; need vastavad erinevatele küsimustele omandisuhte kohta.

Kolmas küsimus: kas server ise on teise tunneli klient?

Kujuta ette teist topoloogiat: VPN-server helistab ka kommertsoperaatorile, seega on tal kaks tunnelit ja kaks aadresside komplekti. Liiklus, mida ta oma klientide eest edastab, lahkub operaatori kaudu ja see ei marsruudi vastuseid tagasi pooli aadressidele. Sellepärast kaovad vastused, kuigi mõlemad tunnelid on terved.

Lahendus on maskeerida ka väljuv tunnel, nii et operaator näeb ainult serveri tunneli aadressi. Vastassuund vajab oma reeglit, sest server, mis algatab ühenduse omaenda kliendiga, on teine voog. Ilma selle reeglita vastab klient aadressile, mida ta marsruudida ei saa. Aseta kitsas reegel enne iga laia maskeeringut, et konkreetne tõlge võidaks.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Mitme võrguliidesega hostid lisavad seotud vea, mis kliendi vaates näeb identne välja. Vastus lahkub liidesest, mille mõõdik on madalam, sest lähteaadress valiti teisest tabelist. Kontrolli tagasiteed otsinguga, selle asemel et eeldada, et edasitee seda tähendab.

Seejärel kontrolli mõlemat suunda ja mõlemat suurust

Pärast muudatust pingi kliendist LAN-i hostini ja siis LAN-i hostist klientini. Teine suund on see, mille inimesed vahele jätavad, ja just see paljastab puuduliku tõlkereegli. Kirjuta mõlemad tulemused ajatemplitega üles, et hilisem regressioon oleks võrreldav.

Seejärel liiguta päris andmeid, sest väike ping, mis õnnestub, samal ajal kui suur ülekanne takerdub, on MTU sümptom. See viga ilmub kohe pärast seda, kui oled endale marsruudi parandamise eest õnnitlenud.

Lõpuks testi uuesti pärast taaskäivitust. Tööajal sisestatud marsruudi- ja tulemüürikäsud ei jää selle üle, ja lahendus, mis järgmisel käivitusel kaob, diagnoositakse uuesti kellegi poolt, kellel on vähem konteksti. Tee muudatus püsivaks nii, nagu sinu süsteem seda juba teeb, ja käivita siis üks kord meelega uuesti.