Bakit Kailangan ng L2TP/IPsec ang UDP 1701 Bukod sa IPsec
Ang L2TP ay pangalawang protokol na naglalakbay sa loob ng una, kaya kailangan pa ring ihatid ng endpoint ang UDP 1701 pagkatapos ng decapsulation, kahit walang intermediate na aparato ang nakakakita nito.
Ang mga firewall na pumapayag sa IKE at ESP pero hindi sa UDP 1701 ay sumisira sa mga koneksyon ng L2TP sa paraang mukhang problema sa mga kredensyal. Ang dahilan ay ang L2TP ay pangalawang protokol na naglalakbay sa loob ng una. Dinadala at pinapatunayan ng IPsec ang palitan, at pinapatakbo ng L2TP ang sarili nitong tunel sa ibabaw ng UDP 1701, na kailangan pa ring ihatid ng lokal na stack. Ang pag-alam kung saan lumilitaw ang bawat header ay nagpapaliwanag kung aling aparato ang nangangailangan ng aling tuntunin.
Dalawang protokol, dalawang set ng port
Gumagamit ang koneksyon ng L2TP/IPsec ng IKE sa UDP 500, ng pagtawid sa NAT sa UDP 4500 kung saan may pagsasalin, at ng ESP bilang IP protocol 50 kung saan wala. Ang L2TP mismo ay protokol ng tunel sa UDP 1701, at tumatakbo ito pagkatapos na mapatunayan ng IPsec ang kapareha. Magkaiba ang pagpalya ng dalawang hati, at ang mga linya ng log na nag-uulat tungkol sa kanila ay nagmumula sa magkaibang bahagi. Ang set ng tuntuning sumasaklaw lamang sa unang hati ay gumagawa ng koneksyong nakikipagnegosasyon at pagkatapos ay namamatay sa yugto ng tunel.
Inilalarawan ng mga numero ng port ang mga dulo ng transportasyon, at ang ESP ay hindi talaga port. Kaya naman ang interface ng firewall na nag-aalok lamang ng mga tuntunin sa TCP at UDP ay hindi maipapahayag ang buong patakaran ng IPsec. Dapat payagan ang protocol 50 bilang protocol, at ang tuntuning tumutukoy lamang sa UDP ay hinding-hindi tutugma rito.
Ipinapaliwanag ng balot ang port
Sa kawad, ang koneksyon ng L2TP/IPsec ay karaniwang nagpapakita ng IKE sa 500 at nakabalot na ESP sa 4500. Ang header ng UDP 1701 ay nasa loob ng protektadong kargamento, kaya hindi ito nakikita ng pagkuha sa panlabas na interface. Kailangan pa ring ihatid ng lokal na host ang datagram na iyon sa daemon ng L2TP, at nangyayari ang paghahatid pagkatapos ng decapsulation. Kaya ang tuntunin para sa 1701 ay pag-aari ng firewall ng endpoint mismo, kahit kailanman ay walang intermediate na aparatong nakakakita sa port.
Ipinapaliwanag ng pagkakasunod-sunod ng pagproseso ang malaking bahagi ng kalituhan. Kung ilalapat ng stack ang patakaran ng IPsec bago ang filter ng host, itutugma ang decapsulated na pakete ng L2TP bilang UDP 1701; kung baliktad ang pagkakasunod-sunod, ang mga panlabas na port ang nakikita ng set ng tuntunin. Umiiral sa praktika ang dalawang pag-uugali, kaya mukhang gumagana ang parehong set ng tuntunin sa isang plataporma at nabibigo sa iba.
Suriin ang landas ayon sa pagkakasunod-sunod
Kunin muna ang panlabas na interface at tiyakin na gumagalaw ang IKE at nakabalot na ESP sa dalawang direksyon. Pagkatapos ay suriin ang mga counter ng lokal na firewall para sa decapsulated na trapiko. Mahalaga ang pagkakasunod-sunod, dahil ang pagkuha na walang ipinapakita ay nangangahulugang nasa itaas ng host ang problema.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701
Kinukumpirma ng pagkuha ang unang hati ng palitan at ipinapakita kung tumutugon ang kapareha. Ipinapakita ng listahan ng tuntunin kung may tuntunin para sa 1701 at kung saan ito nakatayo kaugnay ng anumang patakaran sa pagtatapon. Kinukumpirma ng listahan ng socket na nakatali at nakikinig ang daemon ng L2TP, na nag-aalis ng serbisyong hindi kailanman nagsimula. Basahin ang tatlo bago baguhin ang isang tuntunin, dahil ang nawawalang tagapakinig at ang na-filter na port ay gumagawa ng magkaparehong reklamo mula sa gumagamit.
Ano ang hindi maipapakita ng pag-scan ng port
Ang panlabas na pag-scan ng UDP 1701 laban sa isang server na wastong naka-configure ay karaniwang walang iniuulat, at iyon ang inaasahang resulta. Ang port ay hindi nakalantad sa internet; naaabot lamang ito pagkatapos na mapatunayan ng IPsec ang kapareha. Ang ituring na sira ang saradong resulta ay humahantong sa pagbubukas ng port na dapat manatiling sarado. Hindi makakita ang pag-scan sa loob ng tunel nang higit sa hindi nito makikita ang trapiko ng aplikasyon.
Subukan sa halip gamit ang tunay na kliyente, at basahin kung aling yugto ang naaabot nito. Kung nakikipagnegosasyon ang koneksyon at pagkatapos ay natigil, ang daemon ng L2TP o ang lokal na filter ang pinaghihinalaan; kung hinding-hindi ito nakikipagnegosasyon, ang mga panlabas na port ang may kasalanan. Ang nag-iisang paghahating iyon ay nag-aalis ng malaking bahagi ng hula tungkol sa kung aling tuntunin ang idadagdag, at ginagawang mahulaan ng pagpapatong ng protokol ang bagay na ito sa halip na misteryoso.