Að opna VPN-portinn gerir kleyntunum ekki kleift að ná LAN

Tunnillinn kemur upp, kleynturinn sannar sig, en LAN-ið bak við gáttina er áfram ósýnilegt. Reglan sem átti að laga þetta hleypir VPN-portinum í gegn og virkar nákvæmlega eins og skrifað er, því reglan stjórnar pökkum sem eru stílaðir á gáttina sjálfa. Umferð kleyntsins til hýsis bak við gáttina hefur annað áfangastað og aðra keðju. Árangursrík innskráning breytir ekki hvorri keðjunni kjarninn skoðar.

Tvær keðjur, tveir ólíkir áfangastaðir

Örlög pakka ráðast af því hvert hann fer, ekki hvernig hann kom. Umferð á heimilisfang á gáttinni er afhent staðbundið og metin eftir inntaksreglum. Umferð sem gáttin sendir áfram er metin eftir framsendingarreglum. Sama tunnilviðmótið getur búið til báðar tegundir pakka, því getur ein regla ekki náð yfir bæði verkefnin.

Öll goðsögnin í einni setningu: að leyfa hlustandanum segir ekkert um að leyfa netið bak við hann. Þetta eru tvær aðskildar ákvarðanir með aðskildum sönnunum, og viðmótsnafn á báðum sameinar þær ekki.

Hvað hlustandareglan leyfir í raun

Pökkum hlustandans lýkur í VPN-ferlinu, og það er það sem gerir tunnilinn mögulegan. Stjórnborð gáttarinnar og staðbundið greiningarsvar nota líka eigin inntaksleið hýsisins, því tekst próf til gáttarinnar meðan allt bak við hana bregst. Bæði niðurstöðurnar eru réttar og hvorug snýr að LAN-inu.

Þegar ferlið afkapslar umferð kleyntsins fyrir annan áfangastað fer pakkinn inn á framsendingarleiðina og þarf þar leyfi. Árangursrík sannvottun ræður því hver kleynturinn er; hún ræður ekki hvert hann má fara. Spurningarnar tvær hafa ólíka eigendur, ólík skrár og ólík villuskilaboð.

Prófaðu frá kleynt, aldrei frá gáttinni

Próf sem gert er á gáttinni fylgir eigin útleið hýsisins og getur tekist meðan framsendingarleiðin er lokuð. Byrjaðu prófið frá kleyntinum og fylgstu með báðum endum streymisins.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Ef beiðnin birtist á tun0 og ekkert nær áfangastaðnum er pakkanum hent eftir komu, sem vísar á framsendingarreglur eða eigið síun áfangastaðarins. Ef ekkert birtist á tun0 yfirleitt sendir kleynturinn hana ekki einu sinni í tunnilinn, og vandamálið er leiðarval á kleyntinum en ekki stefna á gáttinni. Berðu það saman við beiðni sem fer rétt út og skilar engu, sem er tilfellið með endurkomuleiðina.

Framsending þarf þrjá hluti, ekki einn

Framsending í kjarnanum verður að vera virk, síuregla verður að taka við streyminu og áfangastaðurinn verður að vera aðgengilegur með leið fyrir svarið til að koma aftur. Ef einn af þremur vantar er þögnin sú sama frá sjónarhóli kleyntsins.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lestu þrjár útkomurnar saman. Núll í þeirri fyrstu gerir hinar tvær óviðkomandi, og sjálfgefin höfnunarstefna í þeirri annarri hendir pökkum kleyntsins meðan eigin umferð gáttarinnar virkar áfram. Þriðja útkoman sýnir hvers vegna hlustandareglan var aldrei vandamálið.

Haltu reglusetningunum tveimur aðskildum í skjölunum

Skrifaðu hlustandaregluna og regluna fyrir framsendu þjónustuna á aðskildar línur, með aðskildum eigendum og ástæðum. Þegar VPN-portinum er breytt eða ný þjónusta gefin út kemur sú aðgreining í veg fyrir að ein breyting víkki hina hijóðlega.

Í stað þess að líta á hvern sannreyndan jafningja sem traustan LAN-meðlim skaltu nota þröngar reglur fyrir þau kleyntsvið og þjónustur sem þurfa þær. Athugasemdir um framsendingu hjá StrongSwan lýsa endurkomuleiðar- og þýðingarhlið sömu landamæra, sem er aftur þriðja ákvörðunin.

Að lokum skaltu halda lögunum beinum þegar notanda er hafnað. Ef beiðnin nær til hýsisins og forritið hafnar reikningnum skaltu laga heimild forritsins á því lagi; að víkka framsendinguna getur ekki veitt skilríki fyrir skráadeilingu og mun víkka aðgang fyrir alla aðra sem tengjast með góðum árangri.